esilvia
commented
3 years ago Sorry I missed this post.
I'm 100% on board with clarifying the data types here, but I confess I'm out of my depth in the computer engineering world when we talk about IEEE data types. I must defer to a more informed individual if we're to clarify the data types more precisely.
If I remember correctly, the primary desire in that particular section (§2.3 in the current revision) was to ensure that float and double are 4 and 8 bytes, respectively, and char and unsigned char are each 1 byte, as the sizes of these variables can vary by implementation, as you've noted. Notice also that the spec has endeavored to avoid the int data type altogether, for the same reason.
plimkilde
The spec currently refers to the C99 standard for the definition of the data types used (
char,short,longetc.). As far as I can tell, taking this at face value may be self-contradictory and not reflect how LAS data should actually be parsed.The "classic" C integer data types are permitted to have any of three different representations for signed integers (sign-and-magnitude, two's complement, one's complement) and, rather than having exact specified widths, merely have minimum requirements for the ranges they can hold (e.g. [-2147483647, +2147483647] for
long). This could be a real problem sincelongis commonly 64 bits wide these days.I suppose the desired behavior is actually that of C99's exact-width types, which are also guaranteed to be two's complement for the signed types. Thus, the integer types should be handled like this:
charint8_tunsigned charuint8_tshortint16_tunsigned shortuint16_tlongint32_tunsigned longuint32_tlong longint64_tunsigned long longuint64_tNote also that
charin C may be either ofsigned charandunsigned char.The
floatanddoublemay technically not map to the single/double types in IEEE 754/IEC 60559. However, the C99 spec has extensive provisions for the common case when they do (they should map properly if__STDC_IEC_559__is defined) as described in Annex F. Thus, it should suffice with a remark that these two types are 32- and 64-bit IEEE types, respectively (as is currently the case).I'm not sure how all this should be addressed in the spec, but directly referring to C99's definitions for the integer type names seems incorrect.