Post by Szabolcs NagyPost by Claudio JekerBut the funniest thing is that strlcpy(a, b, sizeof(a)) is exactly
the same as snprintf(a, sizeof(a), "%s", b) including return values.
So how can be one wrong and bad and the other be right?
no, they are not the same
snprintf is standard while strlcpy is not
so you have no guarantee about the semantics
of strlcpy, it can mean anything
but as i said it seems it works as expected
on systems where it's implemented
That is complete bullshit.
First of all, from our recently updated manual page:
RETURN VALUES
Besides quibbles over the return type (size_t versus int) and signal
handler safety (snprintf(3) is not entirely safe on some systems), the
following two are equivalent:
n = strlcpy(dst, src, len);
n = snprintf(dst, len, "%s", src);
Like snprintf(3), the strlcpy() and strlcat() functions return the total
length of the string they tried to create. For strlcpy() that means the
length of src. For strlcat() that means the initial length of dst plus
the length of src.
If the return value is >= dstsize, the output string has been truncated.
It is the caller's responsibility to handle this.
On all systems that have a function called strclpy in their libc, that
is how it works.
However, in your fiction world filled full of phantoms, some vendor is
going to add a strlcpy version to their libc that does a call to reboot(2).
Or eats children. Or calls random.
If anything, there may be versions of strlcpy out there that behave in broken
ways because they are broken, because people don't want to allow strlcpy to
become standard. Through words much like yours. By not letting strlcpy --
a 100% free piece of code we give to anyone -- gain spread as it should,
we are ending up with fresh new rewrites of it which may have bugs.
Is that what you mean? But that's got nothing to do with whether it
is in a standard or not. Operating systems have bugs in standards
"approved" functions all the time, too. Standards aren't pixy dust
that solve bugs.
So anyways, in reality, strlcpy has *exactly* the same behaviour of
snprintf, and I think you are just spreading hate.
By the way, you shouldn't use snprintf, if you want to put a fine
point on it. Completely without regard to 10 years of established
practice in the post-4.4BSD world, it was fine -- it returned the
number of bytes it wanted, just like it does now.
HOWEVER, the first official standard that documented it said that it
returned -1 on overflow! And a release of Solaris which behaved like
that shipped!
So something being standard doesn't mean it is right, either. I was
there -- fought to get that standard fixed before the problem went too
far, and we have the BSD semantics of > 0 for "string size required"
and the -1 semantic for encoding probelms.
I was there, making sure stuff was useable. While you are here, on
this list, like many others, simply spreading prejudice.