[Twisted-Python] Re: plus mode was Re: how winnt fileopsworkandwhat to do about it

[Paul G]

----- Original Message ----- 
From: "Paul G" <paul-lists at perforge.com>
To: "Twisted general discussion" <twisted-python at twistedmatrix.com>
Sent: Saturday, December 31, 2005 6:50 PM
Subject: Re: [Twisted-Python] Re: plus mode was Re: how winnt 
fileopsworkandwhat to do about it


>
> ----- Original Message ----- 
> From: "James Y Knight" <foom at fuhm.net>
> To: "Twisted general discussion" <twisted-python at twistedmatrix.com>
> Sent: Saturday, December 31, 2005 6:12 PM
> Subject: Re: [Twisted-Python] Re: plus mode was Re: how winnt fileops 
> workandwhat to do about it
>
>
>>
>> On Dec 31, 2005, at 4:57 PM, Paul G wrote:
>>> oh, it makes perfect sense to have a workaround in twisted, i'm not 
>>> suggesting otherwise. however, it should be just that - a temporary 
>>> workaround until cpython has a fix for the issue, because (outside  of 
>>> the offending libc implementation), that is the right place to  fix it.
>>
>> As I wrote in the bug report:
>>> It's not a python bug except perhaps that python should raise an 
>>> exception.
>>> Doing a read and write without a seek in between is illegal in C.
>>>
>>> "ANSI C requires that a file positioning function intervene between 
>>> output and
>>> input, unless an input operation encounters end-of-file."
>
> you stop quoting right at the relevant part (ie, where the difference 
> between eg glibc and msvcrt comes in):
>
> "(If this condition is not met, then a read is allowed to  return
>       the result of writes other than the most recent.)"
>
> does msvcrt do this? no. moreover, msvcrt needs an *fsetpos()*/fseek() and 
> an *fflush()* (as per cory), whereas glibc will take fseek() or 
> *fgetpos()*. this means that calls resulting in synchronization in glibc 
> and msvcrt are different, with glibc sticking to ansi c and msvcrt 
> deviating.
>
> there is an obvious deviation both from ansi c and from glibc usage.
>
> moreover, none of this seems to be necessary with glibc in practice (and 
> cpython seems to not be doing it or suggesting it in the docs), since this 
> test doesn't fail on linux. different results given the same input is a 
> bug, imo.
>
> let us step back for a second: the problem rears its head in a file object 
> "being returned from the open() method of a FilePath
> object". the user has no way to know that he should be syncing the stream, 
> primarily because he's being given a 'File', not a 'File stream'. either 
> these issues should be listed in the docs, or taken care of underneath, 
> keeping a File a black box. from a design point of view, the stream is an 
> implementation detail - exposing it is ugly.
>
> a matter of how you view it though.

talking to myself: no it isn't. here's the msdn article:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_fopen.2c_._wfopen.asp

see the difference to the excerpt you quoted from fopen(2)? yep, no 'you 
dont have to sync if input op hits eof' exception. this is what's causing 
the breakage with msvcrt but not glibc, i bet. still think it's not a bug/is 
a bug in the test?

i'll go sleep now, so if i've missed the boat again, i won't be here to 
witness the smackdown <g>.

-p