[Swan-dev] err_t

D. Hugh Redelmeier hugh at mimosa.com
Thu Jun 28 03:20:02 UTC 2018


| commit 5c6cd3cf0c32b0ff39fee2de2878bf2337197b8c
| Author: Andrew Cagney <cagney at gnu.org>
| Date:   Wed May 23 13:40:20 2018 -0400
| 
|     includes: move typedef err_t to "err.h"
|     
|     Hidden in libreswan.h (nee openswan.h).  Sprinkle #includes.
|     
|     Given the assumption that pluto is single-threaded no longer
|     holds, this type should probably go away :-/

Memory ownership is a big problem in C programs.  On the other hand,
it is an important aspect of micro-efficiency.

err_t is a perfectly sensible type, with the understanding that it
must be such that

1) it is not the caller's job to manage the memory for err_t

2) the caller must not modify an err_t value

3) the callee must arrange that the value is stable and meaningful
   while the caller might care (perhaps forever)

The simplest example for such a value is a string literal.  Those are
immutable in C.

More complicated cases are possible but difficult.  In particular, the
callee has to have some idea of when the caller would be finished with
the value.  I can think of such protocols, but they don't currently
seem wise.

I have considered some kind of memory allocator for which all memory
is freed automatically when the current transaction / event has been
processed.

For example, this would be quite nice for building diagnostics, with
the understanding that the diagnostic isn't of interest past the
transaction in which it arose.

The problem that err_t addressed was that the code that detected a
problem did not know enough context to nicely log the problem.  To be
honest, this is a multilevel problem, but can usually be reduced to
the two-level case.

This worked very well when our library was designed.  It was to be a 
free-standing library, useful for other programs.  err_t meant that the 
library needed no understanding of how to report errors other than to the 
caller.  It didn't need to know how to log.  This was a big improvement 
over errno.

Still another approach would be for the caller to provide a buffer for
the callee to pass back an error message.  This is awkward, but
appropriate in some cases.

In any case, I like err_t and am skeptical that replacing it in all
cases is an improvement.


More information about the Swan-dev mailing list