Re: GError (Re: [Gnu-arch-users] "librifying" libarch)

[Andrew Suffield]

On Mon, Oct 20, 2003 at 01:58:32PM -0700, Tom Lord wrote:
>          _That_ problem, the lack of extensibility, is, I strongly
>            suspect, is the original idea of the `domain' part of a
>            GError.  Anyone can write some code that, at run time,
>            allocates a new domain, and then fills in `code' with a
>            staticly allocated integer.  I've got my set of
>            errno-like-integers, you've got yours, it's the `domain'
>            that sets them apart.  The problem, though, is that the
>            GError designers are suffering from a myth: that error
>            codes have to be integers.
> 
>            Heck, there's a much simpler solution that's just 
>            as good as domain+code:
> 
>               typedef char * arch_error_t;
> 
>             Now, if I want to make a new error code, I can just
>             declare:
> 
>               extern arch_error_t my_err_machine_caught_fire;
> 
>           and define:
> 
>               generic_error_t my_err_machine_caught_fire = 
>                                 ("The machine caught fire");
> 
> 
>           Note that that also gives us a trivial version of the
>             traditonal `strerr' function and plays nicely with i18n.
> 
>             These are just about as good as errno codes.  Whereas with
>             errno codes I can write:
> 
>               if (errno == EEXISTS)
> 
>             now I write:
> 
>               if (err == my_err_machine_caught_fire)
> 
>             The only property lost here is that error codes aren't
>             guaranteed to be small integers (a property also semi-lost
>             in the GError approach).

This is a fragile ABI.

The pointer values are not portable between different processes, so
you'll have to use the string values for IPC. Now you have to make
sure that the strings are properly delimited in transit, that they are
never reused by different components for different purposes, and that
they are never changed except as part of a clear ABI transition, which
should involve compatibility mechanisms and suchlike. That means no
spelling corrections.

Integer values, particularly in the form of enum, solve these problems
quite nicely, and don't have any apparent disadvantages. If you'd
rather have a string value, you can get that via a strerror()-like
function - it'll give you all the same properties as the scheme you
just described.

I'd say that integers *are* the simpler solution. What's wrong with
using integers?

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature