#define X (MinGW)

[syzygy]

OK, thanks everyone. That clears up the mystery. It is bad to use identifiers that could be macros as formal parameters in function definitions in a header file, but I guess this can be excused by the directive that header files should be #included before any #defines. (Although this is a strange directive, as it is quite common to define macros through a compiler flag, like -DX, and then what??)

I don't think there is anything in the standard that says you can't #define before #include'ing.

But that it does not give the error message on the line where it occurs is truly appalling.

test.c:

Code: Select all

#define X 36

#include "test.h"

test.h:

Code: Select all

int triple(int X)
{
  return 3*X;
}

And now:

Code: Select all

$ gcc -c test.c
test.c:1:11: error: expected ‘;’, ‘,’ or ‘)’ before numeric constant
 #define X 36
           ^
test.h:1:16: note: in expansion of macro ‘X’
 int triple(int X)
                ^

Now the error actually makes sense (*).

Apparently the system headers include a directive that turns off diagnostic messages. That is fine if they are flawless, but confusing when they are not.

(*) The ';' confuses me, though. But "int triple(int ; )" in fact does compile without error... How is that legal C?

edit: System Headers (still, warnings are not errors)

[mar]

Maybe clang would give a more elaborate error message?

Another option would be to declare int constants as

Code: Select all

enum { X = 36 };

[hgm]

Ah yes, I guess I have to learn using constants, rather than macros. I was raised with Kernighan & Ritchie C, where these did not exist yet.

Anyway, I moved up the windows.h include, so my problems are solved, for the time being.

[petero2]

Code: Select all

$ gcc -c test.c
test.c:1:11: error: expected ';', ',' or ')' before numeric constant
 #define X 36
           ^
test.h:1:16: note: in expansion of macro 'X'
 int triple(int X)
                ^

Now the error actually makes sense (*).

...

(*) The ';' confuses me, though. But "int triple(int ; )" in fact does compile without error... How is that legal C?

It is not. It is a gcc extension, explained here.

[syzygy]

(*) The ';' confuses me, though. But "int triple(int ; )" in fact does compile without error... How is that legal C?

It is not. It is a gcc extension, explained here.

Thanks! Never saw this extension before.

[Ras]

Although this is a strange directive, as it is quite common to define macros through a compiler flag, like -DX, and then what??

That's why people give useful names to variables and defines - then this doesn't happen. Of course, the aim to produce the shortest source text possible somewhat collides with established principles of software development, so you are in hacking territory.

But that it does not give the error message on the line where it occurs is truly appalling.

Actually not. A C compiler is expected to compile as long as it's happy, and only throw the error when it isn't anymore. The consequences of an error may well show up later.

Just try C++ with 40+ pages of error spew when there is something wrong deeply hidden in some template, and you'll be happy with C error messages again.

[hgm]

That's why people give useful names to variables and defines - then this doesn't happen. Of course, the aim to produce the shortest source text possible somewhat collides with established principles of software development, so you are in hacking territory.

I don't think that producing readable code is "against established principles of software development". When I have a 2-dimensional 18 x 18 table with initialized data, like

Code: Select all

int table[][] + {
  { X, 0, Y, 0, X, 0, N, 0, X, 0, Y, 0, X, 0, Y, 0, X, 0 },
  { 0, N, 0, Y, 0, N, 0, X, 0, N, 0, Y, 0, N, 0, X, 0, N },
  { X, 0, Y, 0, X, 0, N, 0, X, 0, Y, 0, X, 0, Y, 0, X, 0 },
  { 0, N, 0, Y, 0, N, 0, X, 0, N, 0, Y, 0, N, 0, X, 0, N },
  { X, 0, Y, 0, X, 0, N, 0, X, 0, Y, 0, X, 0, Y, 0, X, 0 },
  { 0, N, 0, Y, 0, N, 0, X, 0, N, 0, Y, 0, N, 0, X, 0, N },
  { X, 0, Y, 0, X, 0, N, 0, X, 0, Y, 0, X, 0, Y, 0, X, 0 },
  { 0, N, 0, Y, 0, N, 0, X, 0, N, 0, Y, 0, N, 0, X, 0, N },
  { X, 0, Y, 0, X, 0, N, 0, X, 0, Y, 0, X, 0, Y, 0, X, 0 },
  { 0, N, 0, Y, 0, N, 0, X, 0, N, 0, Y, 0, N, 0, X, 0, N },
  { X, 0, Y, 0, X, 0, N, 0, X, 0, Y, 0, X, 0, Y, 0, X, 0 },
  { 0, N, 0, Y, 0, N, 0, X, 0, N, 0, Y, 0, N, 0, X, 0, N },
  { X, 0, Y, 0, X, 0, N, 0, X, 0, Y, 0, X, 0, Y, 0, X, 0 },
  { 0, N, 0, Y, 0, N, 0, X, 0, N, 0, Y, 0, N, 0, X, 0, N },
  { X, 0, Y, 0, X, 0, N, 0, X, 0, Y, 0, X, 0, Y, 0, X, 0 },
  { 0, N, 0, Y, 0, N, 0, X, 0, N, 0, Y, 0, N, 0, X, 0, N },
  { X, 0, Y, 0, X, 0, N, 0, X, 0, Y, 0, X, 0, Y, 0, X, 0 },
  { 0, N, 0, Y, 0, N, 0, X, 0, N, 0, Y, 0, N, 0, X, 0, N }
}

you should try once to see how it looks when you use long, descriptive variable names...

A C compiler is expected to compile as long as it's happy, and only throw the error when it isn't anymore.

And that is exactly what it does NOT do here. It gives an error aginst the "#define X 36", which at that point was perfectly OK. If it would have complained against a later "void f(int X)" in the included file (the first point where it could be unhappy) that it expected an identifier and found 36, everything would have been clear from the start.

[Ras]

When I have a 2-dimensional 18 x 18 table with initialized data

I see; what I was thinking of was the variable naming in Micro-Max, but that's a different thing here.

Code: Select all

int table[][] + {

Is the '+' a typo for '=', or is '+' really legal here? Never seen that idiom?

you should try once to see how it looks when you use long, descriptive variable names...

I agree. The easy way out would be moving the declarations into C files of their own. If it is about static storage class or local arrays, you can run the C preprocessor over these declaration C files and put the output into a result file which you just #include at the desired place of the source text.

It gives an error aginst the "#define X 36", which at that point was perfectly OK.

The preprocessor is a bit more complex than just single pass replacement, mostly because you can nest macros. So it will run through the source several times until all of the replacements have been marked as "blue" (prevents endless recursions). I guess it depends on the implementation of these passes where and when exactly it will choke.

[mar]

So it will run through the source several times until all of the replacements have been marked as "blue" (prevents endless recursions).

That's not how it works, that would be horribly inefficient. The preprocessor already has all the information it needs.
It simply knows which macro(s) it's currently expanding and simply doesn't expand the same symbol twice.

[hgm]

Is the '+' a typo for '=', or is '+' really legal here? Never seen that idiom?

That was a typo; Apparently I was tardy pressing the Shift key.