Re: strsuftoi(3), strsuftou(3) proposal in libc

[Kamil Rytarowski <n54%gmx.com@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 30.10.2015 00:55, Christos Zoulas wrote:
> In article <rmir3kdcmbw.fsf%fnord.ir.bbn.com@localhost>, Greg Troxel
> <gdt%ir.bbn.com@localhost> wrote:
>> -=-=-=-=-=-
>> 
>> 
>> Kamil Rytarowski <n54%gmx.com@localhost> writes:
>> 
>>>> Assuming no, why should new functionality be added to libc,
>>>> since it will encourage nonportable code.  (Cleaning up
>>>> previous extra stuff is a separate issue.)
>>> 
>>> Do you think libutil(3) might be a better place? There are
>>> already similar string functions, strpct(3) and strspct(3)
>>> (decimal percent formatters).
>> 
>> I think it's better to keep stuff out of libc unless it's
>> specified by c99 or posix.
>> 
>>>> Are these helper functions for some specific purpose?
>>>> Perhaps they belong in a different library that's intended to
>>>> be used within our tree but not by users.
>>> 
>>> The purpose it to replace strsuftoll(3) with a new cleaner
>>> function and deduplicate code. I want to make it available for
>>> users.
>> 
>> The question is then under which circumstances users can
>> reasonbly use this; portable code can't use non-standard
>> functions.
> 
> I think that the rule should be that things that are not in
> posix/c99 but are better (and we recommend their use) than the
> corresponding posix/c99 functions already in libc go to libc.
> 

Is there green light for the strsuftoi(3) family of functions to land
in our libc?

How about my questions from the original mail:

Things not to be discussed:
1. Whether string like '123x 123' is legal or not. Traditionally we
strip whitespace from the beginning of strtol(3) like functions. '123
x123' isn't fully converted string, while '123x 123' is. I was thinking
about making only initial whitespace to the whole input (like '
123x123') legal.
2. Streamline 'b' meaning, change from nothing/dummy argument to block
size (512 bytes).
3. Accept uppercase and lowercase multiplication types (for
compatibility with existing software and orders)?

> One exception would be for functions not in posix/c99 that are
> used by "many" programs (we don't want to have a libutil dependency
> for 1/2 the source tree). Again these should be added to libc.
> 

I've checked and half of strsuftoll(3) users are users of libutil(3).

> In the case in question, I think strsuftoll(3) should not have
> gone to libc in the first place, but it is too late for that. So
> since strsuftoll(3) is in libc already, I don't think that it makes
> sense to put strsuftoi(3) in libutil.
> 

This makes sense.

> The reasoning is that if you want to keep your code trully
> portable, you have to make functionality, brevity, and reliability
> compromises by using only functions mentioned in the standard.
> Instead what we do in practice is design new functions that should
> be in the standard.  The standards typically lag a lot behind,
> specially recently where funding and interest has been declining
> for them. Hell, even strlcpy(3)/err(3)/asprintf(3) have not made
> it!
> 

I'm doing it the other way around - just use featured NetBSD libc and
link with libnbcompat from pkgsrc. People coming from other systems
and reusing our software are doing it this way too.

If there is some limitation in environment it's simply enough to just
copy this or that function from this compatibility layer.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWNqKdAAoJEEuzCOmwLnZsA6gP/08OaNQFVhcpAU5UTfivil+k
SBbByNNLJS3rJvuNmpgmUAzaAD6PAw+gIE9BJyymNOuP2SxAJMk70u07nDKwhdis
rPx4PnroGsnERrJI1GUf28GA+aK2QqKAiMZr4RWK0MGlG+Uj6CM5AODhg47Uhvjk
jQkaNcNkkoNCOuL3x3BjjkNBDfkGhHMMGjfLx60g1Kxo8j6J4tVCbnHh4HCSlk+B
9hkgyLfkqBghVTMXDhwlfC8gervmFyEYo6ThLTGkhJfuCSculRMKu24EmF3WGLl+
PEJE6c8z3KFwYEn8FitdiXk8JjuWICaG0tIOW/k+04A8XAbBxFLAJXN8/IKqxDQu
YyJEnFOIk5ZlRgFVjHeX4GfaUjGwwn2agdeIew66OkSALNcetw1SBCWF2k5ln7uE
sutQSQZ7UDt2F2zikdZvl7zfRUEzc5DszQKAmGdeEBRnNJpUUFh1Pcklhm03bfDY
DQPwmurBusyJq8GgVPehLtbrCjo1YfQyNsXX+uZOTJTSPM28u+MHDpZuY9fOPgTP
b3KN8oA7zNpBVzJFQ/odu6350KxJtFjox5vfD1D27ArEaK59ZAb6rSYznJvNybNN
07GABh+TfHwsq0P/z2CYTs9pAc4o1l7XMgGzzaYDxZwBW4P+raN5DbM03k8278DM
qPhKN23W7vkMPKqJLpSQ
=p9Ye
-----END PGP SIGNATURE-----