Date: Sat, 27 Jan 2018 21:27:46 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: Dimitry Andric <dim@freebsd.org>, Ed Schouten <ed@nuxi.nl>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r328492 - head/contrib/opie/libopie Message-ID: <0e2f6c82-3036-29ef-bf09-15d4e5623020@FreeBSD.org> In-Reply-To: <20180128121851.U4596@besplex.bde.org> References: <201801272216.w0RMGJwo057492@repo.freebsd.org> <CABh_MKn=3pRWyMHUAQkG17dQVBFEwFA2esFixPtgkCt7VE5oCw@mail.gmail.com> <7C471160-44B3-4EA6-8995-08A4EB4332A1@FreeBSD.org> <20180128093811.G4029@besplex.bde.org> <5c39c37d-8d0a-22e9-710b-2453e0dd4481@FreeBSD.org> <20180128121851.U4596@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/27/18 20:42, Bruce Evans wrote: > On Sat, 27 Jan 2018, Pedro Giffuni wrote: > >> On 01/27/18 18:21, Bruce Evans wrote: >>> On Sat, 27 Jan 2018, Dimitry Andric wrote: >>> >>>> On 27 Jan 2018, at 23:20, Ed Schouten <ed@nuxi.nl> wrote: > >> * [... context lost to corruption of spaces which makes it unreadable] > >>>>> >>>>> Wait... This may access utmp.ut_host one byte past the end and no >>>>> longer guarantees that host is null-terminated, right? >>> >>>> No, strncpy "copies at most len characters from src into dst". >>>> However, >>> >>> No, the change breaks the length so 1 byte past the end is accessed >>> in implementations where ut_host is not guaranteed to be NUL terminated >>> and the current instance of ut_host is not NUL terminated. >>> >> The main change is in the sizeof(). Regularly you should use the size >> of destination not the source, and apparently GCC8 decided there was >> something to check there. > > That is the main breakage. Using the size of the destination is very > wrong, > since that size is intentionally 1 larger than the size of the source, to > leave space for appending a NUL. > I am considering reverting the change. Looking at other ways to get rid of the warning, please be patient. >> ... >> Looking in detail, upstream (which appears to have disappeared) does >> have the explicit NULL termination in our last import. For >> consistency and given that we already have a strlcpy in that code, we >> should use strlcpy() there. Every modern OS out there has strlcpy(3) >> and if not they can figure out what to do. > > strlcpy() still seems to be intentionally left out of glibc. > glibc is not portable. I understand some systems that carry glibc also carry libbsd, or they can still use musl: https://github.com/esmil/musl/blob/master/src/string/strlcpy.c Pedro.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0e2f6c82-3036-29ef-bf09-15d4e5623020>