471,336 Members | 1,267 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,336 software developers and data experts.

Structure members and reserved identifiers

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
Jun 26 '07 #1
4 1647
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
Jun 26 '07 #2
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
Jun 26 '07 #3
On Jun 26, 3:43 am, Richard Heathfield <r...@see.sig.invalidwrote:
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
Jun 26 '07 #4
Dave Hansen <id**@hotmail.comwrites:
On Jun 26, 3:43 am, Richard Heathfield <r...@see.sig.invalidwrote:
>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) 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"
Jun 26 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by kazack | last post: by
10 posts views Thread by tapeesh | last post: by
2 posts views Thread by the_init | last post: by
8 posts views Thread by Tim H | last post: by
6 posts views Thread by noone | last post: by
9 posts views Thread by nolonger | last post: by
6 posts views Thread by Scoots | last post: by
reply views Thread by Gordon Burditt | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.