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: Fwd: The semantics of strlcpy and strlcat

Zack Weinberg wrote:
we have a huge installed base _on glibc-based
systems_ of programs using their fallback implementations that don't
dereference the destination buffer pointer when the destination size
is zero

This is an argument for glibc not adding strlcpy/strlcat. If these programs rely on corner-case quirks of their substitutes, then any implementation glibc provides would disagree with some of the replacements and could break the programs. This is because their replacements do not agree (this is not merely because of the size-zero buffer issue).

Better to leave sleeping dogs lie, no?

an overflow can just as easily occur
for `1 + strlen(s)`

No it can't. strlcat is weird here because it does not return the size of a real object as strlen(s) + 1 does; instead, strlcat returns the size of an *imaginary* object. That is one of the fundamental flaws in strlcat's API, and any spec for strlcat should address this flaw somehow.

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