do{..}while(0) macro substitutions

[E. Robert Tisdale]

There are still plenty of platforms with no available C99 compiler.

Can you enumerate them?

The GNU C compiler ports almost everywhere
and is pretty near C99 compliant.

 

[Mathew Hendry]

If you use the macro MAX(a++, b), you'd invoke fairly undefined behaviour

As opposed to unfairly defined?

with one of the expressions being evaluated twice.

There's a sequence point between the two.

-- Mat.

 

[Keith Thompson]

Can you enumerate them?
Nope.

The GNU C compiler ports almost everywhere
and is pretty near C99 compliant.

"Almost" and "pretty near" aren't good enough for everyone's purposes.
I know gcc supports all the C99 features that *you* care about, but
that's relevant only to you.

 

[E. Robert Tisdale]

"Almost" and "pretty near" aren't good enough for everyone's purposes.

Nonsense!

They are good enough for C90 programmers.
C programmers accepted the new C90 standard
long before it was as mature as the C99 standard is now.
I don't see why they should hold C99 to a higher standard than C90.
Do you?

 

[Keith Thompson]

Nonsense!

They are good enough for C90 programmers.
C programmers accepted the new C90 standard
long before it was as mature as the C99 standard is now.
I don't see why they should hold C99 to a higher standard than C90.
Do you?

The issue isn't the maturity of the standard, it's how widespread
conforming implementations are. When C90 implementations were in the
state that C99 implementations are now, C90 code (particularly code
using function prototypes) still had to be considered non-portable.
It was still common to use preprocessor tricks to allow code to
compile both under K&R and C90 compilers. There was (and still is) a
tool called "ansi2knr" which translated C90 code to K&R code.

Some users were lucky enough to work in environments were they didn't
have to be concerned about portability to pre-C90 compilers, but most
of them were sensible enough not to berate those who weren't.

 

[Stephen Sprunk]

That a common implementation is not quite compliant isn't justification for
not using language features where it is compliant. I'm sure one can find
examples where GCC isn't C90 compliant either; should we go back to K&R C
until GCC is fixed?

The issue isn't the maturity of the standard, it's how widespread
conforming implementations are. When C90 implementations were in the
state that C99 implementations are now, C90 code (particularly code
using function prototypes) still had to be considered non-portable.
It was still common to use preprocessor tricks to allow code to
compile both under K&R and C90 compilers. There was (and still is) a
tool called "ansi2knr" which translated C90 code to K&R code.

The situation is different in this case, though, since most of the changes
in C99 were already typically implemented as extensions to C90 compilers.

Some users were lucky enough to work in environments were they didn't
have to be concerned about portability to pre-C90 compilers, but most
of them were sensible enough not to berate those who weren't.

I don't berate those using C90 (or K&R) compilers because I know there are
often reasons that users don't have a choice. However, I do think it's
reasonable to code to C99 these days; the changes are minor enough that
anyone interested can back-port the code and submit patches.

S

 

[Chris Croughton]

By that argument we should all still be writing in K&R C instead of C89; one
must draw a line somewhere, and it's perfectly valid in many cases to make
it C99 (or C89 with very common extensions).

It's perfectly valid in many cases to assume GCC with its extensions
(indeed, much of my code has done), or in other cases to assume that you
have a POSIX comlpiant library (a fair bit of my code assumes that),
etc. However, if you need to make your code maximally portable you need
to assume the minimum standard. This is why a fair bit of code still
uses compiler tricks for function prototypes, because there are still
some systems with only K&R1 compilers (as I recall the compiler supplied
on SunOS systems was barely K&R, it just sufficed to compile GCC but
probably wouldn't even do that with recent versions of GCC). In
practice, assuming C89 is pretty safe by now (15 years after the
standard came out).

There are a number of extensions in C99 which I would like to use, but
can't until C99 compilers get a lot more common (in particular GCC is
still not fully C99 compliant, in particular some of the functions and
headers have chunks of "not implemented yet" in them).

Not everyone has the choice of what compiler they use, many places won't
allow other software to be insttalled (and even when they do there is no
point in one person using a C99 compiler when the rest of the company is
using a C89 one and the code is required to be used by others!). I
doubt if many places are still using a pre-C89 compiler for any serious
development, but I know of none who are using a fully-compliant C99
compiler (indeed, from recent discussions here it seems that there isn't
one yet apart from possibly Comeau/Dinkumware, but their website says
only that it is "as close as you can get to full compliance", not that
it is fully compliant).

Chris C

 

[Randy Howard]

This practice is obsolete and should be discouraged.

Will you never stop?