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 https://github.com/openvenues/libpostal/commit/d35f97f6f1ce5c367eb7dd0e780ff7f1dfbdc38c, 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.