From: Hans L. <han...@re...> - 2007-08-23 12:11:01
|
Currently I am doing some work on the Gnu diction package ("Checks text for readability and bad usage"). To complement the functionality I wrote a cross reference program (xref) using the function fgets. xref can neglect keywords, and currently knows about C, English, German and Dutch. I compiled xref with both current and technology view (sjlj). It works fine. But then I discovered by coincidence tt fails mysteriously and silently on plain text files generated with OpenOffice from Word XP files. Also, it loses track of newlines which I provide the line number of a word in cross reference. So I looked into to the manual of glibc, and discovered that the glibc manual discourages one to use fgets and recommends to use getline instead. Unfortunately, getline seems not to be part of the MingW distribution. Is this true? Or is it a GCC issue? Regards, Hans Lodder PS: By increasing the line buffer size I managed to stop xref from crashing. But it still has the problems as discussed in the glibc library. |
From: Greg C. <chi...@co...> - 2007-08-23 16:50:47
|
On 2007-08-23 12:10Z, Hans Lodder wrote: > > [...] I wrote > a cross reference program (xref) using the function fgets. [...] It > works fine. But then I discovered by coincidence tt fails mysteriously > and silently on plain text files generated with OpenOffice from Word XP > files. Also, it loses track of newlines which I provide the line number > of a word in cross reference. Then there's a defect in the program, but we don't have enough information to guess where. > So I looked into to the manual of glibc, and discovered that the glibc > manual discourages one to use fgets and recommends to use getline > instead. Unfortunately, getline seems not to be part of the MingW > distribution. Is this true? Or is it a GCC issue? Then they're discouraging you from using standard C, and encouraging you to use their nonstandard extension instead. That might indeed be convenient on a platform that provides their extension, but MinGW does not. Yet standard C is powerful enough to write a program such as you describe. > PS: By increasing the line buffer size I managed to stop xref from > crashing. For now. But won't the same problem recur with input files that have even longer lines than you've tested so far? > But it still has the problems as discussed in the glibc library. I'm guessing you mean that an input line might contain an embedded null character. If so, then fread() would seem a better choice than fgets(). Alternatively, if you don't want to mess with low-level C stuff, you might look for a msw library that handles that for you, or consider a higher-level language. |
From: Hans L. <han...@re...> - 2007-08-23 18:16:12
|
Greg Chicares schreef: > On 2007-08-23 12:10Z, Hans Lodder wrote: > >> [...] >> getline seems not to be part of the MingW >> distribution. Is this true? Or is it a GCC issue? >> > > Then they're discouraging you from using standard C, and > encouraging you to use their nonstandard extension instead. > That might indeed be convenient on a platform that provides > their extension, but MinGW does not. > Thanks. Now I get it. > > > an input line might contain an > embedded null character. If so, then fread() would seem a > better choice than fgets(). > > Alternatively, if you don't > want to mess with low-level C stuff, you might look for a > msw library that handles that for you, or consider a > higher-level language. > Indeed, I am thinking about using flex/bison, because that give me the opportunity to concentrate on the currently still unstable requirements. Kind of prototyping I guess. Regards, hans |
From: Brian D. <br...@de...> - 2007-08-24 00:50:55
|
Greg Chicares wrote: > Then they're discouraging you from using standard C, and > encouraging you to use their nonstandard extension instead. > That might indeed be convenient on a platform that provides > their extension, but MinGW does not. Yet standard C is > powerful enough to write a program such as you describe. To be pendatic, getline() will be in the next revision of POSIX, so it can't be considerd non-standard for much longer. But I agree with the sentiment that using getline only because the glibc maintainers say it's a good idea is not the greatest justification -- they have the luxury of ignoring every non-glibc platform in the world, and are notoriously opinionated about it. Brian |