Discussion:
[RFC] importing e* (embolic, estrdup, etc) functions from NetBSD (libc/libutil or libnetbsd)?
NGie Cooper
2015-10-19 19:14:34 UTC
Permalink
Hi all,
While looking quickly through makefs upstream for fixing a PR, I realized that some years ago NetBSD has refactored a number of userland utilities (including makefs) to use their new e* function implementations of malloc, strndup, etc: http://man.netbsd.org/HEAD/usr/share/man/html3/efun.html (they have some other functions that we don’t have in libc/libutil in their libutil that might need to be ported as well).
The basic overall difference is that when the failing case occurs, a function defined by esetfunc is called, it dumps out a diagnostic error message via esetfunc, then returns the original value [*].
I was wondering if anyone had objections to adding this to libutil (I think it’d be handy because it would eliminate a lot of repetitive error handling in our user land code)? If there are major objections, I’ll take it and stuff it into libnetbsd.
Thanks!
-NGie

[*] Based on a quick glance over the code, estrlcpy/estrlcat/estrtoi/estrtou are exceptions to the rule. It modifies/saves errno before calling the error function: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libutil/efun.c?rev=1.10&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
Oliver Pinter
2015-10-19 19:31:08 UTC
Permalink
Post by NGie Cooper
Hi all,
While looking quickly through makefs upstream for fixing a PR, I realized that some years ago NetBSD has refactored a number of userland utilities (including makefs) to use their new e* function implementations of malloc, strndup, etc: http://man.netbsd.org/HEAD/usr/share/man/html3/efun.html (they have some other functions that we don’t have in libc/libutil in their libutil that might need to be ported as well).
The basic overall difference is that when the failing case occurs, a function defined by esetfunc is called, it dumps out a diagnostic error message via esetfunc, then returns the original value [*].
I was wondering if anyone had objections to adding this to libutil (I think it’d be handy because it would eliminate a lot of repetitive error handling in our user land code)? If there are major objections, I’ll take it and stuff it into libnetbsd.
Thanks!
-NGie
[*] Based on a quick glance over the code, estrlcpy/estrlcat/estrtoi/estrtou are exceptions to the rule. It modifies/saves errno before calling the error function: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libutil/efun.c?rev=1.10&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
Ed Maste
2015-10-19 20:03:58 UTC
Permalink
Post by NGie Cooper
Hi all,
While looking quickly through makefs upstream for fixing a PR, I realized that some years ago NetBSD has refactored a number of userland utilities (including makefs) to use their new e* function implementations of malloc, strndup, etc: http://man.netbsd.org/HEAD/usr/share/man/html3/efun.html (they have some other functions that we don’t have in libc/libutil in their libutil that might need to be ported as well).
Yes, I spotted this while looking at makefs as well and I think it's
reasonable to bring them over. I would put them in libnetbsd though
until there's an actual plan to start migrating our own tools to use
them. Moving them from libnetbsd to libutil is easy to do later on.
Brooks Davis
2015-10-19 21:27:50 UTC
Permalink
Post by Ed Maste
Post by NGie Cooper
Hi all,
While looking quickly through makefs upstream for fixing a PR, I realized that some years ago NetBSD has refactored a number of userland utilities (including makefs) to use their new e* function implementations of malloc, strndup, etc: http://man.netbsd.org/HEAD/usr/share/man/html3/efun.html (they have some other functions that we don???t have in libc/libutil in their libutil that might need to be ported as well).
Yes, I spotted this while looking at makefs as well and I think it's
reasonable to bring them over. I would put them in libnetbsd though
until there's an actual plan to start migrating our own tools to use
them. Moving them from libnetbsd to libutil is easy to do later on.
This feels like the right approach to me as well. Let's get them in and
get some them some more exposure and then, if people like them, we can
put a copy in libutil.

-- Brooks
Poul-Henning Kamp
2015-10-19 21:50:12 UTC
Permalink
--------
Post by Brooks Davis
This feels like the right approach to me as well.
I looked at it at one point and I found it seriously lacking.

The philosophy seems to be "just stick 'e' in front and you're done"
but in practice that is not even close.

The *real* problem they're trying to solve is safe string handling,
and the e* functions only cover a small corner area of that space.

Their implemenation also seems half-hearted in many ways. For
instance they have not specified what happens if the error handler
returns to the e* function.

And finally, C-with-exceptions ? Really ?

I far prefer sbuf(3) to e*(3)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
***@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Brooks Davis
2015-10-19 22:09:53 UTC
Permalink
Post by Poul-Henning Kamp
--------
Post by Brooks Davis
This feels like the right approach to me as well.
I looked at it at one point and I found it seriously lacking.
By "This" I ment, sticking them in libnetbsd. For code we don't actively
maintain, I'd rather pick up some extra funcitions in libnetbsd than
convert the code to match our prefered mechanism unless there's a good
reason to.
Post by Poul-Henning Kamp
The philosophy seems to be "just stick 'e' in front and you're done"
but in practice that is not even close.
If one wanted this approach, a libc replacment that fails stop on
unrecoverable errors might be more interesting approach (somwhat with
different, but still signficant limitations).
Post by Poul-Henning Kamp
The *real* problem they're trying to solve is safe string handling,
and the e* functions only cover a small corner area of that space.
Their implemenation also seems half-hearted in many ways. For
instance they have not specified what happens if the error handler
returns to the e* function.
And finally, C-with-exceptions ? Really ?
I far prefer sbuf(3) to e*(3)
For our code, I think I agree.

-- Brooks

Loading...