Re: [Chicken-users] valgrind - more details

[Jörg F . Wittenberger]

On Oct 5 2011, Christian Kellermann wrote:
Hi Christian,

> Dear Jörg,
>
> * Jörg F. Wittenberger <address@hidden> [111005 22:29]:
> > While I've been following this valgrind hint I ran into some
> > code in C_a_i_string_to_number ... as expectable this code
> > is kinda complicated since the problem it solves is just below
> > the level where one would consider to write a real parser and
> > at the same time beyond complexity you want to handle ad hoc.
>
> Thanks for your analysis!
>
> I am interested in this patch, but I would like to know a couple
> of things:

Wait, this must be a missunderstanding.
This diff was only intended to be read, not compiled.
In fact I did not even compile it.
Because it does not fix a single thing.

Also I'm not sure (after some sleep) that I did not introduce
a fresh bug in the hash-prefix evaluation.

Today I re-read the R5RS, which left me wondering.  Would it be
#bi101010.1 or whould it be #b#i101010.1 ?
Furthermore: 
Also I changed my mind: I'm afraid numbers in Scheme are complex
enough to use a real parser to read them.

The complexity point was here (and a few line down again):

   else if(*eptr2 == '\0' || (eptr != eptr2 && !C_strncmp(eptr2, ".0", 
C_strlen(eptr2)))) {
     *flo = fn;
     return 2;
   }

This use of strlen to compute the n for strncmp removes the point
from using strncmp alltogether.  (Which would be to provide an
upper bound to the comparsion in case you don't want to compare
to the string end or you string does not end with '\0'.  It's
even worse, since the string is now scanned twice.)  So either
one would want to use strcmp here, trusting that the final '\0'
is there (we just put one there before, so given that eptr2
(and further down eptr) did not accidentally end up past the string
end marker - or one wants to supply a upper bound computable in
constant time.  That's what I did like this:

   else if(*eptr2 == '\0' || (eptr != eptr2 && !C_strncmp(eptr2, ".0", len 
- (eptr2-str)))) {
     *flo = fn;
     return 2;
   }

Given that "len" was found to be strlen(str) and eptr2 should be
left within the string, we can simply substract the difference
(eptr2-str) from the counted len of str.

However let me reiterate: it does not fix valgrind's compaint.
And I'm not yet seeing any light in the string_number code so far.

Best Regards

/Jörg