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

On 10/30/15 7:16 AM, Jan Danielsson wrote:
>    I recall some discussion (on this list, I think) years ago on the
> topic of creating a libc extensions library which was specifically
> meant for becoming a portability library for common libc extensions.
> As I remember it, it was one of those discussions where there
> was pretty much uniform consensus that it was a good idea, but I
> think the discussion started to fade away when someone brought up
> maintainability of such a library (keeping it in-tree, but at the same
> time keeping it as a separate project).
>    Perhaps it's time to revisit this idea?


If I sit down to write a portable program, I try to avoid nonportable
functions even if they're better. :-(  I wish it wasn't like that.
Yes, I could try to pull the desired functions out of NetBSD libc
or wherever, but that's more work, I'm duplicating code, and I have
to maintain my copy of it (i.e. track and merge changes).  If there
was a nice libc extensions portability library that was offered as a
separate project, that would be *really nice* to just use.  I assume
the functions would need to be prefixed with "nb_" or something to give
them a unique namespace so that if a function became part of a standard
and eventually appeared in libc, it would not conflict with the one in
the portability library.  Then I could modify my program to use the libc
function (without the "nb_" prefix) at my leisure.

And there could of course be a package for it in pkgsrc, and the package
for my portable program could just depend on it in pkgsrc.  Very nice.

On the other hand, I understand that it would require effort for the
NetBSD developers to maintain such a portability library if it was
determined to be a good idea.



Home | Main Index | Thread Index | Old Index