get_crc_table
(Incoherent notes on the problem) This exposes the whole big array to calls. Under the current scheme, some of it is only used on little endian platforms, and other parts of it only on big endian platforms. There's waste of several kilobytes. Additionally, better optimized crc32 code can make do with only 256 entries in it, much less.
I'd much prefer if table wasn't exposed by get_crc_table
as I consider it an implementation detail. We can't delete the interface. I've seen code in the wild that uses this to do its own crc32 calculations. However, they just use the first 256 entries. But I haven't been thorough and there might be code out there that needs the other stupid entries.
Since get_crc_table
doesn't even say how many entries it returns, making the table shorter can silently break code using table. We can change the function to return an array, perhaps, to signal to the compiler what the bounds are. That might not be perfect and might be an API/ABI break but probably not. Or it might not work. Not sure.
Alternatively, add an attribute warning/deprecated to the function, but that means zlib.h has to detect whether that feature is supported which is more trouble than worth.
We can also just break it and say it was an undocumented function if we can't find any users of other than the first 256 entries.