Date: Wed, 15 Jul 2015 10:29:22 +0100 From: David Chisnall <theraven@FreeBSD.org> To: d@delphij.net Cc: Ian Lepore <ian@freebsd.org>, Garrett Cooper <yaneurabeya@gmail.com>, Baptiste Daroussin <bapt@FreeBSD.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r285552 - head/usr.bin/xargs Message-ID: <F8B79263-A02C-455A-BB9F-A1ED464140F5@FreeBSD.org> In-Reply-To: <55A5A30F.4070005@delphij.net> References: <201507141916.t6EJGEG1083928@repo.freebsd.org> <48222CD1-7087-4C9A-A586-71F6A37A601C@gmail.com> <55A574BA.4090700@delphij.net> <1436912270.1334.309.camel@freebsd.org> <55A5A30F.4070005@delphij.net>
index | next in thread | previous in thread | raw e-mail
On 15 Jul 2015, at 01:02, Xin Li <delphij@delphij.net> wrote: > > My only concern with strtonum() is that it's English only. Given that strtonum() wraps strtoll, it ought to support whatever the current locale is (assuming that the program calls setlocale() before calling strtonum(), otherwise it will use the C locale[1]). Or do you mean that the error messages are not localised? David [1] I would strongly advise against calling strtonum() or strtoll(), rather than strtoll_l() from a library, as it is impossible to specify in a potentially multi-threaded context whether you’re currently using a human-friendly or a machine-friendly number representation. In a single-threaded application, it’s probably fine as long as *all* of your number parsing is either from a user or from a machine-parsable file (and all of your output is similar, or you’re explicitly setting the locale before each call). Given that strtonum() is non-standard anyway, we should probably add a strtonum_l() that takes a locale_t and a number base.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F8B79263-A02C-455A-BB9F-A1ED464140F5>