Re: is there anything unstandard in the c part here

Discussion in 'C Programming' started by Barry Schwarz, Jul 26, 2011.

  1. On Mon, 25 Jul 2011 17:45:57 -0600, Uno <> wrote:

    >I'm doing a mixed-language exercise, and C is the middle east as far as
    >that goes. So my listing is going to have non-standard parts, I'll put
    >them at the top, so that people who chaff at the site of another syntax
    >won't have to retreat to under their bridges.


    snip

    >
    >$ cat cfunc2.c
    >
    >
    >#include <sys/types.h>
    >#include <sys/stat.h>
    >#include <unistd.h>


    These are non-standard headers so you should be using the quotation
    mark syntax instead of the angle bracket syntax.

    >
    >#define RIGHT HERE
    >
    >#include <stdio.h>
    >#include <limits.h>
    >#include <stdlib.h>
    >#include <string.h>
    >
    >char * testc() {


    char *testc(void){
    just looks cleaner.

    >
    > char * pa;
    > pa = (char *)malloc (50);


    The cast serves no purpose.

    > if (pa == NULL)
    > {
    > printf ("malloc failed.\n");
    > exit (EXIT_FAILURE);
    > }
    > strcpy((char *)pa, "this sentence is less than fifty bytes.");


    This cast is redundant.

    >
    > return pa;
    >}
    >
    >// gcc -c -Wall -Wextra cfunc2.c -o cfunc.o
    >
    >I tried to follow Heathfield's development in chp 8 of _unleashed_ for
    >memory management. For obvious reason, I don't free what I've
    >malloc'ed, because then it would suck as a pass.
    >
    >Any comments about the code south of RIGHT HERE are welcome. Cheers,


    --
    Remove del for email
    Barry Schwarz, Jul 26, 2011
    #1
    1. Advertising

  2. Barry Schwarz wrote:
    > On Mon, 25 Jul 2011 17:45:57 -0600, Uno <> wrote:
    >
    >> I'm doing a mixed-language exercise, and C is the middle east as far as
    >> that goes. So my listing is going to have non-standard parts, I'll put
    >> them at the top, so that people who chaff at the site of another syntax
    >> won't have to retreat to under their bridges.

    >
    > snip
    >
    >> $ cat cfunc2.c
    >>
    >>
    >> #include <sys/types.h>
    >> #include <sys/stat.h>
    >> #include <unistd.h>

    >
    > These are non-standard headers so you should be using the quotation
    > mark syntax instead of the angle bracket syntax.


    That's not correct. Since these headers are not part of the C Standard,
    C doesn't care which form of #include is used. As it happens, these are
    POSIX headers, and the POSIX standard requires the form used here.
    J. J. Farrell, Jul 26, 2011
    #2
    1. Advertising

  3. Barry Schwarz

    Seebs Guest

    On 2011-07-26, Barry Schwarz <> wrote:
    >>#include <sys/types.h>
    >>#include <sys/stat.h>
    >>#include <unistd.h>


    > These are non-standard headers so you should be using the quotation
    > mark syntax instead of the angle bracket syntax.


    I would strongly disagree with this. If headers are part of the local
    system's implementation, rather than user-provided, they should be in
    angle brackets. Quotes aren't for "stuff that isn't 100% specified by
    ISO C", but for "stuff I am providing rather than my environment".

    -s
    --
    Copyright 2011, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
    Seebs, Jul 26, 2011
    #3
  4. On Jul 26, 7:17 am, Seebs <> wrote:
    > On 2011-07-26, Barry Schwarz <> wrote:
    >
    > >>#include <sys/types.h>
    > >>#include <sys/stat.h>
    > >>#include <unistd.h>

    > > These are non-standard headers so you should be using the quotation
    > > mark syntax instead of the angle bracket syntax.

    >
    > I would strongly disagree with this.  If headers are part of the local
    > system's implementation, rather than user-provided, they should be in
    > angle brackets.  Quotes aren't for "stuff that isn't 100% specified by
    > ISO C", but for "stuff I am providing rather than my environment".


    yes but unix seems to disagree with you
    Nick Keighley, Jul 26, 2011
    #4
  5. On Jul 26, 9:03 am, Nick Keighley <>
    wrote:
    > On Jul 26, 7:17 am, Seebs <> wrote:
    >
    > > On 2011-07-26, Barry Schwarz <> wrote:

    >
    > > >>#include <sys/types.h>
    > > >>#include <sys/stat.h>
    > > >>#include <unistd.h>
    > > > These are non-standard headers so you should be using the quotation
    > > > mark syntax instead of the angle bracket syntax.

    >
    > > I would strongly disagree with this.  If headers are part of the local
    > > system's implementation, rather than user-provided, they should be in
    > > angle brackets.  Quotes aren't for "stuff that isn't 100% specified by
    > > ISO C", but for "stuff I am providing rather than my environment".

    >
    > yes but unix seems to disagree with you


    ?

    Please elaborate.
    Kleuskes & Moos, Jul 26, 2011
    #5
  6. Barry Schwarz

    Ian Collins Guest

    On 07/26/11 07:03 PM, Nick Keighley wrote:
    > On Jul 26, 7:17 am, Seebs<> wrote:
    >> On 2011-07-26, Barry Schwarz<> wrote:
    >>
    >>>> #include<sys/types.h>
    >>>> #include<sys/stat.h>
    >>>> #include<unistd.h>
    >>> These are non-standard headers so you should be using the quotation
    >>> mark syntax instead of the angle bracket syntax.

    >>
    >> I would strongly disagree with this. If headers are part of the local
    >> system's implementation, rather than user-provided, they should be in
    >> angle brackets. Quotes aren't for "stuff that isn't 100% specified by
    >> ISO C", but for "stuff I am providing rather than my environment".

    >
    > yes but unix seems to disagree with you


    How?

    --
    Ian Collins
    Ian Collins, Jul 26, 2011
    #6
  7. Barry Schwarz

    Seebs Guest

    On 2011-07-26, Nick Keighley <> wrote:
    > On Jul 26, 7:17?am, Seebs <> wrote:
    >> On 2011-07-26, Barry Schwarz <> wrote:
    >> I would strongly disagree with this. ?If headers are part of the local
    >> system's implementation, rather than user-provided, they should be in
    >> angle brackets. ?Quotes aren't for "stuff that isn't 100% specified by
    >> ISO C", but for "stuff I am providing rather than my environment".


    > yes but unix seems to disagree with you


    Huh?

    I've yet to see a Unix system not advocate <>s for the Unixy headers like
    unistd.h and sys/*.h. I assume Windows is the same, and so on.

    -s
    --
    Copyright 2011, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
    Seebs, Jul 26, 2011
    #7
  8. On Jul 26, 8:56 am, Seebs <> wrote:
    > On 2011-07-26, Nick Keighley <> wrote:
    >
    > > On Jul 26, 7:17?am, Seebs <> wrote:
    > >> On 2011-07-26, Barry Schwarz <> wrote:


    > >> I would strongly disagree with this. ?If headers are part of the local
    > >> system's implementation, rather than user-provided, they should be in
    > >> angle brackets. ?Quotes aren't for "stuff that isn't 100% specified by
    > >> ISO C", but for "stuff I am providing rather than my environment".

    >
    > > yes but unix seems to disagree with you

    >
    > Huh?
    >
    > I've yet to see a Unix system not advocate <>s for the Unixy headers like
    > unistd.h and sys/*.h.  I assume Windows is the same, and so on.


    oops sorry! I misread the original post! *I* think things that are NOT
    in the standard C++ (or C) should NOT be in angle brackets. Both unix
    and windows disagree with my opinion.

    Personnally I think this blurs the definition of environment. When is
    a third party library "provided by the environemnt" and when is it
    "provided by me"?
    Nick Keighley, Jul 26, 2011
    #8
  9. Barry Schwarz

    Angel Guest

    On 2011-07-26, Nick Keighley <> wrote:
    > On Jul 26, 7:17?am, Seebs <> wrote:
    >> On 2011-07-26, Barry Schwarz <> wrote:
    >>
    >> >>#include <sys/types.h>
    >> >>#include <sys/stat.h>
    >> >>#include <unistd.h>
    >> > These are non-standard headers so you should be using the quotation
    >> > mark syntax instead of the angle bracket syntax.

    >>
    >> I would strongly disagree with this. ?If headers are part of the local
    >> system's implementation, rather than user-provided, they should be in
    >> angle brackets. ?Quotes aren't for "stuff that isn't 100% specified by
    >> ISO C", but for "stuff I am providing rather than my environment".

    >
    > yes but unix seems to disagree with you


    ???

    From the manual page of the Unix system call open():


    NAME
    open, creat - open and possibly create a file or device

    SYNOPSIS
    #include <sys/types.h>
    #include <sys/stat.h>
    #include <fcntl.h>

    [...]


    --
    "C provides a programmer with more than enough rope to hang himself.
    C++ provides a firing squad, blindfold and last cigarette."
    - seen in comp.lang.c
    Angel, Jul 26, 2011
    #9
  10. Barry Schwarz

    Angel Guest

    On 2011-07-26, Nick Keighley <> wrote:
    > On Jul 26, 8:56?am, Seebs <> wrote:
    >>
    >> Huh?
    >>
    >> I've yet to see a Unix system not advocate <>s for the Unixy headers like
    >> unistd.h and sys/*.h. ?I assume Windows is the same, and so on.

    >
    > oops sorry! I misread the original post! *I* think things that are NOT
    > in the standard C++ (or C) should NOT be in angle brackets. Both unix
    > and windows disagree with my opinion.
    >
    > Personnally I think this blurs the definition of environment. When is
    > a third party library "provided by the environemnt" and when is it
    > "provided by me"?


    The line is a bit blurry of course, but consider where the library is
    located. Is it part of your source code? Then it's provided by you and
    "" should be used. If it is in a place that has nothing to do with your
    source code, then it's provided by the environment.

    I'm not sure about other implementations, but on Unix, <> will look only
    in implementation-defined places (usually /usr/include) while "" will
    look in the current directory first.


    --
    "C provides a programmer with more than enough rope to hang himself.
    C++ provides a firing squad, blindfold and last cigarette."
    - seen in comp.lang.c
    Angel, Jul 26, 2011
    #10
  11. Barry Schwarz

    Seebs Guest

    On 2011-07-26, Nick Keighley <> wrote:
    > oops sorry! I misread the original post! *I* think things that are NOT
    > in the standard C++ (or C) should NOT be in angle brackets. Both unix
    > and windows disagree with my opinion.


    I think I do too.

    > Personnally I think this blurs the definition of environment. When is
    > a third party library "provided by the environemnt" and when is it
    > "provided by me"?


    This is all "implementation-defined". To oversimplify standard Unix
    considerably:

    /usr/include/foo.h => <foo.h>
    ./foo.h => "foo.h"

    The basic idea is, if something is in the place where the compiler
    automatically looks for all headers, it's <header.h>, and if it's somewhere
    else (usually the current directory), it's "header.h". This makes it
    easy to decide; if I just wrote "foo.h", and it's in this directory, it gets
    double quotes, if I expect "foo.h" to exist without this program having
    to do anything specific about it, it gets angle brackets.

    It might have been nice to have a third delimiter available so we could
    distinguish between "language base" and "local extensions", but that was not
    the way it was done. The fact is, though, by the time the ANSI/ISO people
    got involved, it had been <sys/types.h> for over a decade.

    -s
    --
    Copyright 2011, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
    Seebs, Jul 26, 2011
    #11
  12. Barry Schwarz

    Nobody Guest

    On Tue, 26 Jul 2011 04:50:58 -0700, Nick Keighley wrote:

    > oops sorry! I misread the original post! *I* think things that are NOT
    > in the standard C++ (or C) should NOT be in angle brackets. Both unix
    > and windows disagree with my opinion.
    >
    > Personnally I think this blurs the definition of environment. When is
    > a third party library "provided by the environemnt" and when is it
    > "provided by me"?


    The C standard only says that using quotes results in the preprocessor
    searching for the header file in additional (implementation-defined)
    locations prior to the locations which are searched when angle brackets
    are used.

    "Typical" compiler behaviour when quotes are used is to search for the
    header relative to the directory containing the source file. IOW, quotes
    are intended for headers which are "part of" the program being compiled,
    while angle brackets are for anything which is "external"

    This means that you don't have to worry about "local" headers conflicting
    with "installed" headers, as installed headers will be included using
    angle brackets, and won't be searched for in the program's source
    directory.

    In large projects with multiple, distinct components, angle brackets may
    be used for headers belonging to a different component. In general, if the
    header is going to be installed as part of the "package", you have to
    choose a name which won't conflict with any other installed package. OTOH,
    if the header is "internal" and won't be installed, the name only needs to
    be locally unique; including the header using quotes will ensure that it
    gets used in spite of any external header of the same name.
    Nobody, Jul 27, 2011
    #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. Mano kumar
    Replies:
    2
    Views:
    356
    Kevin Spencer
    Oct 17, 2003
  2. Replies:
    10
    Views:
    1,334
    Malte
    Jun 30, 2005
  3. Replies:
    5
    Views:
    504
  4. John Gordon
    Replies:
    70
    Views:
    1,363
    J. J. Farrell
    Aug 14, 2011
  5. Nick Keighley

    Re: is there anything unstandard in the c part here

    Nick Keighley, Jul 26, 2011, in forum: C Programming
    Replies:
    16
    Views:
    555
    Ike Naar
    Aug 1, 2011
Loading...

Share This Page