Is strdup() standard? was Re: A Beginner question on strings???
Kurt Watzka
>seems so, but it isn't in the c-lib of my dec. is it
>part of the standard?
strdup() is conformant to SVID2, i.e. it's not part of the ANSI C
standard library, if that's the standard you are talking about :-).
--
| Kurt Watzka Phone : +49-89-2180-2158
| wat...@statistik.uni-muenchen.d400.de
| ua3...@sunmail.lrz-muenchen.de
Hans Friedrich Steffani
>In article <32a6cu$9...@nz12.rz.uni-karlsruhe.de>,
>Hans Friedrich Steffani <gm...@fg70.rz.uni-karlsruhe.de> wrote:
>>This function returns a new string containing the same chars
>>as the_string does.
>Kind of like strdup, isn't it?
seems so, but it isn't in the c-lib of my dec. is it
part of the standard?
hans friedrich steffani
--
Hans Friedrich Steffani gm...@rz.uni-karlsruhe.de
Maschinenwesen im Baubetrieb hans.s...@bau-verm.uni-karlsruhe.de
Universitaet Karlsruhe gm...@DKAUNI2.BITNET
0721 / 608-6008
Mark Klenk
>
>>Kind of like strdup, isn't it?
>
>seems so, but it isn't in the c-lib of my dec. is it
>part of the standard?
No, it is not.
---
mkl...@impact.xerox.com (Mark Klenk)
Lars Wirzenius
> part of the standard?
It is not part the standard. I don't know why, possibly because they
wanted to have all the memory allocation stuff in stdlib.h, and didn't
want to throw in a string function as well.
If you don't have it, you can get it free with Publib. If you don't
care about Publib :-), you can take it from here:
#include <assert.h>
#include <stdlib.h>
#include <string.h>
char *strdup(const char *s) {
size_t n;
char *p;
assert(s != NULL);
n = strlen(s) + 1;
p = malloc(n);
if (p != NULL)
memcpy(p, s, n);
return p;
}
--
Lars.Wi...@helsinki.fi (finger wirz...@klaava.helsinki.fi)
ftp.cs.helsinki.fi:pub/Software/Local/Publib -- general C function library
Mark Brader
> It is not part [of] the standard. ...
And then supplies a version, starting with
> char *strdup(const char *s) {
But the name strdup() is in the implementation's name space, so if
you do define it yourself, you might find your code failing to port
to another implementation -- perhaps one that uses the name strdup()
to refer to some *other* function. The safe thing is to define your
function as str_dup() instead.
--
Mark Brader, m...@sq.com "Constrain your data early and often."
SoftQuad Inc., Toronto -- C. M. Sperberg-McQueen
This article is in the public domain.
Peter Holzer
>Lars Wirzenius (wirz...@cc.Helsinki.FI) writes:
>> It is not part [of] the standard. ...
>And then supplies a version, starting with
>> char *strdup(const char *s) {
>But the name strdup() is in the implementation's name space, so if
>you do define it yourself, you might find your code failing to port
>to another implementation -- perhaps one that uses the name strdup()
>to refer to some *other* function. The safe thing is to define your
>function as str_dup() instead.
Depends on what you want. If you want to be portable to all C
implementations, that will ever exist, you are right. If you want to
implement a function which already exists in a lot of implementations
and is used in a lot of functions, and want to press it into the next
release of the standard, it should be called strdup.
hp
--
_ | h...@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems
|_|_) |------------------------------------------------------------------------
| | | It's not what we don't know that gets us into trouble, it's
__/ | what we know that ain't so. -- Will Rogers
Lars Wirzenius
> But the name strdup() is in the implementation's name space, so if
> you do define it yourself, you might find your code failing to port
> to another implementation -- perhaps one that uses the name strdup()
> to refer to some *other* function. The safe thing is to define your
> function as str_dup() instead.
That will, however, perhaps make it somewhat less useful for all the
application code that uses the name strdup, I think.
strdup is included in Publib for portability, so that users of Publib
may assume that it exists (it is installed only if the target system
does not already have it). If and when there is a collision on some
system with a strdup that does something different, there will be a
problem. From a pragmatic point of view, since the name strdup is as
established as it is, I doubt there ever will be a collision.
The issues of reserved name spaces has troubled me quite a bit with
Publib. I would like to conform to the standard as closely as
possible. Since I target Publib as an extension to the standard
library, I should use only the name space reserved to the
implementation. That, however, is not particularly nice, since it
forces names like __expr_compile, which are both more to type, and will
make users comfortable with using under-scored names. Therefore I have
taken the liberty to expand the reserved name space. Users of Publib
will have to include a non-standard header, thereby making the program
not-strictly-conforming anyway, and in this header I boldly declare certain
additional parts of name space reserved (by grouping the library
functions into modules, and having every name in the module start with
a prefix unique to that module; hence, all names beginning with any of
the prefixes is reserved). I hope this approach will work well.
So why do I want to consider Publib part of the implementation? If I
didn't, I could solve the problem by using only names in the users'
name space. Unfortunately, I want to be able to use names that are
reserved anyway. One example is strdup. At the moment I have 47 other
functions with names beginning with str or mem and a lower case
letter. I don't think it would be very convenient to have the user
have to remember which string functions have an underscore after str
and which do not. (Besides, it wouldn't fit into my grand plan for
taking over the world, if users will be able to see at a glance which
functions are part of the standard library and which part of Publib.)
Of course, if experience will show that this decision causes too much
trouble, I may have to revert it.
Mark Brader
> > But the name strdup() is in the implementation's name space ...
> > The safe thing is to define your function as str_dup() instead.
Lars Wirzenius replied:
> That will, however, perhaps make it somewhat less useful for all the
> application code that uses the name strdup, I think.
Which is a good point. On the other hand, that code was already non-
portable, since it was taking advantage of an implementation extension.
Perhaps the best thing is to replace all the calls to the function with
uses of a macro STR_DUP, which you define as strdup on implementations
that have that function, and str_dup on others.
Then again, considering that str_dup() is so trivial to write, it seems
unlikely that the implementation's library's version of it will have
significantly better performance than your str_dup() would. So another
option would be to just use str_dup() -- or change the existing code to
use it -- and ignore the fact that there might be a strdup() in the library.
--
Mark Brader, m...@sq.com "When you say 'non-trivial', can you
SoftQuad Inc., Toronto quantify that for me?" --Kate Hamilton