Re: What attributes of a programming language simplify its use?

On Tuesday, December 6, 2022 at 10:28:44 AM UTC-8, Keith Thompson wrote:


(snip)


> long long and int64_t are not the same (though int64_t may be the same
> type as long long in a given implementation). long long is *at least* 64
> bits. int64_t is *exactly* 64 bits, and must have a 2's-complement
> representation and no padding bits. "int int" is a syntax error.


> (I'm not arguing that C's integer type system isn't overly complicated.)


It seems that many Fortran programmers now assume that KIND=8
(for REAL) is a 64 bit IEEE floating point value, and I suspect for
INTEGER that it is a 64 bit integer.


Fortran makes no claim on the numerical values of KINDs.


It doesn't seem too surprising, then, that some would miss the
distinction between int64_t and long long.


In the early days of 64 bit computing, which I mostly remember from
the DEC Alpha, C compilers made long the 64 bit type.


That, then, broke too much software assuming long was 32 bits.


Much of IP networking evolved when C int was either 16 or 32 bits, but
you didn't really know. When short was reliably 16 bits, and long was
reliably 32 bits.


So, we have things like htonl() and ntohl() for converting 32 bit
values to/from network byte order. (The l stands for long.)


Since networking code, especially cross platform, depends more on
exact lengths than many others, that was one that had to get done
right pretty early. (Cross platform file formats, too.)


So then we got long long as the (close enough to) reliable 64 bit
type.


Maybe in a few years, we will have the long long long 128 bit type.


But C syntax has been confusing due to the reserved words and need for
additions in more than just data types.


There are stories that I don't remember on the different uses of the
word "static" in C.


Though maybe not quite as many as Fortran uses for *.

Return to the comp.compilers page.
Search the comp.compilers archives again.