Re: [RFA] Add la_getstr member to language_defn

Thiago Jung Bauermann
2008-11-24T18:35:22Z

El dom, 23-11-2008 a las 21:28 -0500, Daniel Jacobowitz escribiÃ³:
> On Sun, Nov 23, 2008 at 11:40:21PM -0200, Thiago Jung Bauermann wrote:
> > The comment is wrong. c_getstr actually reads until a null character is
> > found, but doesn't read past the end of an array with known length. I
> > updated the comment to reflect that.
> >
> > Except that there was a bug for GDB-hosted strings, in which case the
> > function behaved as described by the comment. I fixed it now.
>
> Are you sure? I took a look at read_string and its comments and it
> seemed to do what I described - but I might be wrong.
>
> + If LEN is -1, stops at the first null character (not necessarily the first
> + null byte) up to a maximum of FETCHLIMIT characters, otherwise reading
> + proceeds (including null characters) until LEN characters have been read.
> + Set FETCHLIMIT to UINT_MAX to read as many characters as possible from the
> + string.

c_getstr allways passes -1 as the LEN argument, and if the length of the
array is known, it passes the length as FETCHLIMIT. If it is not known,
FETCHLIMIT will be UINT_MAX (actually, the code currently passes -1,
I'll change it to pass UINT_MAX explicitly).

Would the comment above be clearer if it read as follows?

If LEN > 0, reads exactly LEN characters (including eventual NULs in
the middle or end of the string). If LEN is -1, stops at the first
null character (not necessarily the first null byte) up to a maximum
of FETCHLIMIT characters. Set FETCHLIMIT to UINT_MAX to read as many
characters as possible from the string.

By the way, I just realised that if LEN is 0, BUFFER is not allocated,
contradicting the property I mention in the comment that "unless an
exception is thrown, BUFFER will always be allocated, even on failure".
I'll change it to allocate a 1 byte buffer in this case, to keep the
caller's life simple.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center