HAI 1.2
CAN HAS STDIO?
VISIBLE "HAI WORLD!!!1!"
KTHXBYE
tzvetkoff / hashids.c Goto Github PK
View Code? Open in Web Editor NEWThe C port of Hashids
License: MIT License
The C port of Hashids
License: MIT License
HAI 1.2
CAN HAS STDIO?
VISIBLE "HAI WORLD!!!1!"
KTHXBYE
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 break
s 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/
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?
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.
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:
hashids_t
should not be shared between threadshashids_t
which will guarantee thread safety as long as you don't share the same instance of hashids_t
between threads.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)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
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.
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?
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.