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

 

[Bas Wassink]

Bas Wassink said:


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

 

[Dave Hansen]

Bas Wassink said:



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

 

[Keith Thompson]

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.

 

[Bas Wassink]

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.

 

[CBFalconer]

Keith Thompson wrote:
.... snip ...


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.

 

[Keith Thompson]

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.