Re: Conversion functions.

[Magnus Myrefors <myrefors magnus telia com>]

On Fri, 7 Sep 2007 16:16:35 +0200
Magnus Myrefors <myrefors magnus telia com> wrote:
By the way I have found out that I used 
a way of reading lines from the input-file which can cause
some problem. I read in a book that fgets(string, sizeof(string), input)
should read one line up to sizeof(string) -1 or to the first newline-
character. But when I tested I found out that that wasn't the case.
That can explain the false data.

Magnus

> I looked at the code and I as far as I also think 
> that something should be printed to stdout.
> The only thing I could see in the code was that malloc
> wasn't used to allocate char *buf in the args to function
> getline().
>
> Magnus
>  
>
> On Fri, 7 Sep 2007 10:08:19 +0200
> David NeÄas (Yeti) <yeti physics muni cz> wrote:
>
> > On Fri, Sep 07, 2007 at 01:45:09AM +0200, Magnus Myrefors wrote:
> > > yeti>> I have tested your minimal testprogram with the whole
> > > test-file. Unfortunately the program doesn't print anything to
> > > stdout. It doesn't seem to be any data stored in the GSList
> > > or in the datastructure, Data *data.
> >
> > If there is any line that starts with a digit (after
> > possible whitespace), it has to print either the data or an
> > error.  If it doesn't, then there is no line whose first
> > non-whitespace character would satisfy g_ascii_isdigit(c) or
> > it does not end up in the list. This means either
> > - g_ascii_isdigit(c) does not evaluate to TRUE for digits
> >   on your system
> > - g_slist_prepend() does not work
> > - g_slist_reverse() does not work
> > - the file looks different than you sent
> >
> > Which one is it?
> >
> > > (I tried to print a field
> > > every time a new line was about to be read in the while-loop).
> > > Furthermore, I wonder if the test,
> > >  if(end == start)
> > >    failfield = "Latitude";,
> > > can conclude that the string was converted correctly with
> > > g_ascii_strtod(). If g_ascii_strtod() converts only a fraction 
> > > of the string, it will result in (end != start) and failfield
> > > won't be set which results in no output to stderr.
> >
> > end is the input to the next conversion, therefore failfield
> > will be set in the next conversion (or trailing garbage
> > message will be printed if it was the last).  Unless the
> > file contain one of the few possible cases of concatenated
> > floating point numbers that can be parsed back -- these can
> > be catched by checking whether *end is space or '\0'.
> >
> > But this does not matter at all.  Either way you get *some*
> > output, either data or errors (or both in the case of
> > trailing garbage).  You must get some output even if
> > g_ascii_strtod() and strtol() return completely random
> > values.  So I just don't believe you.  Period.
> >
> > Yeti
> >
> > --
> > http://gwyddion.net/
> > _______________________________________________
> > gtk-app-devel-list mailing list
> > gtk-app-devel-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list