Some code is not 32-bit safe

[federicomenaquintero]

I haven't checked everything, but for example:

static ordinal_indicator_t *ordinal_indicator_read(FILE *f) {
size_t key_len;
if (!file_read_uint64(f, (uint64_t *)&key_len)) {
return NULL;
}

char *key = malloc(key_len);
if (key == NULL) {
    return NULL;
}

This assumes that size_t is 64 bits. If the code is compiled on a 32-bit machine, the call to file_read_uint64() will smash the stack.

[albarrentine]

That's a good point. Testing so far has been on 64-bit arch only. Will convert the size_t reads to uint64_t and post a fix. Will also see what I can do about getting a 32 bit build as part of the continuous integration in Travis.

[albarrentine]

As of commit d35f97f, all file_read_uint64 calls reading into stack variables use uint64_t, not size_t. In #16, libpostal was reported to be working on 32-bit Debian and Ubuntu.

On the build side, Travis, our CI system, doesn't appear to support 32-bit environments, so unfortunately I won't be able to add an automated 32-bit build, but as a matter of good practice will avoid baking in 64-bit size_t assumptions going forward.

Closing the issue but feel free to reopen if there are any objections.