Groovy hepcat Chris Croughton was jivin' on Sun, 27 Mar 2005 13:01:22
+0100 in comp.lang.c.
Re: strdup()'s a cool scene! Dig it!
So you want to write a different version of the code for each
implementation you compile it on? Well, if that's what floats your
boat then who am I to stifle you? But I prefer to write code that's
portable.
If you want to limit yourself to those few programs which are totally
portable (nothing which involves directory access, for a start), I'm
not stopping you. I need to write programs in the real world, however,
where it can't be guaranteed that even all of the C89 functions will be
implemented, so I need to provide replacements for them.
Since it's in my library of "things I find useful", the only 'porting' I
need to do is to determine whether it is available on the target
platform, and for most of them that will happen automatically. That
sort of thing needs to be done anyway to determine headers for doing
filesystem access (read directories), sockets, pipes, whether long long
exists, and many more non portable but essential features in real
programs.
And what about all those implementations that are not POSIX
compliant but have extentions named strdup which may or may not follow
the usual idioms? You'd have to make special arrangements for them.
What implementation has strdup() which does not follow the idiom? I
haven't found one in the last 20+ years, and I very much doubt that
anyone would be foolish enough to write one now.
With a function as trivial as the one we're discussing here, it is so
much easier to just write it yourself portably than to do what you
suggest.
Duh, I did just write it portably.
True. But why make the situation worse by invoking undefined
behaviour?
It is only 'undefined' by the C standard, which is not the only standard
in real world programs.
And what about all those implementations that don't follow existing
standards like POSIX? They often do things different just to be
difficult. You should take that into account when writing code.
Examples? As I said, I have never found any library implementations of
strdup() which do anything other than what the POSIX standard says (even
before POSIX existed). The worst is on K&R systems which didn't support
const, but that will blow most C89 and later programs anyway.
Oh, is that what'll happen, eh?
Anything which breaks POSIX will just be ignored by the vast majority of
the programmers, because there is too much POSIX compliant code which
would be affected. Having standards which are ignored causes them to
fall into disrepute (this is happening anyway with C99, very few places
are at all interested in going to C99 compliant compilers), just as it
does with laws.
I just did a scan of some of the Free Software source on my system.
Every project there uses strdup(). Perl, Python, Qt, openSSL, fvwm,
gcc, procmail, GPG, Doxygen, all of the libraries, etc. (it's almost 100
directories, I'm not going to bother to list them all). I somehow think
that anyone re-using it as something different would not be popular...
Chris C
