bulia byak wrote:
Why "better"? What if one day, we need 64 bit precision - do a global search and replace again? The NR* stuff was there exactly for this: a layer of abstraction that allows to change the actual precision quickly - and it was not "a bug" because the typedefs are there for exactly this purpose (and they were not "general purpose" becaue the NR prefix limited their scope pretty narrowly to the NR subsystem).
Well, it's "better" because of fixing clarity in the code.
NRShort sounds like it's supposed to be a short of some type. It sounds like it's supposed to be the 'general' idea of a short.
Thus, it sounds like it was exactly intended to get a common, predetermined precision regardless and isolated from the underlying C implementation. And looking into gen_nr_config.c, it seems that is the case:
if (sizeof (short) == 2) { printf ("typedef signed short NRShort;\n"); printf ("typedef unsigned short NRUShort;\n"); } else { die ("sizeof (short) != 2"); }
Since there's a hardcoded check for a size of 2 (even after your update), it seems to clearly be saying "Hey! I want this NRShort type to be exactly 16-bit"
And then looking to the header at the begining, the 'kludge' factor goes up more:
/** * A little utility function to generate header info. * * Yes, it would be possible to do this using more "native" autoconf * features, but I personally find this approach to be cleaner. * * The output of this program is generally written to art_config.h, * which is installed in libart's include dir. **/
Anyway, with all the signs in the code, it seemed to be calling out for '16-bit' as the original intent. If that has changed, then we should tweak it. Yes, changing it to 'int' would work for most (but not all) systems, however that seems to be just a clever work-around to the true precision problem.
And... here we hit the crux of a problem. A simple work-around got the bug to go away. However, the clarity of the code was not updated, so later work undid the earlier fix. This is why I follow advice of Knuth and the like and consider clarity to be the first priority for code.