This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Implement strlcat [BZ#178]

On 12/04/2015 01:01 PM, Florian Weimer wrote:
> On 12/03/2015 07:08 PM, Zack Weinberg wrote:
>>> Calling strlcpy (DST, SRC, 0) instead of the more-obvious strlen (SRC)?
>>> Really? That would be bizarre. I'd like to see an example.
>> char *my_strdup(char *s)
>> {
>>     size_t bufsiz = strlcpy(0, s, 0) + 1;
>>     char *buf = malloc(bufsiz);
>>     if (!buf) return 0;
>>     strlcpy(buf, s, bufsiz);
>>     return s;
>> }
> The implementation I posted does not actually support that because (like
> virtually all C standard functions), a null pointer is not allowed even
> if the buffer size is zero.

I think that's a showstopper bug in your implementation; as I've been
saying to Paul, the semantics should _exactly_ match *BSD (OpenBSD,
specifically) or we shouldn't have these functions at all.  If I'm
reading the OpenBSD manpages correctly, this applies to both strlcpy and

> This is incompatible with the C++ standard library, but I did not have
> any luck so far with convincing people that this needs to be fixed in
> the C standard.  The strlcpy/strlcat patch is not the place for this
> general discussion, I think.

FWIW I would support a general policy of "if a buffer size is specified
as zero, the associated pointer(s) are not dereferenced".  But agree
that this is a separate discussion.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]