FD_SET compiler warning, why that particular warniing?

Discussion in 'C Programming' started by David Mathog, Dec 21, 2007.

  1. David Mathog

    David Mathog Guest

    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
    David Mathog, Dec 21, 2007
    #1
    1. Advertising

  2. David Mathog

    Guest

    David Mathog wrote:
    > 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?
    , Dec 21, 2007
    #2
    1. Advertising

  3. In article <fkh2et$4jo$>,
    David Mathog <> wrote:
    >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.


    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.
    --
    So you found your solution
    What will be your last contribution?
    -- Supertramp (Fool's Overture)
    Walter Roberson, Dec 21, 2007
    #3
  4. David Mathog

    Ben Pfaff Guest

    -cnrc.gc.ca (Walter Roberson) writes:

    > In article <fkh2et$4jo$>,
    > David Mathog <> wrote:
    >>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.

    >
    > 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.
    --
    "In My Egotistical Opinion, most people's C programs should be indented six
    feet downward and covered with dirt." -- Blair P. Houghton
    Ben Pfaff, Dec 21, 2007
    #4
  5. David Mathog

    David Mathog Guest

    wrote:
    > David Mathog wrote:
    >> 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?


    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
    David Mathog, Dec 21, 2007
    #5
  6. David Mathog <> writes:
    > 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. */
    }

    --
    Keith Thompson (The_Other_Keith) <>
    Looking for software development work in the San Diego area.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Dec 21, 2007
    #6
  7. David Mathog

    Guest

    David Mathog wrote:
    > wrote:
    > > David Mathog wrote:
    > >> 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


    That should be std, not stc, right?

    > >> 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?

    >
    > 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 ')'.
    , Dec 21, 2007
    #7
  8. David Mathog

    Jack Klein Guest

    On Fri, 21 Dec 2007 12:40:55 -0800, Ben Pfaff <>
    wrote in comp.lang.c:

    > -cnrc.gc.ca (Walter Roberson) writes:
    >
    > > In article <fkh2et$4jo$>,
    > > David Mathog <> wrote:
    > >>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.

    > >
    > > 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.


    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
    Jack Klein, Dec 22, 2007
    #8
  9. Jack Klein <> writes:
    > On Fri, 21 Dec 2007 12:40:55 -0800, Ben Pfaff <>
    > wrote in comp.lang.c:

    [...]
    >> 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.

    --
    Keith Thompson (The_Other_Keith) <>
    Looking for software development work in the San Diego area.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Dec 22, 2007
    #9
  10. David Mathog

    Jack Klein Guest

    On Fri, 21 Dec 2007 19:01:40 -0800, Keith Thompson <>
    wrote in comp.lang.c:

    > Jack Klein <> writes:
    > > On Fri, 21 Dec 2007 12:40:55 -0800, Ben Pfaff <>
    > > wrote in comp.lang.c:

    > [...]
    > >> 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
    Jack Klein, Dec 23, 2007
    #10
  11. Jack Klein <> writes:
    > On Fri, 21 Dec 2007 19:01:40 -0800, Keith Thompson <>
    > wrote in comp.lang.c:
    >> Jack Klein <> writes:

    [...]
    >> > 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.


    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.)

    --
    Keith Thompson (The_Other_Keith) <>
    Looking for software development work in the San Diego area.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Dec 23, 2007
    #11
  12. David Mathog

    Richard Bos Guest

    wrote:

    > David Mathog wrote:
    > > wrote:
    > > > David Mathog wrote:
    > > >> 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);


    > > >> it issued this warning for that line number:
    > > >>
    > > >> error: 'FD_SET' undeclared (first use in this function)


    > > > 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)

    >
    > 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
    Richard Bos, Dec 24, 2007
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    11
    Views:
    1,109
  2. William

    FD_SET has unknown sockfd

    William, Mar 28, 2005, in forum: C++
    Replies:
    1
    Views:
    3,244
    Malte Starostik
    Mar 28, 2005
  3. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    880
    Mark Rae
    Dec 21, 2006
  4. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,849
    Smokey Grindel
    Dec 2, 2006
  5. Replies:
    29
    Views:
    628
    Lawrence Kirby
    Jun 11, 2005
Loading...

Share This Page