FD_SET compiler warning, why that particular warniing?

[David Mathog]

There was an editing error in one of my programs giving this line (two
left parentheses, one right):

FD_SET((ncmd->cmd_in_fd,&read_set);

When compiled with

gcc -Wall -pedantic -stc=c99

it issued this warning for that line number:

error: 'FD_SET' undeclared (first use in this function)

There's no argument that the line of code was wrong. I am curious
though why a compiler would choose to emit that particular message.
It was most confusing since FD_SET calls preceded and followed this one,
and they were not generating these "undeclared" warnings.

Regards,

David Mathog

 

[jameskuyper]

There was an editing error in one of my programs giving this line (two
left parentheses, one right):

FD_SET((ncmd->cmd_in_fd,&read_set);

When compiled with

gcc -Wall -pedantic -stc=c99

it issued this warning for that line number:

error: 'FD_SET' undeclared (first use in this function)

There's no argument that the line of code was wrong. I am curious
though why a compiler would choose to emit that particular message.
It was most confusing since FD_SET calls preceded and followed this one,
and they were not generating these "undeclared" warnings.

How is FD_SET defined?

 

[Walter Roberson]

There was an editing error in one of my programs giving this line (two
left parentheses, one right):

When compiled with

gcc -Wall -pedantic -stc=c99

it issued this warning for that line number:

error: 'FD_SET' undeclared (first use in this function)

There's no argument that the line of code was wrong. I am curious
though why a compiler would choose to emit that particular message.
It was most confusing since FD_SET calls preceded and followed this one,
and they were not generating these "undeclared" warnings.

Suppose FD_SET is an object-like macro, then because of the missing
bracket, the line is not an object-like invocation of the macro
and so FD_SET would not be recognized as a macro name on that line.

 

[Ben Pfaff]

Suppose FD_SET is an object-like macro, then because of the missing
bracket, the line is not an object-like invocation of the macro
and so FD_SET would not be recognized as a macro name on that line.

That doesn't make sense. To be expanded, an object-like macro
doesn't need to be followed by any particular token. And if you
actually meant function-like macro, then the preprocessor would
continue reading the arguments from succeeding lines of the
source file; the lack of a right parenthesis on the same line
would not dissuade it from the idea that it was expanding a
macro.

 

[David Mathog]

How is FD_SET defined?

Good question. I believe these are the ones it is using:

#define FD_SET(fd, fdsetp) __FD_SET (fd, fdsetp)

and

#define __FD_SET(fd,fdsetp) \
__asm__ __volatile__("btsl %1,%0": \
"=m" (*(__kernel_fd_set *) (fdsetp)):"r" ((int) (fd)))

I had to take a little white space out of the latter one to keep
it from wrapping.

Regards,

David Mathog

 

[Keith Thompson]

There was an editing error in one of my programs giving this line (two
left parentheses, one right):

FD_SET((ncmd->cmd_in_fd,&read_set);

When compiled with

gcc -Wall -pedantic -stc=c99

it issued this warning for that line number:

error: 'FD_SET' undeclared (first use in this function)

There's no argument that the line of code was wrong. I am curious
though why a compiler would choose to emit that particular message.
It was most confusing since FD_SET calls preceded and followed this one,
and they were not generating these "undeclared" warnings.

FD_SET is not part of standard C, but it's defined as a function-like
macro on many systems. Assuming it's defined that way on your system,
the only thing the C standard says is that implementation must produce
at least one diagnostic. The standard doesn't require the diagnostic
to make sense.

Detailed questions about gcc's behavior would be better asked on
gnu.gcc.help. But here's a hint: The output of "gcc -E" is
instructive. (And it's odd that gcc continues processing after a
fatal preprocessing error; that's why gcc gets confused.)

If we want to discuss this in the context of standard C (without
dependence either on gcc or on headers that define FD_SET), here's a
standalone invalid program that illustrates the same issue:

void fd_set(int x, int y) { }
#define FD_SET(x, y) fd_set(x, y)
void foo(void)
{
int x = 0, y = 0;
FD_SET((x, y); /* Note extra left parenthesis. */
}

 

[jameskuyper]

That should be std, not stc, right?

Good question. I believe these are the ones it is using:

#define FD_SET(fd, fdsetp) __FD_SET (fd, fdsetp)

Using your defective code and those #defines, I get:

unterminated argument list invoking macro "FD_SET"

which makes perfect sense, unlike the message you've been getting. Is
it possible that there's a ')' somewhere else in your code matching
the first '(' in your use of FD_SET? If so, then the macro won't fail,
giving you all kinds of opportunities for the program itself to fail
after the macro is expanded. How weird the error messages are that you
would get depends upon how much of the rest of your program lies
between the first '(' and the matching ')'.

 

[Jack Klein]

That doesn't make sense. To be expanded, an object-like macro
doesn't need to be followed by any particular token. And if you
actually meant function-like macro, then the preprocessor would
continue reading the arguments from succeeding lines of the
source file; the lack of a right parenthesis on the same line
would not dissuade it from the idea that it was expanding a
macro.

Has someone forgotten that macros end at the first unescaped newline?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Keith Thompson]

[...]

That doesn't make sense. To be expanded, an object-like macro
doesn't need to be followed by any particular token. And if you
actually meant function-like macro, then the preprocessor would
continue reading the arguments from succeeding lines of the
source file; the lack of a right parenthesis on the same line
would not dissuade it from the idea that it was expanding a
macro.

Has someone forgotten that macros end at the first unescaped newline?

Macro definitions do. Macro invocations (for function-like macros) do
not. For example, if FD_SET is a macro that expects two arguments,
then this:

FD_SET (
arg1,
arg2
)

is valid.

 

[Jack Klein]

[...]

That doesn't make sense. To be expanded, an object-like macro
doesn't need to be followed by any particular token. And if you
actually meant function-like macro, then the preprocessor would
continue reading the arguments from succeeding lines of the
source file; the lack of a right parenthesis on the same line
would not dissuade it from the idea that it was expanding a
macro.

Has someone forgotten that macros end at the first unescaped newline?

Macro definitions do. Macro invocations (for function-like macros) do
not. For example, if FD_SET is a macro that expects two arguments,
then this:

FD_SET (
arg1,
arg2
)

is valid.

You're absolutely right, and you and this topic have caused me to
learn something new today. That doesn't often happen to me regarding
the C standard these days, so thanks.

Imagine...

"Within the sequence of preprocessing tokens making up an invocation
of a function-like macro, new-line is considered a normal white-space
character."

I never would have guessed.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Keith Thompson]

You're absolutely right, and you and this topic have caused me to
learn something new today. That doesn't often happen to me regarding
the C standard these days, so thanks.

Imagine...

"Within the sequence of preprocessing tokens making up an invocation
of a function-like macro, new-line is considered a normal white-space
character."

I never would have guessed.

The key thing to remember is that an invocation of a function-like
macro is supposed to work just like an ordinary function call.
Standard library functions can additionally be defined as macros.
That wouldn't work if there were syntactic restrictions on macro
invocations beyond those imposed on function calls. (If you happen to
write all your function calls on a single line, you won't run into
this, but there's no requirement to do so.)

 

[Richard Bos]

Using your defective code and those #defines, I get:

unterminated argument list invoking macro "FD_SET"

which makes perfect sense, unlike the message you've been getting.

At a guess, the extra open paren makes the compiler think that this is
an invocation of FD_SET(one_argument) with the parenthesised comma
expression (ncmd->cmd_in_fd, &read_set). Since there is no definition
for FD_SET with one argument, only for FD_SET with two arguments, it
complains that it cannot find it. Since it's now thoroughly confused, it
misses the extra syntax error of having a function macro call without
the closing paren.
Yes, it's a broken message. But I'd not be surprised if that's what
happened.

Richard