tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

Hash: SHA256

On 30.10.2015 00:55, Christos Zoulas wrote:
> In article <>, Greg Troxel
> <> wrote:
>> -=-=-=-=-=-
>> Kamil Rytarowski <> 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.
Version: GnuPG v2


Home | Main Index | Thread Index | Old Index