On Fri, Nov 10, 2023 at 12:05:31PM +0100, Alejandro Colomar wrote:
> Hi Paul,
>
> On Thu, Nov 09, 2023 at 09:36:43PM -0800, Paul Eggert wrote:
> > On 2023-11-09 15:48, Alejandro Colomar wrote:
> > > I'd then just use strlen(3)+strcpy(3), avoiding
> > > strncpy(3).
>
> Heh, brain fart on my side.
>
> >
> > But that is vulnerable to the same denial-of-service attack that strlcpy is
> > vulnerable to. You'd need strnlen+strcpy instead.
> >
> > The strncpy approach I suggested is simpler, and (though this doesn't matter
>
> Yeah, although you can always wrap strnlen(3)+memcpy(3) in a strxcpy()
> inline function and have it even simpler.
>
> Rewriting the strxcpy() wrapper I wrote the other day to not be
> vulnerable to DoS, and hoping I get it right today.
>
> [[nodiscard]]
> inline ssize_t
> strxcpy(char *restrict dst, const char *restrict src, size_t dsize)
> {
> size_t slen;
>
> slen = strnlen(src, dsize);
> if (slen >= dsize)
Oops: s/>=/==/
> return -1;
>
> memcpy(dst, src, slen + 1);
>
> return slen;
> }
>
> Hopefully, it won't be so bad in terms of performance. And it is still
> protected by fortification of memcpy(3). And thanks to [[nodiscard]],
> it should be hard to misuse.
>
> > much in practice) is typically significantly faster than strnlen+strcpy in
> > the typical case where the destination is a small fixed-size buffer.
> >
> > Although strncpy is not a good design, it's often simpler or faster or safer
> > than later "improvements".
>
> Cheers,
> Alex
>
> --
> <https://www.alejandro-colomar.es/>
--
<https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
