naming functions and variables str*

J

John Smith

I understand that C identifiers beginning with str are reserved for
future implementations. Do variable and function names beginning with
str in my existing code, which is for my own use only, constitute a
functional bug or a potential for undefined behaviour? Does "future
implementation" mean a formal revision of the current standard?

JS
 
W

Walter Roberson

I understand that C identifiers beginning with str are reserved for
future implementations. Do variable and function names beginning with
str in my existing code, which is for my own use only, constitute a
functional bug or a potential for undefined behaviour?

If new str* are added to the standard (possibly as an addendum
rather than a formal revision), and they happen to overlap your names,
then there is the potential that if you recompiled your code with
a compiler that had the new functions, that you could run into
symbol overlaps; that could result in anything from a compile
error for mismatched prototypes, to a refusal to link, to the
code not doing what you wanted because the wrong function was called.

The idea is future-proofing: if you avoid str* now then you
don't have to change your code later.
 
P

pete

Walter said:
If new str* are added to the standard (possibly as an addendum
rather than a formal revision), and they happen to overlap your names,
then there is the potential that if you recompiled your code with
a compiler that had the new functions, that you could run into
symbol overlaps; that could result in anything from a compile
error for mismatched prototypes, to a refusal to link, to the
code not doing what you wanted because the wrong function was called.

The idea is future-proofing: if you avoid str* now then you
don't have to change your code later.

Function names that begin with str and a lowercase letter
are reserved.
char *str_cpy(char *s1, const char *s2);
is fine.
 
C

CBFalconer

Walter said:
If new str* are added to the standard (possibly as an addendum
rather than a formal revision), and they happen to overlap your
names, then there is the potential that if you recompiled your code
with a compiler that had the new functions, that you could run into
symbol overlaps; that could result in anything from a compile error
for mismatched prototypes, to a refusal to link, to the code not
doing what you wanted because the wrong function was called.

The idea is future-proofing: if you avoid str* now then you
don't have to change your code later.

It's more than that. Those names are reserved for the
implementation. So an implementor can provide a functions
strblah(...) which does whatever he wishes, place it in the
library, and call it from his internal operations. If you replace
it you can cause well known standard library functions to fail.
You gotta know the territory.

I will concede in advance that such an event is unlikely, and would
probably result in negative comments about the implementation
quality.
 
M

Mark L Pappin

CBFalconer said:
It's more than that. Those names are reserved for the
implementation. So an implementor can provide a functions
strblah(...) which does whatever he wishes, place it in the
library, and call it from his internal operations. If you replace
it you can cause well known standard library functions to fail.
You gotta know the territory.

I will concede in advance that such an event is unlikely, and would
probably result in negative comments about the implementation
quality.

I don't know ... I'm kind of keen on compilers flagging as much
non-sanctioned behaviour as they can, and reserved identifiers seem to
be an easier thing to catch than [the general case of] i = i++.
(Quietly breaking when such an identifier is used is, however,
sub-optimal.)

mlp
 
J

John Smith

CBFalconer said:
It's more than that. Those names are reserved for the
implementation. So an implementor can provide a functions
strblah(...) which does whatever he wishes, place it in the
library, and call it from his internal operations. If you replace
it you can cause well known standard library functions to fail.

This is the kind of thing I was concerned about. I suppose one can
examine the implementation's headers to find out if this is the case.
 
I

Ian Pilcher

CBFalconer said:
It's more than that. Those names are reserved for the
implementation. So an implementor can provide a functions
strblah(...) which does whatever he wishes, place it in the
library, and call it from his internal operations. If you replace
it you can cause well known standard library functions to fail.
You gotta know the territory.

I will concede in advance that such an event is unlikely, and would
probably result in negative comments about the implementation
quality.

Not necessarily. SuS includes strdup, so an application-defined
function of that name could very easily cause a conflict, without
inviting negative comments.
 
C

CBFalconer

Ian said:
Not necessarily. SuS includes strdup, so an application-defined
function of that name could very easily cause a conflict, without
inviting negative comments.

The smarter implementor will create __strdup, and put a #define in
the appropriate header file (possibly with guards for pedantic
conformity etc.) such as:

#define strdup __strdup

and the problem goes away when the appropriate header is not
included.
 
I

Ian Pilcher

CBFalconer said:
The smarter implementor will create __strdup, and put a #define in
the appropriate header file (possibly with guards for pedantic
conformity etc.) such as:

#define strdup __strdup

and the problem goes away when the appropriate header is not
included.

Good point, however ...

strdup is declared in <string.h>. Any translation unit that makes use
of an application-defined strdup it likely to also make use of other
functions declared in this header.

Either way, the reasons for not using str... names are good.
 
T

those who know me have no need of my name

in comp.lang.c i read:
I suppose one can examine the implementation's headers to find out if this
is the case.

every one of them you use? will you even remember to check each new
implementation as you begin using it? will you check every implementation
each time it is updated? yes, that's the scope of the issue -- save
yourself the hassle, stay away from str*, and is*, mem*, to* and wcs*. is*
surprises lots of people (e.g., int isactive();). but there is hope, the
reservation is only when the identifier has external linkage and the prefix
is followed by a lowercase letter, so an underscore gets you back into the
safe zone without much disruption. in theory an uppercase letter will too,
but external identifiers aren't required to be case sensitive so it might
also bite you -- stick with the underscore.

also an initial E if followed by an uppercase letter or a decimal digit.

also an initial LC, SIG or SIG_ if followed by an uppercase letter.

and also, of course, those with an initial underscore.

see <http://oakroadsystems.com/tech/c-predef.htm> for a more involved
discussion of the issues.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top