"Writing bug free C code" thoughts

[Army1987]

#define LOOP(nArg) { int _nMax=nArg; int loop; \
for (loop=0; loop<_nMax; ++loop)

If one is *really* that brain-dead, they could at least (apart from
not invading implementation namespace) add a {

#define LLOOP(lArg) { long _lMax=lArg; long lLoop; \
for (lLoop=0; lLoop<_lMax; ++lLoop)
#define ENDLOOP }

Otherwise we would have
LOOP (42) {
stuff();
ENDLOOP
which looks even worse than LOOP (42) stuff(); ENDLOOP.

 

[Army1987]

However its not a typo.
double * x, y;

I would write this as double *x, y; to emphatise x and y have
different types, if I were forced not to use more than one
semicolon. Otherwise I would use multiple decls only if all objects
have the same type and are somehow related (eg int i, j; for the
indices of nested loops).

 

[Guillaume]

If one is *really* that brain-dead, they could at least (apart from
not invading implementation namespace) add a {

Otherwise we would have
LOOP (42) {
stuff();
ENDLOOP

Nope. There is an opening { at the beginning of the LOOP macro.
This is why it's not really invading anyone's namespace, _nMax is a
local variable... granted, it could hide another _nMax which would be at
a higher level scope.

That said, there is a problem with this set of macros: only the first
instruction after the LOOP() will actually get looped.
You could add a { at the end of the LOOP() macro and add a second } at
the end of the ENDLOOP macro. There, better.

I agree that defining macros to do basic flow control is brain-dead, though.

That's not saying that you should never use macros. They are pretty
useful everytime they can spare you from repeating identical sequences:
it saves text space and keeps you (or at least lowers the probability
of) from doing evil copy-and-paste which can lead to silly errors.
They can make your source code look easier to read, too. And as an added
bonus, they can make maintaining much easier if your macros are well
written.

 

[Dietmar Schindler]

In C, any name begining with '_', and some others (...) are in
the implementations namespace. Using such in an application
results in undefined behaviour. ...

N1124, "7.1.3 Reserved identifiers" doesn't say so for identifiers
without file scope that begin with an underscore.

 

[Dietmar Schindler]

7.1.3 Reserved identifiers

...

-- All identifiers that begin with an underscore are
always reserved for use as identifiers with file scope
in both the ordinary and tag name spaces.

...

Thanks for confirming that N1124 and N869 agree in this case.

Rather than argue about it it is much safer to simply avoid them.

My concern wasn't safety, but correctness.