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

[christos%astron.com@localhost (Christos Zoulas)]

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.

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.

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.

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!

christos