«

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

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

On Jun 26, 3:43 am, Richard Heathfield <r...@see.sig.invalid> 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 <> writes:
> On Jun 26, 3:43 am, Richard Heathfield <r...@see.sig.invalid> 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) kst- <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"

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

> Dave Hansen <> writes:
>> On Jun 26, 3:43 am, Richard Heathfield <r...@see.sig.invalid> 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 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

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