[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Re: [MERGE REQUEST] Re: Another step for libtla
From: |
Matthew Dempsky |
Subject: |
[Gnu-arch-users] Re: [MERGE REQUEST] Re: Another step for libtla |
Date: |
10 Jul 2004 21:48:33 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 |
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