System headers, compiler conformance... - Unix

This is a discussion on System headers, compiler conformance... - Unix ; Hi, I have a C source file that includes several system header files (namely , , and ). When I compile it by invoking the compiler in conforming mode, it doesn't object to the inclusion of the headers, but it ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: System headers, compiler conformance...

  1. System headers, compiler conformance...

    Hi,

    I have a C source file that includes several system header files
    (namely , , and ). When
    I compile it by invoking the compiler in conforming mode, it doesn't
    object to the inclusion of the headers, but it gives me errors for
    every function, type, etc, that I use that's supposed to be defined in
    the header file, saying that it's undefined. (In other words, it acts
    as though the header file didn't define anything.) But when I compile
    it in non-conforming mode, it's All Good.

    Does anybody know why is this and how I can fix it? Do I have use non-
    conforming mode for every file that uses non-standard headers?

    I'm using GCC 4.3.0 on Fedora 9.

    Thanks,
    Sebastian


  2. Re: System headers, compiler conformance...

    On Fri, 08 Aug 2008 12:08:45 -0700, s0suk3 wrote:

    > I have a C source file that includes several system header files (namely
    > , , and ).


    > When I compile it by invoking the compiler in conforming mode, it
    > doesn't object to the inclusion of the headers, but it gives me errors
    > for every function, type, etc, that I use


    > when I compile it in non-conforming mode, it's All Good.


    Try using gcc -E to inspect the output of the pre-processor.

    $ cat foo.c
    #include

    $ gcc -E foo.c -o foo.cpp
    $ cat foo.cpp
    /* header.h header file */

    int foo(int);

    $

    See if the headers are there.

    It might be that they are included conditionally:

    #ifdef SOMETHING

    int foo(int);

    #endif

    in which case then the macro SOMETHING might not be defined in standard
    mode.



  3. Re: System headers, compiler conformance...

    s0suk3@gmail.com wrote:
    > Hi,
    >
    > I have a C source file that includes several system header files
    > (namely , , and ). When
    > I compile it by invoking the compiler in conforming mode, it doesn't
    > object to the inclusion of the headers, but it gives me errors for
    > every function, type, etc, that I use that's supposed to be defined in
    > the header file, saying that it's undefined. (In other words, it acts
    > as though the header file didn't define anything.) But when I compile
    > it in non-conforming mode, it's All Good.
    >
    > Does anybody know why is this and how I can fix it? Do I have use non-
    > conforming mode for every file that uses non-standard headers?
    >

    Something in your code or build is broken.

    Post a short example with the errors you see and how you compiled it.

    --
    Ian Collins.

  4. Re: System headers, compiler conformance...

    On Aug 8, 3:20*pm, viza
    wrote:
    > On Fri, 08 Aug 2008 12:08:45 -0700, s0suk3 wrote:
    > > I have a C source file that includes several system header files (namely
    > > , , and ).
    > > When I compile it by invoking the compiler in conforming mode, it
    > > doesn't object to the inclusion of the headers, but it gives me errors
    > > for every function, type, etc, that I use
    > > when I compile it in non-conforming mode, it's All Good.

    >
    > Try using gcc -E to inspect the output of the pre-processor.
    >
    > $ cat foo.c
    > #include
    >
    > $ gcc -E foo.c -o foo.cpp
    > $ cat foo.cpp
    > /* header.h header file */
    >
    > int foo(int);
    >
    > $
    >
    > See if the headers are there.
    >
    > It might be that they are included conditionally:
    >
    > #ifdef SOMETHING
    >
    > int foo(int);
    >
    > #endif
    >
    > in which case then the macro SOMETHING might not be defined in standard
    > mode.


    You're right. Thanks. One macro that's conditioning-out something that
    I need (the 'addrinfo' struct, and the getnameinfo() and
    freeaddrinfo() funcs) is '__USE_POSIX', in the header. So I
    could define this macro in my source, but I think there are other
    things that are being conditioned-out, and going through all those
    header files seems cumbersome, plus that doesn't seem like a good
    solution anyway.

    The gcc flag I'm using is std=c99. The code I have uses C99 features
    that will be disabled if I don't use that flag. What do you suggest I
    should do?

    Sebastian


  5. Re: System headers, compiler conformance...

    On Aug 8, 4:10*pm, Ian Collins wrote:
    > s0suk3@gmail.com wrote:
    > > Hi,

    >
    > > I have a C source file that includes several system header files
    > > (namely , , and ). When
    > > I compile it by invoking the compiler in conforming mode, it doesn't
    > > object to the inclusion of the headers, but it gives me errors for
    > > every function, type, etc, that I use that's supposed to be defined in
    > > the header file, saying that it's undefined. (In other words, it acts
    > > as though the header file didn't define anything.) But when I compile
    > > it in non-conforming mode, it's All Good.

    >
    > > Does anybody know why is this and how I can fix it? Do I have use non-
    > > conforming mode for every file that uses non-standard headers?

    >
    > Something in your code or build is broken.
    >
    > Post a short example with the errors you see and how you compiled it.
    >


    Like I mentioned to Viza, they're macros in the system header files
    that seem to be undefined when I invoke the compiler in conforming
    mode. Here are the errors from the compiler:

    gcc -std=c99 -Wall -c -I . -o obj/IStream.o network/unix/IStream.c
    network/unix/IStream.c: In function ‘IStream_Create’:
    network/unix/IStream.c:29: warning: implicit declaration of function
    ‘getaddrinfo’
    network/unix/IStream.c:31: error: unknown field ‘ai_flags’ specified
    in initializer
    network/unix/IStream.c:31: error: ‘AI_NUMERICSERV’ undeclared (first
    use in this function)
    network/unix/IStream.c:31: error: (Each undeclared identifier is
    reported only once
    network/unix/IStream.c:31: error: for each function it appears in.)
    network/unix/IStream.c:31: warning: excess elements in struct
    initializer
    network/unix/IStream.c:31: warning: (near initialization for
    ‘(anonymous)’)
    network/unix/IStream.c:32: error: unknown field ‘ai_family’ specified
    in initializer
    network/unix/IStream.c:32: warning: excess elements in struct
    initializer
    network/unix/IStream.c:32: warning: (near initialization for
    ‘(anonymous)’)
    network/unix/IStream.c:33: error: unknown field ‘ai_socktype’
    specified in initializer
    network/unix/IStream.c:33: warning: excess elements in struct
    initializer
    network/unix/IStream.c:33: warning: (near initialization for
    ‘(anonymous)’)
    network/unix/IStream.c:34: error: unknown field ‘ai_protocol’
    specified in initializer
    network/unix/IStream.c:34: warning: excess elements in struct
    initializer
    network/unix/IStream.c:34: warning: (near initialization for
    ‘(anonymous)’)
    network/unix/IStream.c:35: error: unknown field ‘ai_addrlen’ specified
    in initializer
    network/unix/IStream.c:35: warning: excess elements in struct
    initializer
    network/unix/IStream.c:35: warning: (near initialization for
    ‘(anonymous)’)
    network/unix/IStream.c:36: error: unknown field ‘ai_addr’ specified in
    initializer
    network/unix/IStream.c:36: warning: excess elements in struct
    initializer
    network/unix/IStream.c:36: warning: (near initialization for
    ‘(anonymous)’)
    network/unix/IStream.c:37: error: unknown field ‘ai_canonname’
    specified in initializer
    network/unix/IStream.c:37: warning: excess elements in struct
    initializer
    network/unix/IStream.c:37: warning: (near initialization for
    ‘(anonymous)’)
    network/unix/IStream.c:38: error: unknown field ‘ai_next’ specified in
    initializer
    network/unix/IStream.c:38: warning: excess elements in struct
    initializer
    network/unix/IStream.c:38: warning: (near initialization for
    ‘(anonymous)’)
    network/unix/IStream.c: In function ‘IStream_Destroy’:
    network/unix/IStream.c:52: warning: implicit declaration of function
    ‘freeaddrinfo’
    network/unix/IStream.c: In function ‘IStream_Connect’:
    network/unix/IStream.c:60: error: dereferencing pointer to incomplete
    type
    network/unix/IStream.c:61: error: dereferencing pointer to incomplete
    type
    network/unix/IStream.c:62: error: dereferencing pointer to incomplete
    type
    network/unix/IStream.c:63: error: dereferencing pointer to incomplete
    type
    network/unix/IStream.c:67: error: dereferencing pointer to incomplete
    type
    network/unix/IStream.c:67: error: dereferencing pointer to incomplete
    type

    This are the #include's in the source file:

    #include
    #include
    #include
    #include
    #include
    #include
    #include

    Sebastian


  6. Re: System headers, compiler conformance...

    s0suk3@gmail.com writes:
    >On Aug 8, 4:10=A0pm, Ian Collins wrote:
    >> s0suk3@gmail.com wrote:
    >> > Hi,

    >>
    >> > I have a C source file that includes several system header files
    >> > (namely , , and ). When
    >> > I compile it by invoking the compiler in conforming mode, it doesn't
    >> > object to the inclusion of the headers, but it gives me errors for
    >> > every function, type, etc, that I use that's supposed to be defined in
    >> > the header file, saying that it's undefined. (In other words, it acts
    >> > as though the header file didn't define anything.) But when I compile
    >> > it in non-conforming mode, it's All Good.

    >>
    >> > Does anybody know why is this and how I can fix it? Do I have use non-
    >> > conforming mode for every file that uses non-standard headers?

    >>
    >> Something in your code or build is broken.
    >>
    >> Post a short example with the errors you see and how you compiled it.
    >>

    >
    >Like I mentioned to Viza, they're macros in the system header files
    >that seem to be undefined when I invoke the compiler in conforming
    >mode. Here are the errors from the compiler:


    If you try to compile with std=C99, your program can _ONLY_ use c99 features.

    That means you cannot use getaddrinfo or sockets because they're not defined by
    c99.

    Why do you want to specify -std=c99, and did you read the gcc man page?

    scott

  7. Re: System headers, compiler conformance...

    s0suk3@gmail.com writes:
    >On Aug 8, 3:20=A0pm, viza
    >wrote:
    >> On Fri, 08 Aug 2008 12:08:45 -0700, s0suk3 wrote:
    >> > I have a C source file that includes several system header files (namel=

    >y
    >> > , , and ).
    >> > When I compile it by invoking the compiler in conforming mode, it
    >> > doesn't object to the inclusion of the headers, but it gives me errors
    >> > for every function, type, etc, that I use
    >> > when I compile it in non-conforming mode, it's All Good.

    >>
    >> Try using gcc -E to inspect the output of the pre-processor.
    >>
    >> $ cat foo.c
    >> #include
    >>
    >> $ gcc -E foo.c -o foo.cpp
    >> $ cat foo.cpp
    >> /* header.h header file */
    >>
    >> int foo(int);
    >>
    >> $
    >>
    >> See if the headers are there.
    >>
    >> It might be that they are included conditionally:
    >>
    >> #ifdef SOMETHING
    >>
    >> int foo(int);
    >>
    >> #endif
    >>
    >> in which case then the macro SOMETHING might not be defined in standard
    >> mode.

    >
    >You're right. Thanks. One macro that's conditioning-out something that
    >I need (the 'addrinfo' struct, and the getnameinfo() and
    >freeaddrinfo() funcs) is '__USE_POSIX', in the header. So I
    >could define this macro in my source, but I think there are other
    >things that are being conditioned-out, and going through all those
    >header files seems cumbersome, plus that doesn't seem like a good
    >solution anyway.
    >
    >The gcc flag I'm using is std=3Dc99. The code I have uses C99 features
    >that will be disabled if I don't use that flag. What do you suggest I
    >should do?
    >


    1) don't use the c99 features in question.

    2) from the gcc man page

    Even when this option is not specified, you can still use some of
    the features of newer standards in so far as they do not conflict
    with previous C standards. For example, you may use "__restrict__"
    even when -std=c99 is not specified.

  8. Re: System headers, compiler conformance...

    s0suk3@gmail.com wrote:
    > On Aug 8, 4:10 pm, Ian Collins wrote:
    >> s0suk3@gmail.com wrote:
    >>> Hi,
    >>> I have a C source file that includes several system header files
    >>> (namely , , and ). When
    >>> I compile it by invoking the compiler in conforming mode, it doesn't
    >>> object to the inclusion of the headers, but it gives me errors for
    >>> every function, type, etc, that I use that's supposed to be defined in
    >>> the header file, saying that it's undefined. (In other words, it acts
    >>> as though the header file didn't define anything.) But when I compile
    >>> it in non-conforming mode, it's All Good.
    >>> Does anybody know why is this and how I can fix it? Do I have use non-
    >>> conforming mode for every file that uses non-standard headers?

    >> Something in your code or build is broken.
    >>
    >> Post a short example with the errors you see and how you compiled it.
    >>

    >
    > Like I mentioned to Viza, they're macros in the system header files
    > that seem to be undefined when I invoke the compiler in conforming
    > mode. Here are the errors from the compiler:
    >

    Then add -D to your build line. It's odd that this should be
    happening.

    Try this:

    #include
    #include

    int main(void)
    {
    struct addrinfo hints;
    struct addrinfo* res;

    getaddrinfo( "host", "service", &hints, &res );
    }

    it compiles fine with gcc4 and Sun C99 on Solaris.

    --
    Ian Collins.

  9. Re: System headers, compiler conformance...

    On Fri, 08 Aug 2008 14:32:00 -0700, s0suk3 wrote:

    > The gcc flag I'm using is std=c99. The code I have uses C99 features
    > that will be disabled if I don't use that flag. What do you suggest I
    > should do?


    -std=gnu99

  10. Re: System headers, compiler conformance...

    Scott Lurndal wrote:
    >
    > If you try to compile with std=C99, your program can _ONLY_ use c99 features.
    >

    Utter nonsense.

    > That means you cannot use getaddrinfo or sockets because they're not defined by
    > c99.
    >

    Utter nonsense.

    They aren't defined by c90 either, they are declared in the appropriate
    system headers which the OP has included.

    > Why do you want to specify -std=c99, and did you read the gcc man page?
    >

    Probably stop gcc warning when invoked in C90 conforming mode.

    --
    Ian Collins.

  11. Re: System headers, compiler conformance...

    s0suk3@gmail.com writes:

    > On Aug 8, 3:20Â*pm, viza
    > wrote:
    >> On Fri, 08 Aug 2008 12:08:45 -0700, s0suk3 wrote:
    >> > I have a C source file that includes several system header files (namely
    >> > , , and ).
    >> > When I compile it by invoking the compiler in conforming mode, it
    >> > doesn't object to the inclusion of the headers, but it gives me errors
    >> > for every function, type, etc, that I use


    > The gcc flag I'm using is std=c99. The code I have uses C99 features
    > that will be disabled if I don't use that flag. What do you suggest I
    > should do?


    If you want POSIX functions (the most likely case) just add
    -D_POSIX_C_SOURCE to your compile line or CFLAGS makefile variable.
    The problem comes when you need a mix -- POSIXÂ*here, BSD there...

    man feature_test_macros

    for the most useful settings.

    --
    Ben.

  12. Re: System headers, compiler conformance...

    Ian Collins wrote:

    > it compiles fine with gcc4 and Sun C99 on Solaris.


    The source of the issue lies with the glibc headers. I suggest the OP read
    /usr/include/features.h. Immediately following the license boiler plate can
    be found concise documentation of glibc feature macros.

    An easy answer is to define _GNU_SOURCE, which throws in everything and the
    kitchen sink. Using the -std=gnu99 switch probably has the effect of
    defining _GNU_SOURCE as the default feature set, but then you've also
    enabled GCC compiler extensions, which may be undesirable.


  13. Re: System headers, compiler conformance...

    William Ahern wrote:
    > Ian Collins wrote:
    >
    >> it compiles fine with gcc4 and Sun C99 on Solaris.

    >
    > The source of the issue lies with the glibc headers. I suggest the OP read
    > /usr/include/features.h. Immediately following the license boiler plate can
    > be found concise documentation of glibc feature macros.
    >
    > An easy answer is to define _GNU_SOURCE, which throws in everything and the
    > kitchen sink. Using the -std=gnu99 switch probably has the effect of
    > defining _GNU_SOURCE as the default feature set, but then you've also
    > enabled GCC compiler extensions, which may be undesirable.
    >

    I see. So my original guess that something in the build process was
    broken was correct!

    --
    Ian Collins.

  14. Re: System headers, compiler conformance...

    Ian Collins writes:
    >Scott Lurndal wrote:
    >>
    >> If you try to compile with std=C99, your program can _ONLY_ use c99 features.
    >>

    >Utter nonsense.


    I was indeed mistaken. I assumed that std=c99 would prevent included
    headers from affecting the namespace, but that's only the case with
    header files defined by C99, not POSIX header files.

    $ cat /tmp/a.c
    #include

    int
    main(int ac, char **av)
    {
    char *a;

    a = tempnam(P_tmpdir, "tst");

    return 0;
    }

    $ cc -std=c99 -o /tmp/a /tmp/a.c
    /tmp/a.c: In function 'main':
    /tmp/a.c:8: warning: implicit declaration of function 'tempnam'
    /tmp/a.c:8: error: 'P_tmpdir' undeclared (first use in this function)
    /tmp/a.c:8: error: (Each undeclared identifier is reported only once
    /tmp/a.c:8: error: for each function it appears in.)
    /tmp/a.c:8: warning: assignment makes pointer from integer without a cast

    $ cc -o /tmp/a /tmp/a.c
    /tmp/ccGDDMT6.o: In function `main':
    a.c.text+0x1a): warning: the use of `tempnam' is dangerous, better use `mkstemp'

  15. Re: System headers, compiler conformance...

    On 8 Aug, 23:22, Ben Bacarisse wrote:

    > If you want POSIX functions (the most likely case) just add
    > -D_POSIX_C_SOURCE to your compile line or CFLAGS makefile variable.
    > The problem comes when you need a mix -- POSIX*here, BSD there...


    A couple of people have suggested defining _POSIX_C_SOURCE
    or _GNU_SOURCE or _XOPEN_SOURCE when invoking the
    compiler, but I think it is a better practice to #define it in
    the source code itself. If a.c contains code that relies on
    a particular standard then that standard should be specified
    in a.c before any #includes, not left until compiler invocation.
    This makes it clear to the maintainer looking at the file
    what assumptions are in place, and makes the build less fragile.
    Is there any good reason not to define the standard used
    directly in the source file?


  16. Re: System headers, compiler conformance...

    William Pursell writes:

    > On 8 Aug, 23:22, Ben Bacarisse wrote:
    >
    >> If you want POSIX functions (the most likely case) just add
    >> -D_POSIX_C_SOURCE to your compile line or CFLAGS makefile variable.
    >> The problem comes when you need a mix -- POSIXÂ*here, BSD there...

    >
    > A couple of people have suggested defining _POSIX_C_SOURCE
    > or _GNU_SOURCE or _XOPEN_SOURCE when invoking the
    > compiler, but I think it is a better practice to #define it in
    > the source code itself. If a.c contains code that relies on
    > a particular standard then that standard should be specified
    > in a.c before any #includes, not left until compiler invocation.
    > This makes it clear to the maintainer looking at the file
    > what assumptions are in place, and makes the build less fragile.
    > Is there any good reason not to define the standard used
    > directly in the source file?


    This is a good point and I don't really know if there is a best
    answer. If your code is built on lots of systems and compilers, it
    can be simpler to put the configuration in the make file, but if you
    use mainly one compiler/version then it is probably more robust to put
    the #define in the code itself.

    If the OP goes that route (direct definition in the source) it is wise
    to do it in an included "config.h" file so it can be changes for all
    source files in one edit.

    Of course, this is what automatic build and configuration are all
    about but they are often overkill for small programs. My answer was
    prompted only by "getting the thing to compile", not what the best way
    to define such options. I think you are correct that it is really a
    property of the code and belongs there.

    --
    Ben.

  17. Re: System headers, compiler conformance...

    William Pursell wrote:
    > On 8 Aug, 23:22, Ben Bacarisse wrote:
    >
    >> If you want POSIX functions (the most likely case) just add
    >> -D_POSIX_C_SOURCE to your compile line or CFLAGS makefile variable.
    >> The problem comes when you need a mix -- POSIX here, BSD there...

    >
    > A couple of people have suggested defining _POSIX_C_SOURCE
    > or _GNU_SOURCE or _XOPEN_SOURCE when invoking the
    > compiler, but I think it is a better practice to #define it in
    > the source code itself. If a.c contains code that relies on
    > a particular standard then that standard should be specified
    > in a.c before any #includes, not left until compiler invocation.
    > This makes it clear to the maintainer looking at the file
    > what assumptions are in place, and makes the build less fragile.
    > Is there any good reason not to define the standard used
    > directly in the source file?


    Counterarguments:

    1. _POSIX_C_SOURCE et al might be fine because they're standard, but
    _GNU_SOURCE is compiler-specific. If you build with non-gcc compilers on
    some platforms, or might switch compilers someday, having these in the
    source could be confusing. Conceivably they could even break something
    as another compiler suite is not required to avoid using _GNU_SOURCE for
    something else.

    2. If you do it this way you have to remember to make the entry in each
    source file, and if you forget in one it could take some time to track
    down the problem. Using a makefile or similar you can just say

    CFLAGS += -D_GNU_SOURCE

    and forget about it.

    I see it as a matter of taste with no right answer.

    HS

  18. Re: System headers, compiler conformance...

    On 9 Aug, 13:07, Harold Shand wrote:
    > William Pursell wrote:
    > > On 8 Aug, 23:22, Ben Bacarisse wrote:

    >
    > >> If you want POSIX functions (the most likely case) just add
    > >> -D_POSIX_C_SOURCE to your compile line or CFLAGS makefile variable.
    > >> The problem comes when you need a mix -- POSIX here, BSD there...

    >
    > > A couple of people have suggested defining _POSIX_C_SOURCE
    > > or _GNU_SOURCE or _XOPEN_SOURCE when invoking the
    > > compiler, but I think it is a better practice to #define it in
    > > the source code itself. *If a.c contains code that relies on
    > > a particular standard then that standard should be specified
    > > in a.c before any #includes, not left until compiler invocation.
    > > This makes it clear to the maintainer looking at the file
    > > what assumptions are in place, and makes the build less fragile.
    > > Is there any good reason not to define the standard used
    > > directly in the source file?

    >
    > Counterarguments:
    >
    > 1. _POSIX_C_SOURCE et al might be fine because they're standard, but
    > _GNU_SOURCE is compiler-specific. If you build with non-gcc compilers on
    > some platforms, or might switch compilers someday, having these in the
    > source could be confusing. Conceivably they could even break something
    > as another compiler suite is not required to avoid using _GNU_SOURCE for
    > something else.


    I would think that specifying _GNU_SOURCE in the source
    is less confusing since it implies that the developer assumes
    gcc will be used and thus makes no guarantees that another
    compiler will even work. If I wonder why code won't compile
    with icc and see _GNU_SOURCE on the first line of the source
    file, it's a pretty good clue.

    >
    > 2. If you do it this way you have to remember to make the entry in each
    > source file, and if you forget in one it could take some time to track
    > down the problem.


    You can certainly specify the standard in the project's common header,
    but this does point to another issue. Is it desirable to dictate a
    standard
    for the entire project? Say you have 2 source files in the project,
    and
    one of them uses nothing newer than 1989, while one uses gnu
    extensions. Should both be compiled with _GNU_SOURCE?
    I think not, since one might want to modify the code later to
    get away from the gnu extensions, and not defining _GNU_SOURCE
    for the one source file shows that no work is necessary. But it may
    be
    a little confusing to start having multiple standards being used
    in different parts of the project. This file is POSIX 1999, this one
    is XOPEN_SOURCE 500, this one is GNU, etc...

    Using a makefile or similar you can just say
    >
    > * * * * CFLAGS += -D_GNU_SOURCE
    >
    > and forget about it.


    Minor nit: make that CPPFLAGS


    > I see it as a matter of taste with no right answer.


    That is probably absolutely correct!


+ Reply to Thread