Development quote of the week [LWN.net]

SunOS 4.0 or 4.1 was when the Sun geniuses unbundled the C compiler and made it a $$$ add on. That move single-handedly made GCC the reference compiler moving forward.

— Lyndon Nerenberg

to post comments

Yes. It did.

Posted Mar 6, 2025 2:03 UTC (Thu) by ejr (subscriber, #51652) [Link] (4 responses)

Other companies followed suit over the years. "Ours optimizes better!" (*cough* at Sun's trickery over SPEC, and IBM's over GEMM, Intel over which group is responsible for what funded by which other group)

But gcc (and now clang) kept moving forward steadily.

My main worry is that all the world pretends it's gcc. I used to rely on Sun's cc and IBM's xlc to present alternative views for C's undefined pieces. Maybe converging on "one" behavior for the vast majority of uses is ok. But I appreciated finding out when I misunderstood the standard. ubsan is an option-ish. But it comes out of a shared understanding of what "should be." Sun cc and xlc vehemently disagreed on some of the undefined aspects.

Yes. It did.

Posted Mar 6, 2025 10:38 UTC (Thu) by farnz (subscriber, #17727) [Link] (2 responses)

On the other hand, part of the reason the standard has certain swathes of "undefined behaviour" is that maintained compilers disagreed on how it should be defined in a way that meant that a strictly conformant program could not exploit unspecified or implementation defined behaviour. If all maintained compilers agree that signed integer overflow (to choose a hot one) is defined as twos-complement wrapping, then future C standards can remove signed integer overflow from undefined behaviour.

For example, sizeof(int) is implementation defined, but a strictly conformant program can still make useful use of it; similarly, strcpy_s leaves the values of the destination array elements after the null terminator unspecified, which is fine because strcpy_s is still useful even allowing for that.

Yes. It did.

Posted Mar 6, 2025 10:58 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

Surely it's the *result* of sizeof(int) that's implementation defined, not sizeof(int) itself? How can the semantics of sizeof(int) vary across implementations?

And why can't the C standard itself take all these behaviours, declare them implementation-defined, and require a standard way of telling conformant programs which implementation standard is desired or implemented?

Cheers,
Wol

Why not make it all implementation defined

Posted Mar 6, 2025 12:19 UTC (Thu) by farnz (subscriber, #17727) [Link]

In C, implementation defined behaviours are constrained by the Standard; a conforming implementation does not have freedom to do whatever it wants for unspecified or implementation defined behaviours, but instead must choose a behaviour within the constraints given. For sizeof(int), the semantics are defined by the Standard, but the value is the size of int in bytes, where the size of a byte in bits is given by CHAR_BIT (which is an implementation defined integer, at least 8). Further, sizeof(int) * CHAR_BIT must be at least 16, but can be larger. As long as these constraints are met, the implementation is conforming, even though the precise semantics of sizeof(int) are not fully defined by the Standard (since the resulting value from evaluating it can be 2, 4, or even 32 if the implementation so desires).

The distinction between implementation-defined and unspecified is twofold:

For implementation-defined behaviours, the implementation must document what behaviour it has chosen within the given constraints; for unspecified behaviour, it does not have to document anything.
For implementation-defined behaviour, the implementation's behaviour must be deterministic; for unspecified behaviour, the implementation is allowed to non-deterministically choose different behaviour within the constraints given by the standard each time the program is executed (unless, of course, the Standard specifies deterministic choice as one of the constraints).

And at least in theory, the Standard could use feature test macros to convert all undefined behaviour to unspecified behaviour in a useful form (where the allowed sets of behaviour are constrained, and you must have a feature test macro to tell you which set is chosen by this implementation). It doesn't do so, firstly because some behaviour doesn't admit a definition on all systems (e.g. if you create a function pointer and set it to 0x12345678, what's the behaviour of calling the function pointer?), and secondly because implementations can choose to exceed the minimum requirements of the Standard anyway, and document a feature test macro plus defined behaviour for an undefined behaviour in the Standard.

Note that feature test macros are already required for optional parts of the standard (e.g. there's a macro to tell you if <threads.h> is available), so this isn't a big leap for an implementation to make. It would thus be entirely reasonable, if someone stepped up to do the work and maintain it, for GCC or Clang to have a compiler flag that turns on a "most behaviour is defined in the documentation" mode with a feature test macro for each case where they made a decision, minimising UB to the cases where there's just no good definition (e.g. calling a dangling function pointer).

Yes. It did.

Posted Mar 6, 2025 12:05 UTC (Thu) by smoogen (subscriber, #97) [Link]

> Other companies followed suit over the years. "Ours optimizes better!" (*cough* at Sun's trickery
> over SPEC, and IBM's over GEMM, Intel over which group is responsible for what funded by which other group)

I honestly thought they all were doing it about this time or even earlier. I don't remember being able to get an IBM or HP C compiler on any computer in 87 or so without paying extra. However I was just getting into real computers then and these were University computers... so might have been 'deals' in the first place.

[I know on the PC, Commodore, and Apple markets it was already $$ to get a compiler so had thought it was standard]

/usr/ucb/cc

Posted Mar 6, 2025 23:44 UTC (Thu) by ballombe (subscriber, #9523) [Link] (1 responses)

While SUN unbundled the working SUNpro C compiler, they left the totally unusable /usr/ucb/cc for some backward compatibility reason. Suffice to say, that did not bring trust in Sun compiler expertise.

/usr/ucb/cc

Posted Mar 13, 2025 22:58 UTC (Thu) by raindog308 (guest, #176490) [Link]

I thought /usr/ucb/cc was just a wrapper that allowed you to use BSD-style flags, BSD header paths, etc. This was for users who still had pre-Solaris code, scripts, etc. I'm relying on a 25+-year-old memory and could certainly be wrong.