tzvetkoff / hashids.c

The C port of Hashids

HAI 1.2
  CAN HAS STDIO?
  VISIBLE "HAI WORLD!!!1!"
KTHXBYE

hashids.c's Issues

Support uint128_t as well on platforms/compilers that support it

I have a test failure that results from a hash that produces a number that is too long for an unsigned long long integer.
On platforms that provide the uint128_t we can provide an API that accepts those types.
Even on platforms that do not support it we can provide support since both GCC and Clang provide a compiler extension that supports uint_128_t.
On GCC it's unsigned __int128_t and on Clang it's __uint128_t.
I inspected the resulting assembly and it seems that both compilers cannot vectorize this type properly. We might be able to do this vectorization manually with AVX but I'm not sure.
What do you think?

Statement may fall through - warning in GCC7 and upper

Compiling under GCC version 7 or greater gives warning this statement may fall through for the last line of macro hashids_shuffle_step(iter). Macro is inserted in every case of switch-case in function void hashids_shuffle(char *str, size_t str_length, char *salt, size_t salt_length), and compiler warns because there are no breaks in cases.

But there is simple solution: just add __attribute__ ((fallthrough)); at the end of hashids_shuffle_step(iter) macro. More here: https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/

Hashids.c is not thread-safe

The hashids_t struct is not thread safe and shouldn't be shared between threads. I don't think we care about that though.
The real issue is error reporting. Currently there's global state for error reporting and that might produce a data race when one thread sets an error and the other reads it or when both of them set an error.
In my opinion we should:

• Document that instances of hashids_t should not be shared between threads
• Move the error reporting to hashids_t which will guarantee thread safety as long as you don't share the same instance of hashids_t between threads.
• Make hashids_errno thread-safe (http://www.gnu.org/software/autoconf-archive/ax_tls.html, https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Thread-Local.html)

Use integer floor division when possible

I encountered http://stackoverflow.com/questions/4102423/efficiently-implementing-floored-euclidean-integer-division and it seems that we can optimize floor division as well for integers.
I don't understand the code yet and I'm not 100% sure it's portable but I think there's a lot of performance to be gained if we get rid of most of our floating point arithmetics.

Vectorize hashids_shuffle

There's a possible optimization in hashids_shuffle() that allows us to partially vectorize it behind a feature flag if AVX512 is available.
See http://stackoverflow.com/questions/39277870/how-do-initialize-an-simd-vector-with-a-range-from-0-to-n#answer-39379901

Provide an API that support wide characters

I have a branch that implements an API with wchar_t *.
I'm unable to resolve some of the segfaults though.
Since the algorithm is the same and only the string manipulation functions are different I was thinking that maybe we can use m4 to generate both the regular API and wide character enabled API.
What do you think?

Safe hashids_decode

It will be really useful to provide a safe version of hashids_decode, something like:
hashids_decoden(struct hashids_t *hashids, char *str, unsigned long long *numbers, size_t n)
to avoid buffer overflows.

Right now any safely-written code should use both:
hashids_numbers_count and hashids_decode
which unnecessary doubles CPU work.

Hashids compatibility between C version and Swift version

Hello,

I am asking this here because no one seems to be facing this issue.
I am using Hashids swift version to encode an array and I am using C version to decode it with same SALT. The decoding is successful only one time after device reset, and after that every time decoding fails. The C version is 1.1.5 and Swift version is 1.1.0. Though I am not facing this issue if encoding is done using the Java version of Hashids on Android. Java version is 1.0.1.

The C code is:

size_t decode_hashids(const char *salt, char *hash, unsigned long long num_array[])
{
  hashids_t *hashids;
  hashids = hashids_init3(salt, MIN_HASH_STRLEN,HASHIDS_DEFAULT_ALPHABET);
 /*MIN_HASH_STRLEN is 6*/
  size_t bytes_decoded = hashids_decode(hashids, hash, num_array);   
  hashids_free(hashids);
  return bytes_decoded;
}

The Swift Code is:

let hashIds = Hashids(salt: salt , minHashLength: 6)
let id = hashIds.encode(number, number)

The call to hashids_init3 or any other function does not modify its value. In fact salt is a string in both languages. So in C its const char[] type and in Swift its String type. The value of salt is kept as a hardcoded value in both languages which does not change for the device (i.e. an arm based processor) where C code is running.