I looked a bit yesterday into figuring out to better control FILE's buffering behavior. The problem is unpleasant enough that Lars had to define a whole separate type UnbufferedFile.

Background: FILE has only setbuf() (uninteresting) and setvbuf() to control buffering. There's no getvbuf() or generally any way to query what buffering mode and what buffer size has been set etc.

I've been looking at the actual definition of the FILE structure and it turns out it is possible (and quite easily) to define query functions that have OS-independent signatures and OS-dependent implementation.

This doesn't add much to the system-specific implementation because the FILE structure itself (which stores information regarding buffering etc.) is already defined in a system-specific manner in core.stdc.stdio.

I think we can define any or all of the following APIs for the File type:

/**
    Returns _IONBF, _IOLBF, or _IOFBF
*/
int getBufferingMode() const;
/**
    Returns the buffer size of the file (will be 1 if file is unbuffered).
*/
size_t getBufferSize() const;

We could even get into more esoteric things like getting how many bytes of lookahead are available or how many bytes could be pushed back into the stream with ungetc().


Thoughts?

Andrei

Andrei Alexandrescu wrote:
>
>
> Thoughts?
>
>

I much prefer the idea of working with FILE* rather than attempting to replace it.

Walter Bright wrote:
>
>
> Andrei Alexandrescu wrote:
>>
>>
>> Thoughts?
>>
>>
>
> I much prefer the idea of working with FILE* rather than attempting to replace it.
>

I mean I agree with your approach.

On Fri, 2010-09-10 at 11:11 -0500, Andrei Alexandrescu wrote:
> I looked a bit yesterday into figuring out to better control FILE's buffering behavior. The problem is unpleasant enough that Lars had to define a whole separate type UnbufferedFile.
> 
> Background: FILE has only setbuf() (uninteresting) and setvbuf() to control buffering. There's no getvbuf() or generally any way to query what buffering mode and what buffer size has been set etc.
> 
> I've been looking at the actual definition of the FILE structure and it turns out it is possible (and quite easily) to define query functions that have OS-independent signatures and OS-dependent implementation.
> 
> This doesn't add much to the system-specific implementation because the FILE structure itself (which stores information regarding buffering etc.) is already defined in a system-specific manner in core.stdc.stdio.


How standardised is the FILE structure?  Are we sure it's the same across different C stdlibs on the various platforms?  (Or is D defined to work only with GNU's C library on POSIX, like it is with DMC on Windows?)

-Lars

On 9/11/10 3:23 CDT, Lars Tandle Kyllingstad wrote:
> How standardised is the FILE structure?  Are we sure it's the same across different C stdlibs on the various platforms?  (Or is D defined to work only with GNU's C library on POSIX, like it is with DMC on Windows?)

Looking in core.stdc.stdio, either D knows the exact FILE layout, or it static assert(false).

Andrei

On Sep 11, 2010, at 7:03 AM, Andrei Alexandrescu wrote:

> On 9/11/10 3:23 CDT, Lars Tandle Kyllingstad wrote:
>> How standardised is the FILE structure?  Are we sure it's the same across different C stdlibs on the various platforms?  (Or is D defined to work only with GNU's C library on POSIX, like it is with DMC on Windows?)
> 
> Looking in core.stdc.stdio, either D knows the exact FILE layout, or it static assert(false).

It's possible that a platform could define it as an opaque type by having it contain a byte array, but so far they all provide the contents.