[Gnu-arch-users] [MERGE REQUEST] Re: Another step for libtla

[Tom Lord]

    > From: Matthew Dempsky <address@hidden>

    > I've picked up the work Brian May did on sorting out the arch files
    > into -cmds and -utils, and have updated his patches for Tom's 1.3
    > branch.  

Oh, super!

    > The patches are available in:

    >   address@hidden/tla--libarch--1.3

(converted to a merge request even though you're not done yet.... just
to have it pegged on the wall as something to not lose track of.)

    > I've also started work on step c of Tom's original plan (switching
    > libawk to use alloc_limits), and have a 5kloc changeset for updating
    > relational.c and all of its callers.  However, I need pointers on how
    > to handle associative.c.

What's the issue?  (or is it just the stuff that follows)

    > Also, if I need to change where I put alloc_limits in the argument
    > list for any of the relational.c functions, I can easily do that (I
    > just put it at the beginning of all of them since it was the
    > simplest).

Just to make explicit what I think you're saying: it sounds like you
realize it should go between the return parameters (if any) and the
arguments, right?

    > Finally, the reason I skipped ahead to c rather than do step b
    > (eliminate exits, panics, and safe_* calls from -utils), is I wanted
    > to know how error handling should be done in those.  Will a simple
    > return value (-1 or null as appropriate), or do we need to propogate
    > an error number too?

>From libawk?

I think for most functions, yes, there's only one error condition and
that would be allocation failure.

The I/O functions need to be able to return an errno.

A short-cut that may make it easier to do error propogation upwards
incrementally is to also add "safe_" wrappers for errno-returning
libawk functions and change callers to use that.   Then callers can be
picked off and converted to the error returning forms one by one.

-t