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

[Matthew Dempsky]

Tom Lord <address@hidden> writes:

>     > 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)

The associative.c stuff uses hackerlab's hashtree functions which seem
to expect the hashtree_rules parameter to specify the alloc_limits to
use, but associative.c only has a single static alloc_limits
parameter.

I suppose one way would be to modify that hashtree_rules before each
hashtree function call, but then the hashtree_rules needs a mutex for
making it multithread safe, and that doesn't seem very clean/pretty.

>     > 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?

Right (just like with Pika's FFI), however, a few of the functions I'm
not sure if you consider them in or out parameters.  Specifically, I'm
concerned about the following functions:

void rel_add_records (alloc_limits limit, rel_table * table, ...);
void rel_add_field (alloc_limits limit, rel_record * r, t_uchar * field);
void rel_append_x (alloc_limits limit, rel_table * out, rel_table t);
void rel_uniq_by_field (alloc_limits limit, rel_table * table, int field);

Like I said, I aded the alloc_limits to the beginning simply because
it seemed like the safest default, but I have the patience to change
it anyway you'd prefer.

>     > 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?

The error code elimination step (step b) is actually about removing
the non-local exits from libarch-utils, but there are a few functions
that do I/O in libawk that panic if there's any problem, so I suppose
this is applicable there too.

> 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.

Can do.

> 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.

Right, I can do that easily.

-jivera