Date: Sun, 9 Aug 2015 18:02:54 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Baptiste Daroussin <bapt@FreeBSD.org> Cc: Bruce Evans <brde@optusnet.com.au>, src-committers@freebsd.org, svn-src-projects@freebsd.org Subject: Re: svn commit: r286521 - projects/collation/lib/libc/locale Message-ID: <A7DDA029-A520-41E7-B4EA-CD5DB4B5023D@FreeBSD.org> In-Reply-To: <20150809163935.GA96980@ivaldir.etoilebsd.net> References: <201508091150.t79Boo3v096088@repo.freebsd.org> <20150809223647.O2415@besplex.bde.org> <20150809163935.GA96980@ivaldir.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9 Aug 2015, at 17:39, Baptiste Daroussin <bapt@FreeBSD.org> wrote:
>=20
> Well on the review David recommended to use asprintf rather than =
snprintf.
>=20
> While I dislike the option (as I stated in the review) given he wrote =
most of
> the recent changes (xlocale) I followed his recommendations.
Having a large (1028 byte currently) buffer on the stack won=E2=80=99t =
push you over the guard page if you run out of stack, but will mean that =
if you=E2=80=99re near the end of the stack you=E2=80=99ll get a =
segfault. And if there are bugs in the length calculation then we just =
get a bigger allocation than expected, we don=E2=80=99t get a stack =
buffer overflow.
In both places, the buffer is only used in one place and so it should =
only need freeing in one place, though it will require splitting the =
next lines so that the open call is followed by the free and then the =
check of the error return.
We have this pattern in enough places in libc that it=E2=80=99s probably =
worth pulling it out into a function something like this:
int
open_format(const char * restrict format, int oflag, ...)
{
char *path;
int file;
va_list ap;
va_start(ap, format);
vasprintf(&path, format, ap);
va_end(ap);
if (path =3D=3D NULL)
return (NULL);
file =3D open(path, oflag);
free(path);
return (file);
}
I think every single one of the locale lookup data loading functions =
would benefit from using this instead of the existing code path. There =
are a few other places in libc that seem to do this as well.
As I said in the code review, when we=E2=80=99re doing a printf and some =
file I/O, the cost of a short-lived heap allocation is likely to be in =
the noise.
David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A7DDA029-A520-41E7-B4EA-CD5DB4B5023D>