Structure members and reserved identifiers

[Bas Wassink]

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

[Richard Heathfield]

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_attrac tor' 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

[Bas Wassink]

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_attrac tor' 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

[Dave Hansen]

On Jun 26, 3:43 am, Richard Heathfield <[e-mail].i nvalidwrote:

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_attrac tor' if you like.

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

Regards,

-=Dave

[Keith Thompson]

Dave Hansen <id**@hotmail.c omwrites:

On Jun 26, 3:43 am, Richard Heathfield <[e-mail].i nvalidwrote:

>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_attra ctor' 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_Keit h) ks***@mib.org <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"