On Fri, 7 Sep 2007 16:16:35 +0200 Magnus Myrefors <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]> 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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
