Structure members and reserved identifiers

Discussion in 'C Programming' started by Bas Wassink, Jun 26, 2007.

  1. Bas Wassink

    Bas Wassink Guest

    Hello all,

    I've been wondering about struct member names and reserved identifiers
    for some time now and I can't figure out whether the reserved identifier
    restrictions apply to struct members.

    I think the following is allowed:

    struct foo {
    unsigned char *memory;
    };

    Since struct members are in a different namespace from (than?) function
    names, the member name 'memory' would not invade the implementations
    namespace 'mem[a-z]*'.

    Until now I've refrained from using member names such as 'string' and
    'memory', just to be on the safe side, but sometimes such names are the
    most descriptive for the data they represent.

    I've been reading through the standard (n1124 draft) and my books on C
    (K&R2 and 'Expert C Programming' by Peter van der Linden) but I can't
    find a satisfactory answer.


    So if anyone could shed some light on this issue, I would be much obliged,

    Bas Wassink
     
    Bas Wassink, Jun 26, 2007
    #1
    1. Advertising

  2. Bas Wassink said:

    > Hello all,
    >
    > I've been wondering about struct member names and reserved identifiers
    > for some time now and I can't figure out whether the reserved
    > identifier restrictions apply to struct members.


    They don't (although I'd still steer clear of keywords if I were you!).

    The crux is that the kind of names you're (laudably) worrying about,
    str*, mem*, to*, is*, and so on, are reserved for use as ***external
    identifiers***. Each struct carries its own name space around, so
    you're okay with a struct member called 'memory' (or indeed 'member').
    You can also have struct members called 'towel', 'isobar', and
    'strange_attractor' if you like.

    The relevant text in C89 begins with:

    4.13 FUTURE LIBRARY DIRECTIONS

    The following names are grouped under individual headers for
    convenience. All external names described below are reserved no
    matter what headers are included by the program.

    The relevant text in C99 begins with:

    7.26 Future library directions

    1 The following names are grouped under individual headers for
    convenience. All external names described below are reserved no matter
    what headers are included by the program.



    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Jun 26, 2007
    #2
    1. Advertising

  3. Bas Wassink

    Bas Wassink Guest

    On Tue, 26 Jun 2007 08:43:10 +0000, Richard Heathfield wrote:

    > Bas Wassink said:
    >
    >> Hello all,
    >>
    >> I've been wondering about struct member names and reserved identifiers
    >> for some time now and I can't figure out whether the reserved
    >> identifier restrictions apply to struct members.

    >
    > They don't (although I'd still steer clear of keywords if I were you!).


    I certainly won't use those as member names, that would only cause
    confusion.

    > The crux is that the kind of names you're (laudably) worrying about,
    > str*, mem*, to*, is*, and so on, are reserved for use as ***external
    > identifiers***. Each struct carries its own name space around, so you're
    > okay with a struct member called 'memory' (or indeed 'member'). You can
    > also have struct members called 'towel', 'isobar', and
    > 'strange_attractor' if you like.
    >
    > The relevant text in C89 begins with:
    >
    > 4.13 FUTURE LIBRARY DIRECTIONS
    >
    > The following names are grouped under individual headers for
    > convenience. All external names described below are reserved no matter
    > what headers are included by the program.
    >
    > The relevant text in C99 begins with:
    >
    > 7.26 Future library directions
    >
    > 1 The following names are grouped under individual headers for
    > convenience. All external names described below are reserved no matter
    > what headers are included by the program.


    Right, the word *external* in those sections lead me to believe I could
    indeed use things like 'string' and 'token' as struct member names, but I
    wanted to be sure, that's why I thought I'd ask the experts.

    Thank you very much,

    Bas Wassink
     
    Bas Wassink, Jun 26, 2007
    #3
  4. Bas Wassink

    Dave Hansen Guest

    On Jun 26, 3:43 am, Richard Heathfield <> wrote:
    > Bas Wassink said:
    >
    > > Hello all,

    >
    > > I've been wondering about struct member names and reserved identifiers
    > > for some time now and I can't figure out whether the reserved
    > > identifier restrictions apply to struct members.

    >
    > They don't (although I'd still steer clear of keywords if I were you!).
    >
    > The crux is that the kind of names you're (laudably) worrying about,
    > str*, mem*, to*, is*, and so on, are reserved for use as ***external
    > identifiers***. Each struct carries its own name space around, so
    > you're okay with a struct member called 'memory' (or indeed 'member').
    > You can also have struct members called 'towel', 'isobar', and
    > 'strange_attractor' if you like.
    >


    But beware of reserved macro names if the associated header is
    included. Macros don't respect namespaces.

    Regards,

    -=Dave
     
    Dave Hansen, Jun 26, 2007
    #4
  5. Dave Hansen <> writes:
    > On Jun 26, 3:43 am, Richard Heathfield <> wrote:
    >> Bas Wassink said:
    >> > I've been wondering about struct member names and reserved identifiers
    >> > for some time now and I can't figure out whether the reserved
    >> > identifier restrictions apply to struct members.

    >>
    >> They don't (although I'd still steer clear of keywords if I were you!).
    >>
    >> The crux is that the kind of names you're (laudably) worrying about,
    >> str*, mem*, to*, is*, and so on, are reserved for use as ***external
    >> identifiers***. Each struct carries its own name space around, so
    >> you're okay with a struct member called 'memory' (or indeed 'member').
    >> You can also have struct members called 'towel', 'isobar', and
    >> 'strange_attractor' if you like.

    >
    > But beware of reserved macro names if the associated header is
    > included. Macros don't respect namespaces.


    Right, but if mem* and friends are defined as macros, they're defined
    as function-like macros.

    But you can still run into problems if you use one of those identifers
    as a member name, if the member is a function pointer. For example:

    #include <string.h>
    /* Assume the implementation defines a function memfoo(), and
    additionally defines an equivalent function-like macro. */

    struct mystruct {
    void (*memfoo)(void);
    }
    struct mystruct obj;
    /* ... */
    obj.memfoo(); /* This invokes the macro! */

    If you *don't* include <string.h>, either directly or indirectly,
    there's no conflict with the external function.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jun 26, 2007
    #5
  6. Bas Wassink

    Bas Wassink Guest

    On Tue, 26 Jun 2007 13:54:54 -0700, Keith Thompson wrote:

    > Dave Hansen <> writes:
    >> On Jun 26, 3:43 am, Richard Heathfield <> wrote:
    >>> Bas Wassink said:
    >>> > I've been wondering about struct member names and reserved
    >>> > identifiers for some time now and I can't figure out whether the
    >>> > reserved identifier restrictions apply to struct members.
    >>>
    >>> They don't (although I'd still steer clear of keywords if I were
    >>> you!).
    >>>
    >>> The crux is that the kind of names you're (laudably) worrying about,
    >>> str*, mem*, to*, is*, and so on, are reserved for use as ***external
    >>> identifiers***. Each struct carries its own name space around, so
    >>> you're okay with a struct member called 'memory' (or indeed 'member').
    >>> You can also have struct members called 'towel', 'isobar', and
    >>> 'strange_attractor' if you like.

    >>
    >> But beware of reserved macro names if the associated header is
    >> included. Macros don't respect namespaces.

    >
    > Right, but if mem* and friends are defined as macros, they're defined as
    > function-like macros.
    >
    > But you can still run into problems if you use one of those identifers
    > as a member name, if the member is a function pointer. For example:
    >
    > #include <string.h>
    > /* Assume the implementation defines a function memfoo(), and
    > additionally defines an equivalent function-like macro. */
    >
    > struct mystruct {
    > void (*memfoo)(void);
    > }
    > struct mystruct obj;
    > /* ... */
    > obj.memfoo(); /* This invokes the macro! */
    >
    > If you *don't* include <string.h>, either directly or indirectly,
    > there's no conflict with the external function.


    But if I interpret the standard correctly, I could #undef the memfoo()
    macro and then use 'void (*memfoo)(void)' as a member of a struct,
    avoiding the macro-substition and not invading the implementation's
    namespace.

    Not that I would do such a thing, that would be unnecessarily confusing
    (and very bad style in my opinion). I'm just curious if I've interpreted
    the standard (7.1.3 and 7.1.4) correctly.
     
    Bas Wassink, Jun 26, 2007
    #6
  7. Bas Wassink

    CBFalconer Guest

    Bas Wassink wrote:
    > Keith Thompson wrote:
    >

    .... snip ...
    >
    >> If you *don't* include <string.h>, either directly or indirectly,
    >> there's no conflict with the external function.

    >
    > But if I interpret the standard correctly, I could #undef the
    > memfoo() macro and then use 'void (*memfoo)(void)' as a member of
    > a struct, avoiding the macro-substition and not invading the
    > implementation's namespace.


    You MIGHT get away with it, but it is not gu guaranteed by the
    standard. So don't.

    --
    <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
    <http://www.securityfocus.com/columnists/423>
    <http://www.aaxnet.com/editor/edit043.html>
    cbfalconer at maineline dot net



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Jun 26, 2007
    #7
  8. Bas Wassink <> writes:
    > On Tue, 26 Jun 2007 13:54:54 -0700, Keith Thompson wrote:

    [...]
    >> Right, but if mem* and friends are defined as macros, they're defined as
    >> function-like macros.
    >>
    >> But you can still run into problems if you use one of those identifers
    >> as a member name, if the member is a function pointer. For example:
    >>
    >> #include <string.h>
    >> /* Assume the implementation defines a function memfoo(), and
    >> additionally defines an equivalent function-like macro. */
    >>
    >> struct mystruct {
    >> void (*memfoo)(void);
    >> }
    >> struct mystruct obj;
    >> /* ... */
    >> obj.memfoo(); /* This invokes the macro! */
    >>
    >> If you *don't* include <string.h>, either directly or indirectly,
    >> there's no conflict with the external function.

    >
    > But if I interpret the standard correctly, I could #undef the memfoo()
    > macro and then use 'void (*memfoo)(void)' as a member of a struct,
    > avoiding the macro-substition and not invading the implementation's
    > namespace.
    >
    > Not that I would do such a thing, that would be unnecessarily confusing
    > (and very bad style in my opinion). I'm just curious if I've interpreted
    > the standard (7.1.3 and 7.1.4) correctly.


    Yes -- and yes, it would be ugly.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jun 27, 2007
    #8
    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. metaperl
    Replies:
    32
    Views:
    949
    NickC
    Sep 15, 2006
  2. Delaney, Timothy (Tim)
    Replies:
    10
    Views:
    699
    Jason
    Sep 14, 2006
  3. Steve Holden
    Replies:
    0
    Views:
    410
    Steve Holden
    Sep 13, 2006
  4. Tim H

    reserved identifiers?

    Tim H, Mar 23, 2007, in forum: C++
    Replies:
    8
    Views:
    882
    red floyd
    Mar 23, 2007
  5. Replies:
    3
    Views:
    202
    osmium
    Nov 6, 2013
Loading...

Share This Page