[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GCC 3.2 replacement for streammarker?



So says Steve Greenland:

> On 27-Oct-02, 10:20 (CST), "Steve M. Robbins" <steven.robbins@videotron.ca> wrote: 
> > [Bear in mind, however, that this code dates from 10 years ago,
> > and was developed when stdio was a lot more standard, apparently.
> > They took a lot of liberties with poking about in the FILE structure]
>
> 10 years ago was 3 years after the ANSI/ISO C standard was released, And
> FILE has always[1] been an opaque type. No excuse. As I'm sure you know.

Yes.  They had no excuse.  The authors are bad people.  :-)

However, the code exists and is being used.  
I'd like to keep it buildable with GCC 3.2.


> > Sadly, geomview is too general: it accepts input from many different
> > sources including over the net from a remote machine, the tty, a
> > pipe from another process, a memory buffer, or a bona-fide disk file.
> > 
> > In a perfect world, it needs to occasionally seek backwards on
> > any of those sources.
> 
> Then it needs to do its own buffering. 

I tend to agree.  But I've got better things to do with my weekends
than reimplement the wheel, so:

    I'm looking for a relatively clean implementation of the
    functionality of the stdio stream code (fopen/fseek,fread/etc)
    that is well tested, reasonably portable, and fairly efficient.

I'm going to have a look at glibc, but on first glance, the i/o code
appears heavily intertwined with a lot of other stuff in glibc.  It
would be nice to have some code that can be cleanly separated.  Maybe
someone has implemented buffering on top of file descriptors for use
with sockets?  

I'll take any pointers to such code that I can get!

Thanks,
-Steve



Reply to: