GithubHelp home page GithubHelp logo

hashids.c's Introduction

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

hashids.c's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

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:

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.