Re: using structures

Discussion in 'C Programming' started by Jack Klein, Aug 18, 2003.

  1. Jack Klein

    Jack Klein Guest

    On Sun, 17 Aug 2003 16:43:54 +0200, Irrwahn Grausewitz
    <> wrote in comp.std.c:

    Followup set to comp.lang.c, where this really belongs.

    > (ambika) wrote in
    > <>:


    [snip]

    > So, the whole thing corrected goes like this:
    >
    > //*************************************************


    Not many compilers claim conformance with the current version of the C
    standard yet. The line above is an error, not a single line comment,
    under the version of the standard most compilers available today claim
    to conform to.

    > #include <stdio.h>
    > #include <stdlib.h>
    >
    > struct h
    > {
    > int data;
    > };
    >
    > int main()
    > {
    > struct h *p, *n;
    >
    > p = (struct h*) malloc( sizeof (struct h) );
    > n = (struct h*) malloc( sizeof (struct h) );


    This style of calling malloc() is frowned upon by most experienced C
    programmers, including the majority of comp.lang.c regulars. The cast
    could hide a serious error if the OP forgot to take your advice and
    did not include <stdlib.h>. And the use of type names as arguments to
    the sizeof operator can make for a lot of editing effort if the type
    changes. The recommended version is:

    p = malloc(sizeof *p);

    Now if the type of p is ever changed, say to point to a larger
    structure that includes a struct h, the code does not need editing and
    automatically remains correct.

    > if ( ( p == NULL ) || ( n == NULL ) )
    > return EXIT_FAILURE;
    >
    > p->data=20;
    > n->data=10;
    >
    > printf("\nValue of data pointed by p is %d",p->data);
    > printf("\nValue of data pointed by n is %d",n->data);
    > printf("\nlocation pointed by p is %p",&p->data);
    > printf("\nlocation pointed by n is %p\n",&n->data);


    The last two printf() calls above still invoke undefined behavior.
    The "%p" conversion specifier to any of the *printf() functions
    requires a corresponding argument of type "pointer to void".

    To eliminate the undefined behavior:

    printf("\nlocation pointed by p is %p",(void *)(&p->data));
    printf("\nlocation pointed by n is %p\n",(void *)(&n->data));

    > getchar();
    >
    > return EXIT_SUCCESS;


    Really, return 0; would be just fine here.

    > }


    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c /faq
    Jack Klein, Aug 18, 2003
    #1
    1. Advertising

  2. Jack Klein wrote:

    > Irrwahn Grausewitz wrote:
    >
    >> #include <stdio.h>
    >> #include <stdlib.h>
    >>
    >> typedef struct h {
    >> int data;
    >> } h;
    >>
    >> int main(int argc, char* argv[]) {
    >>
    >> h* p = (h*)malloc(sizeof(h));
    >> h* n = (h*)malloc(sizeof(h));

    >
    > This style of calling malloc() is frowned upon by most experienced C
    > programmers, including the majority of comp.lang.c regulars. The cast
    > could hide a serious error if the OP forgot to take your advice and
    > did not include <stdlib.h>. And the use of type names as arguments to
    > the sizeof operator can make for a lot of editing effort if the type
    > changes. The recommended version is:
    >
    > h* p = malloc(sizeof *p);
    >
    > Now if the type of p is ever changed,
    > say to point to a larger structure that includes a struct h,
    > the code does not need editing and automatically remains correct.
    >
    >> if ((NULL == p) || (NULL == n))
    >> return EXIT_FAILURE;
    >>
    >> p->data = 20;
    >> n->data = 10;
    >>
    >> fprintf(stdout, "Value of data pointed by p is %d\n", p->data);
    >> fprintf(stdout, "Value of data pointed by n is %d\n", n->data);
    >> fprintf(stdout, "location pointed by p is %p\n", &p->data);
    >> fprintf(stdout, "location pointed by n is %p\n", &n->data);

    >
    > The last two fprintf() calls above still invoke undefined behavior.
    > The "%p" conversion specifier to any of the *fprintf() functions
    > requires a corresponding argument of type "pointer to void".
    >
    > To eliminate the undefined behavior:
    >
    > fprintf(stdout, "location pointed by p is %p\n", (void*)(&p->data));
    > fprintf(stdout, "location pointed by n is %p\n", (void*)(&n->data));
    >
    >> getchar();
    >>
    >> return EXIT_SUCCESS;

    >
    > Really, return 0; would be just fine here.
    >
    >> }
    E. Robert Tisdale, Aug 18, 2003
    #2
    1. Advertising

  3. Jack Klein wrote:
    >>//*************************************************

    > Not many compilers claim conformance with the current version of the C
    > standard yet. The line above is an error, not a single line comment,
    > under the version of the standard most compilers available today claim
    > to conform to.


    There are now several compilers that claim conformance to C99,
    or conformance with minor documented exceptions.

    For a compiler that doesn't grok //-comments, the above is
    likely to be a / token followed by a blank that spans through
    the end of the next */ characters.

    > The "%p" conversion specifier to any of the *printf() functions
    > requires a corresponding argument of type "pointer to void".


    And the reason that it requires a cast is that printf is
    a variadic function whose argument types are not declared
    in the prototype. For many other functions (e.g. free)
    the pointer conversion to void* would be automatic when
    the prototype is visible.
    Douglas A. Gwyn, Aug 18, 2003
    #3
  4. Jack Klein <> wrote in
    <>:

    <BIIIIG SNIP>

    All points taken.
    Yesterday was my "quick'n'dirty" day. Hope I didn't mess
    up things too bad for the OP.

    Irrwahn
    --
    Proofread carefully to see if you any words out.
    Irrwahn Grausewitz, Aug 18, 2003
    #4
  5. Jack Klein <> wrote in message news:<>...
    > > //*************************************************

    >
    > Not many compilers claim conformance with the current version of the C
    > standard yet. The line above is an error, not a single line comment,
    > under the version of the standard most compilers available today claim
    > to conform to.


    Ignore this person. "//" comments are acceptable in C code. Any
    compiler that doesn't accept "//" will fail to compile a large amount
    of C code.

    Sam
    Samuel Barber, Aug 18, 2003
    #5
  6. Jack Klein

    Sven Semmler Guest

    Samuel Barber wrote:
    > Jack Klein wrote:
    > > > //*************************************************

    > >
    > > Not many compilers claim conformance with the current version of the C
    > > standard yet. The line above is an error, not a single line comment,
    > > under the version of the standard most compilers available today claim
    > > to conform to.

    >
    > Ignore this person. "//" comments are acceptable in C code. Any compiler
    > that doesn't accept "//" will fail to compile a large amount of C code.


    You should be ignored.

    "//" is supported since C99, every C standard before that does not know
    it. So if your program targets the C99 standard "//" is okay, if it
    targets any previous it is not okay.

    "large amount of C code" does not say anything about the standard, so
    please stop confusing the tenderfoots.

    /Sven

    --
    Sven Semmler http://www.semmlerconsulting.com/
    GPG Fingerprint: 72CA E26D C2A3 1FEB 7AFC 10EA F769 A9A4 937F 5E67
    Sven Semmler, Aug 18, 2003
    #6
  7. Jack Klein

    Randy Howard Guest

    In article <>,
    says...
    > Jack Klein <> wrote in message news:<>...
    > > > //*************************************************

    > >
    > > Not many compilers claim conformance with the current version of the C
    > > standard yet. The line above is an error, not a single line comment,
    > > under the version of the standard most compilers available today claim
    > > to conform to.

    >
    > Ignore this person.


    Ignore Jack Klein, and listen to you instead? You must be joking.
    Randy Howard, Aug 18, 2003
    #7
  8. Jack Klein

    Dave Hansen Guest

    On 18 Aug 2003 10:57:58 -0700, (James Kuyper) wrote:

    > (Samuel Barber) wrote in message news:<>...

    [...]
    >> ... Any
    >> compiler that doesn't accept "//" will fail to compile a large amount
    >> of C code.

    >
    >I believe that you're wrong; there's only a small, but increasing,
    >amount of C code that relies upon C99 features. However, I have no
    >good idea of how to prove that. It's more nearly correct to say the
    >reverse: Any code that relies upon "//" comments will fail to compile
    >on most C compilers.


    Of the various C compilers I've used between 1984 and the present,
    exactly two failed to support "//" comments. One was DEC C for
    VAX/VMS in 1984. The other was a version of gcc targetting the i960
    that accepted "//" without generating any warnings or errors, but
    generated faulty code.

    The "//" comment form has several advantages over the "/**/" form, and
    perhaps one disadvantage (backslash-newline continues the comment to
    the next line). It has appeared in much of the code I've worked on
    over the past 15 years, and not just code I wrote -- libraries, vendor
    examples, existing code at new job sites, etc. Furthermore, it is --
    well, maybe not trivial, but simple -- to write a filter that converts
    "//" comments into the "/**/" form.

    So, modulo your definition of "C code" and "large," the original claim
    ("Any compiler that doesn't accept "//" will fail to compile a large
    amount of C code") seems valid, and your "reverse" seems false.

    I agree, though, that any code that relies upon "//" comments will
    fail to compile on any C89-compliant implementation. And any
    implementation that accepts "//" comments is not C89-compliant.

    Regards,

    -=Dave
    --
    Change is inevitable, progress is not.
    Dave Hansen, Aug 18, 2003
    #8
  9. Jack Klein

    Jack Klein Guest

    On Mon, 18 Aug 2003 19:12:56 GMT, (Dave Hansen) wrote
    in comp.lang.c:

    > On 18 Aug 2003 10:57:58 -0700, (James Kuyper) wrote:
    >
    > > (Samuel Barber) wrote in message news:<>...

    > [...]
    > >> ... Any
    > >> compiler that doesn't accept "//" will fail to compile a large amount
    > >> of C code.

    > >
    > >I believe that you're wrong; there's only a small, but increasing,
    > >amount of C code that relies upon C99 features. However, I have no
    > >good idea of how to prove that. It's more nearly correct to say the
    > >reverse: Any code that relies upon "//" comments will fail to compile
    > >on most C compilers.

    >
    > Of the various C compilers I've used between 1984 and the present,
    > exactly two failed to support "//" comments. One was DEC C for
    > VAX/VMS in 1984. The other was a version of gcc targetting the i960
    > that accepted "//" without generating any warnings or errors, but
    > generated faulty code.


    I remember one particular compiler from a major vendor that accepted
    "//" comments and only got them wrong in very subtle cases.

    As for how many pre-C99 compilers actually accept this, it might well
    depend on how you invoke them, since most compilers are not standard
    conforming by default.

    The industry I am in requires, by law, that we provide support,
    service, parts, and potentially code defect fixes for a product for 10
    years AFTER we withdraw the product from the market. I have one such
    product that will still be sold for at least another two years whose
    compiler will not accept them at all, under any circumstances.

    In addition there are a large number of current C compilers that will
    not accept them if invoked in standard conforming mode, which is how
    we compile our code. There are occasional circumstances where certain
    platform-specific features must be compiled in another mode. Each
    such instance requires a sign-off by me.

    > The "//" comment form has several advantages over the "/**/" form, and
    > perhaps one disadvantage (backslash-newline continues the comment to
    > the next line). It has appeared in much of the code I've worked on
    > over the past 15 years, and not just code I wrote -- libraries, vendor
    > examples, existing code at new job sites, etc. Furthermore, it is --
    > well, maybe not trivial, but simple -- to write a filter that converts
    > "//" comments into the "/**/" form.


    Funny you should say that. I have a brand spanking new compiler from
    one of the world's largest IC manufacturers for one of their brand new
    processors. It comes with a dozen or so headers providing easy access
    from C for a variety of peripherals on-chip, such as the memory
    management unit, processor clock PLL, and such like.

    The headers are littered with "//" comments, and will not compile with
    their own compiler set to <sic>"ANSI strict" mode.

    It took me all of about 5 minutes to whip up an admittedly non-robust
    program to convert them to /* */ comments, and now all but one of them
    (which uses an extended keyword "interrupt") compile in strict
    standard mode just fine.

    > So, modulo your definition of "C code" and "large," the original claim
    > ("Any compiler that doesn't accept "//" will fail to compile a large
    > amount of C code") seems valid, and your "reverse" seems false.
    >
    > I agree, though, that any code that relies upon "//" comments will
    > fail to compile on any C89-compliant implementation. And any
    > implementation that accepts "//" comments is not C89-compliant.
    >
    > Regards,
    >
    > -=Dave


    Actually if you review the definitions of what a strictly conforming
    application is allowed to do, it would be possible to accept //
    comments as an extension without violating conformance. It would be
    quite difficult, because you would have to specifically recognize the
    pathological cases where accepting them could break the translation of
    a strictly conforming program.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c /faq
    Jack Klein, Aug 19, 2003
    #9
  10. Stewart Brodie wrote:
    > '//' comments are NOT acceptable in C code that is going to be
    > compiled by a compiler which conforms to a pre-C99 standard.


    Not only that, but one can come up with an example of a
    valid (strictly conforming) C89 program that is
    incorrectly interpreted as a different program (with
    different output) if // is taken as starting a comment.
    Douglas A. Gwyn, Aug 19, 2003
    #10
  11. Dave Hansen wrote:
    > well, maybe not trivial, but simple -- to write a filter that converts
    > "//" comments into the "/**/" form.


    Indeed, I had to do that just before I left Geotronics,
    because they were acquiring a VAX Unix system that didn't
    support //-comments (which I had added support for in our
    PDP-11 Unix compiler and preprocessor). I coded it as a
    state machine; there were maybe a dozen states required.

    > I agree, though, that any code that relies upon "//" comments will
    > fail to compile on any C89-compliant implementation. And any
    > implementation that accepts "//" comments is not C89-compliant.


    Actually an implementation that accepts //-comments with
    an advisory message such as "thanks for using // comments"
    can be conforming *if* it handles the //* case correctly.
    Douglas A. Gwyn, Aug 19, 2003
    #11
  12. Jack Klein

    James Kuyper Guest

    (Dave Hansen) wrote in message news:<>...
    > On 18 Aug 2003 10:57:58 -0700, (James Kuyper) wrote:
    >
    > > (Samuel Barber) wrote in message news:<>...

    > [...]
    > >> ... Any
    > >> compiler that doesn't accept "//" will fail to compile a large amount
    > >> of C code.

    > >
    > >I believe that you're wrong; there's only a small, but increasing,
    > >amount of C code that relies upon C99 features. However, I have no
    > >good idea of how to prove that. It's more nearly correct to say the
    > >reverse: Any code that relies upon "//" comments will fail to compile
    > >on most C compilers.

    >
    > Of the various C compilers I've used between 1984 and the present,
    > exactly two failed to support "//" comments. One was DEC C for
    > VAX/VMS in 1984. The other was a version of gcc targetting the i960
    > that accepted "//" without generating any warnings or errors, but
    > generated faulty code.


    I use two compilers at work. The IRIX compiler in default mode does
    not accept "//".

    The Gnu compiler (version 3.0.1) accepts it in default mode as an
    extension to C90, but not in -ansi mode. The default meaning of -ansi
    on that compiler is C90, not C99. It's C99 mode is not fully
    conforming, even when all relevant options are selected appropriately.
    Don't tell me that the newest version has different behavior; our
    system is far from being the only one to be running a few years behind
    on updates. Every compiler update is a major shakeup for our system,
    and we therefore make updates only when we have to, just like a great
    many other people.

    > The "//" comment form has several advantages over the "/**/" form, and
    > perhaps one disadvantage (backslash-newline continues the comment to
    > the next line). It has appeared in much of the code I've worked on
    > over the past 15 years, and not just code I wrote -- libraries, vendor
    > examples, existing code at new job sites, etc. Furthermore, it is --
    > well, maybe not trivial, but simple -- to write a filter that converts
    > "//" comments into the "/**/" form.


    It doesn't occur anywhere in any of the millions of lines of delivered
    C code that constitute the project I work on. That may have something
    to do with the fact that we're contractually obligated to provide C90
    code. :) I doubt that we're the only contractor similarly constrained
    by NASA's conservatism.
    James Kuyper, Aug 19, 2003
    #12
  13. Jack Klein

    Ben Pfaff Guest

    Jan Engelhardt <> writes:

    > Possibly an advantage of /**/:
    > - it is supported in C++


    So is //.
    --
    "I ran it on my DeathStation 9000 and demons flew out of my nose." --Kaz
    Ben Pfaff, Aug 19, 2003
    #13
  14. >> Possibly an advantage of /**/:
    >> - it is supported in C++

    >
    >So is //.


    My rows meant: in C++ you have both, in C (per standard) only /**/.

    --
    - Jan Engelhardt
    Jan Engelhardt, Aug 20, 2003
    #14
  15. Jack Klein

    James Kuyper Guest

    Jan Engelhardt <> wrote in message news:<>...
    > >> Possibly an advantage of /**/:
    > >> - it is supported in C++

    > >
    > >So is //.

    >
    > My rows meant: in C++ you have both, in C (per standard) only /**/.


    Incorrect: the C standard also allows //.

    The previous version of the C standard didn't support it. Lots of
    compilers still implementat the old standard by default. That is an
    advantage of "/**/" over "//". Being supported by C++ is NOT an
    advantage that "/**/" has over "//", since both of them are supported
    by both C99 and C++.
    James Kuyper, Aug 20, 2003
    #15
  16. James Kuyper wrote:

    > Jan Engelhardt <> wrote in message news:<>...
    >
    >>>>Possibly an advantage of /**/:
    >>>>- it is supported in C++
    >>>
    >>>So is //.

    >>
    >>My rows meant: in C++ you have both, in C (per standard) only /**/.

    >
    >
    > Incorrect: the C standard also allows //.
    >
    > The previous version of the C standard didn't support it. Lots of
    > compilers still implementat the old standard by default. That is an
    > advantage of "/**/" over "//". Being supported by C++ is NOT an
    > advantage that "/**/" has over "//", since both of them are supported
    > by both C99 and C++.


    The obvious advantage in newgroups is that '/* ... */' comments don't get
    munged.


    --
    Martin Ambuhl
    Martin Ambuhl, Aug 20, 2003
    #16
    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. Ganesh Gella

    Xalan using generic DOM structures..

    Ganesh Gella, Oct 25, 2004, in forum: XML
    Replies:
    7
    Views:
    574
    Ganesh Gella
    Nov 10, 2004
  2. ES Kim
    Replies:
    0
    Views:
    467
    ES Kim
    Aug 19, 2003
  3. Vivek
    Replies:
    1
    Views:
    483
    John Harrison
    Aug 19, 2003
  4. tweak
    Replies:
    14
    Views:
    2,760
    Eric Sosman
    Jun 11, 2004
  5. Alfonso Morra
    Replies:
    11
    Views:
    701
    Emmanuel Delahaye
    Sep 24, 2005
Loading...

Share This Page