J. David Bryan a écrit:
The problem is that C doesn't have, as far as I know, a method of declaring an integer of a guaranteed size, which makes interfacing across compilers problematic. You can pick some types that happen to work today, but they aren't guaranteed to work tomorrow. ISO Pascal, of course, has the same problem. GPC appears to solve that problem by providing sized integers. (Ada also recognizes this problem and solves it by providing optional "representation attributes" to guarantee a particular size where needed.)
"WordBool" and "Boolean (32)" solve different problems: the former when interfacing to a GNU C routine that uses "unsigned int" and where the parameter size is intended to track changes in the size of GNU C's "int", and the latter when interfacing to third-party routines that require specific parameter sizes.
I fully agree with this analysis. I has similar problems while rereading with gpc 16 bits integer files which contained experimental data or results of computations written by BP: shortint was one solution, but integer(16) is definitely better because it is clear, explicit and permanent. So keep the actual status: Shortint, integer(16) and also the standard packed(-32768..32767) all defined. integer(16) is much clearer than packed ... The last construct is probably then the way to solve the problem of redefining integer=integer(16) which launched the discussion. Better use integer=packed(-32768..32767) if you want to define 16 bits integer to enable to rerun 16 bits programs completely unchanged. The only issue is _not_ to enforce the standard that packed components can be accessed only by the pack and unpack standard procedures, which is already done now.
Maurice