http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694
--- Comment #13 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-02-17 12:13:53 UTC --- (In reply to comment #12) > the "file" is not seekable so the position eturne by seek always returns > zero. If you mean sseek(), don't count on that; the unix.c:raw_*() functions are more-or-less 1:1 mappings to the POSIX IO API, where the lseek() documentation http://pubs.opengroup.org/onlinepubs/9699919799/functions/lseek.html says "The behavior of lseek() on devices which are incapable of seeking is implementation-defined. The value of the file offset associated with such a device is undefined." and also in the errors section there is: [ESPIPE] The fildes argument is associated with a pipe, FIFO, or socket. FWIW, the need to handle seeking within a record (due to T* and some other edit descriptors) was one of the main motivations to introduce the fbuf layer in the first place. > I plane to see if we can do something with the seek to get it to return a > position within fbuf. If that does not seem reasonable, I will go with the > fbuf_fgetc approach which should be fairly efficient. As I recall, the problem with using fbuf_getc() in read_sf() is that the read_sf() API change would propagate such that one would need to modify all the read_x() functions in read.c to pass a buffer as a parameter rather than getting a pointer into the fbuf buffer to read from. I suspect this particular bug could be fixed by some smallish changes to read_sf() to handle short reads better, but perhaps we need to more fundamentally think about what kind of API we want to have for formatted IO?
