Does your C compiler support "//"? (was Re: using structures)

[Paul Eggert]

some appear to think that POSIX ought to dictate the compiler
implementation choices at the architectural level.

It's quite reasonable for POSIX to do that, in order to specify
behavior that is useful for POSIX applications. And it has been done
on several occasions, not just this one. Signal handling and
thread-specific errno come to mind. Another example is that POSIX
1003.1-2001 also requires char to be exactly 8 bits wide. (There were
good reasons for this decision, too.)

 

[Paul Eggert]

But it can make sense for a system to have 16-bit ints and larger
addresses.

It's not merely a matter of machine addresses; it's also a matter of
other places where integers are used (e.g., wide character
processing). I will concede that one could build a 16-bit-int POSIX
1003.1-2001 host as a theoretical exercise, but nobody in their right
mind would build a practical system that way these days.

Of course you can always make "int" 32 bits even if the machine's
natural word size is 16 bits, though you have to bend the standard's
recommendation that 'A "plain" int object has the natural size
suggested by the architecture of the execution environment'.

But the natural word size on the 68k is 32 bits. Did you have some
other architecture in mind? (The segmented 16-bit x86 architecture
perhaps? Acck! From the POSIX point of view it's long gone, and good
riddance.)

 

[Douglas A. Gwyn]

How does your free implementation check that the typedef's it provides
match *all* the requirements imposed by the C standard (no padding bits,
two's complement representation for exact-width types)? How does it
provide int_least64_t on a platform with no native 64-bit (or longer)
integer type?

Get it and see.

And is that [select(2)] enough to be SUS conformant?

No, but presumably if one wanted to one could flesh out the
implementation *except* for the ridiculous requirement that
type int have 32 bits. The reason the C standard said that
int doesn't have to have 32 bits is because of such platforms.
POSIX has no business trying to override an architectural
matter.

 

[Douglas A. Gwyn]

Then, the C code that is *guaranteed* to be portable to *all*
freestanding implementations ...

No, you mean only to conforming freestanding implementations.
There is a trade-off such that requiring too much doesn't
improve portaibility but rather discourages standard
conformance, and for freestanding implementations conformance
to the language portion is quite important while conformance
to the library is secondary. Indeed, most of us have our
own implementations of the simple standard library functions
that we can use if we need them, but we don't have our own
compilers ready to go.

If the committee was stupid enough to reject it the first time, why should
I expect a different decision the second time?

The committee was not "stupid" just because they decided on
the basis of factors you personally don't care about. Since
the computing environment changes over time, trade-offs also
changes, and after 20 years perhaps a different decision can
be made.

Except for <assert.h>, certain parts of <stdio.h> and the dynamic
memory allocation functions, there is precious little in the C89 library
specification that couldn't be supported on freestanding implementations
or that wouldn't be useful on them. They'd also greatly benefit from the
C99 single precision additions to <math.h>, double precision being seldom
used on most embedded control applications.

I suppose you must mean type-generic functions. That raises
the bar for compilers, and imposing it on small systems that
might not even have substantial use of floating point is
something that must be weighed carefully.

 

[Douglas A. Gwyn]

... But it can make sense for a system to
have 16-bit ints and larger addresses. The 68000 is one example; I
think some of the earlier members of the x86 family also qualify.

Yes; I already raised that point, but Eggert seems to think
that POSIX is right to dictate that aspect of the language
implementation. Since it doesn't need to, the only argument
offered so far being that some programmers were "confused"
about the minimum width of type int (meaning that they
didn't understand the language they were using), doing so is
a violation of the layering principle.

Of course you can always make "int" 32 bits even if the machine's
natural word size is 16 bits, though you have to bend the standard's
recommendation that 'A "plain" int object has the natural size
suggested by the architecture of the execution environment'.

And there is usually a significant speed penalty in doing so.
Until such time as use of <stdint.h> becomes widespread, the
choice of implementation for type "int" needs to take into
account this historical property of best match to what the
hardware wans to do, because as the "default" choice for
integers of modest size that is what programmers have been
relying on.

 

[Douglas A. Gwyn]

... Another example is that POSIX
1003.1-2001 also requires char to be exactly 8 bits wide.

That is even less reasonable! What POSIX *should* have done,
if there was a requirement for an octet type, was to specify
support for int8_t.

 

[Douglas A. Gwyn]

It's not merely a matter of machine addresses; it's also a matter of
other places where integers are used (e.g., wide character
processing). I will concede that one could build a 16-bit-int POSIX
1003.1-2001 host as a theoretical exercise, but nobody in their right
mind would build a practical system that way these days.

You have distorted the issue. What is important is not that
complete POSIX implementations or SUS implementations exist
for 16-bit word architectures, but that as much of the
presumed *useful* applications developed originally on such
platforms *also* be readily ported to other hosts. Surely
you must have ben around when we spent a lot of resources
converted VAXisms to portable code? Now you're encouraging
the same mistakes all over again.

 

[Paul Eggert]

the only argument offered so far being that some programmers were
"confused" about the minimum width of type int (meaning that they
didn't understand the language they were using)

That's not what I meant when I wrote "confused". I meant that
programmers who read the standard naturally assumed that there must be
some 16-bit-int POSIX platforms out there, since the standard allowed
16-bit int. This assumption was incorrect.

And there is usually a significant speed penalty in doing so.
Until such time as use of <stdint.h> becomes widespread, the
choice of implementation for type "int" needs to take into
account this historical property of best match to what the
hardware wans to do,

That got thrown out the window long ago, I'm afraid. On the Alpha,
for example, the "natural size suggested by the architecture" is 64
bits, but int is 32 bits. This is because they needed some type to be
32 bits, and at the time the Alpha was designed, 'int' was the only
plausible type available. Other 64-bit platforms have mostly followed
suit. Perhaps the Alpha team would have chosen differently had C99
been available back then.

 

[Paul Eggert]

What is important is not that complete POSIX implementations or SUS
implementations exist for 16-bit word architectures, but that as
much of the presumed *useful* applications developed originally on
such platforms *also* be readily ported to other hosts.

That may be important to you, if you still care about 16-bit int
hosts. But it's not important to me, or to the vast majority of
programmers writing for POSIX platforms. We shouldn't have to
waste our time worrying about 16-bit platforms.

Now you're encouraging the same mistakes all over again.

Not at all. First, it's not a mistake to assume at-least-32-bit int.
Second, it's not even a similar situation. If it were similar,
programmers now would be assuming 32-bit-exactly int even though many
newer hosts had 64-bit int. That's not what's happening.

 

[Keith Thompson]

But the natural word size on the 68k is 32 bits. Did you have some
other architecture in mind? (The segmented 16-bit x86 architecture
perhaps? Acck! From the POSIX point of view it's long gone, and good
riddance.)

Note that I was referring to the 68000, not necessarily to the later
versions of the 68k family.

Motorola's documentation and instruction format names refer to 16-bit
quantities as "words", and to 32-bit quantities as "long-words". That
suggests it's a 16-bit processor.

On the other hand, the data and address registers are 32 bits each,
which argues for it being a 32-bit processor.

Unfortunately, there doesn't seem to be any good definition of what
constitutes an N-bit processor. I don't think it's address size;
nobody expects an 8-bit processor to be limited to 256 bytes of
address space. Probably the most consistent definition is the size of
the general-purpose integer data registers -- which argues for the
68000 being a 32-bit CPU, but 16-bit operations are more efficient
(i.e., int_fast16_t should be 16 bits, whereas it would be 32 bits on
a "true" 32-bit system).

The point is that choosing to make "int" 16 bits on the 68000 is a
perfectly reasonable choice, though not the only one.

 

[Keith Thompson]

That got thrown out the window long ago, I'm afraid. On the Alpha,
for example, the "natural size suggested by the architecture" is 64
bits, but int is 32 bits. This is because they needed some type to be
32 bits, and at the time the Alpha was designed, 'int' was the only
plausible type available. Other 64-bit platforms have mostly followed
suit. Perhaps the Alpha team would have chosen differently had C99
been available back then.

In the absence of extended integer types, there's a strong pressure to
make int no more than 32 bits on most systems. Assuming an 8-bit byte,
this gives you:

char 8 bits
short 16 bits
int 32 bits
long 32 or 64 bits
long long 64 bits

If you make int 64 bits, then either you don't have a 16-bit type, or
you don't have a 32-bit type. This can cause serious problems for
some software (as I've found out while trying to compile large
software packages on Crays).

Of course a C99 implementation could fill the gaps with extended
integer types, but no C90-conforming software can use them. That's
not quite true given a C90 implementation of <stdint.h>, but the C90
solutions for this kind of thing are usually limited to the standard
types.

The fundamental problem, I think, is that C's integer type system
isn't uniform enough. The type names are all keywords or sequences of
keywords with a very limited grammar, and it's far too easy for unwary
programmers to create dependencies on certain types being certain
sizes.

One possible solution that's consistent with what's been done so far
might be to allow a "short short" type. Then you could have:

char 8 bits
short short 16 bits
short 32 bits
int 64 bits
long 64 bits
long long 128 bits?

(and maybe "long char" rather than "wchar_t").

 

[Ben Pfaff]

One possible solution that's consistent with what's been done so far
might be to allow a "short short" type. Then you could have:

How about "long char"? "short long"?

 

[Paul Eggert]

Motorola's documentation and instruction format names refer to 16-bit
quantities as "words", and to 32-bit quantities as "long-words". That
suggests it's a 16-bit processor.

That was merely leftover terminology from the earlier Motorola 6800.
The VAX "word" was also 16 bits -- for consistency with the PDP-11
terminology -- but the VAX also was a 32-bit processor in any
reasonable sense.

(Back when VAXes were still popular I used to drive a car whose
license plate was 2GHZ780. Alas, the VAX-11/780 that I once
programmed for was merely a 5 MHz system. Those were the days, eh?)

The point is that choosing to make "int" 16 bits on the 68000 is a
perfectly reasonable choice,

Quite true. But nobody ever made that choice for a POSIX platform.
Besides, the 68000's days as a practical POSIX target are long gone.

 

[Ross Ridge]

The GNU coding standard inadvertently resulted in a fair bit of GNU code
being written that wasn't portable to 64-bit CPUs.

Really? That's news to me.

No, it's not news to you. You're on record has having fixed GNU code
that assumed 32-bit ints and as result wan't portable to 64-bit CPUs.

http://mail.gnu.org/archive/html/bug-bash/2001-04/msg00096.html

The GNU coding standards go to some length to say that code must
be portable among a wide variety of system types. It says that it is
"absolutely essential".

Thus, as I said, it's an inadvertent result.

Perhaps you're thinking about some of the older BSD code? A lot of
that code indeed assumed that int and long both had to be 32 bits.
But most of that code is long dead (or improved) by now, killed off by
ports to 64-bit hosts like the Alpha in the early 1990s.

The same is true of lot of GNU code.

Ross Ridge

 

[Ross Ridge]

But the natural word size on the 68k is 32 bits.

It depends on how you look at it. The 68000 CPU had a 32-bit
architecture, with 32-bit addressess and 32-bit registers, but it's
actual hardware only had a 16-bit ALU. As result 16-bit arithmetic was
about twice as fast as 32-bit arithmetic on this CPU and there wasn't
a full set of 32-bit operations. If int should be the fastest type,
then there's a good reason for a 68000 compiler to have an int that's
only be 16 bits wide

On the other hand I don't see the latest edition of POSIX being terribly
relevent. Who the heck has any reason to implement it?

Ross Ridge

 

[Paul Eggert]

No, it's not news to you. You're on record has having fixed GNU code
that assumed 32-bit ints and as result wan't portable to 64-bit CPUs.

http://mail.gnu.org/archive/html/bug-bash/2001-04/msg00096.html

Yes, I've fixed several bugs in that area. But it's a big leap to
suggest that the bugs were there because of the GNU coding standards.
I've also fixed bugs in the GNU where the source code assumed ASCII;
shall we chalk them up to the GNU coding standards too? How about
dereferencing null pointers and subscript errors, while we're at it?

 

[Paul Eggert]

I don't see the latest edition of POSIX being terribly
relevent. Who the heck has any reason to implement it?

The same sort of people who are implementing C99.
Gluttons for punishment, all of them.

 

[Richard Bos]

That is even less reasonable!

POSIX is not required to be reasonable from a C POV. It's not even
required to be reasonable from a portability POV, as the C Standard sees
portability. It's only required to be reasonable as far as the systems
which POSIX targets go. Since those systems are, AFAICT, modern desktop
machines, by preference running some kind of Unixoid, demanding 8-bit
chars and 32-bit ints is quite reasonable - for POSIX, not for C.

Richard

 

[Douglas A. Gwyn]

... We shouldn't have to
waste our time worrying about 16-bit platforms.

The point is, you don't have to waste time worrying about
them. Just use C's data types portably instead of making
unnecessary assumptions. Nobody would even think that
int always has 32 bits if you hadn't been misinforming
them. If they need 32 bits they should use another type.

Not at all. First, it's not a mistake to assume at-least-32-bit int.

But it is, because it's certainly not true for C in general,
and there are better ways to obtain that property than by
limiting one's programs to only POSIX platforms.

 

[Douglas A. Gwyn]

That's not what I meant when I wrote "confused". I meant that
programmers who read the standard naturally assumed that there must be
some 16-bit-int POSIX platforms out there, since the standard allowed
16-bit int. This assumption was incorrect.

It hardly seems like a problem if some 16-bit-int POSIX
platforms happened to exist, and there was no logical
reason to preclude them.