Re: [TCLCORE] Inconsistent buffered I/O

[Tom J. <tom...@gm...>]

All,

I'm going to go out on a limb here and observe that in Tcl there is no
such thing as an unbuffered channel.

It might be possible to construct one in binary mode, but in character
mode, the tclIO.c code seems to make clear that buffering always
occurs, even if it is just a few bytes on each end.

If this observation is correct, then the -buffering none option isn't
a valid description of the buffering situation, but it might represent
the flushing mechanism. With the -buffersize option, you can be
assured after x bytes, the data will be written. Unfortunately you
don't know if all bytes are written, maybe a few less than the buffer
size.

Anyway, it is probably a fiction to think in terms of no buffering in
the tcl channel code. Some buffering must exist. But since seek works
in bytes while read works in chars, any channel which supports both
reads/seeks and writes is bound to fail for some UTF-8 data.

Maybe disable r+? Seems like a totally pointless feature.

If you are looking for those impacted by this change, just ask who
uses r+, all of them are potentially impacted.

Hopefully nobody who runs a nuclear power plant would use r+.

tom jackson

btw, the only reason my previous examples seemed surprising to me was
that I have never opened a file for reading and writing. I just can't
imagine that such a thing would be safe. I haven't discovered anything
which has changed my mind.

On Wed, Nov 25, 2009 at 11:31 AM, Tom Jackson <tom...@gm...> wrote:
> Alex,
>
> My last post just pointed out that you get inconsistent results based
> upon the -buffersize option, "within" -buffering none and/or
> -buffering full. If you don't set -buffersize when -buffering  is
> none, the second write jumps to the end of the file. So the
> inconsistency doesn't depend on just the type of buffering or the
> buffer size. The inconsistency also depends on surrounding code and
> the number of read/write operations.
>
> Anyway, the example in the bug report is just tcl code, what is the
> actual problem, because the inconsistency in your example doesn't rule
> out other sources of inconsistency. Of course, the bug report also
> doesn't describe why interwoven read/writes should be consistent
> across full/none and unrelated to buffering, or even what the expected
> behavior is supposed to be. What I mean is that neither none nor full
> buffering produced expected behavior until I added a [seek $fd 0
> current] prior to each [read] or [puts]. Are both broken? Or what is
> the expected fix, I can test it if you have a patch.
>
> tom jackson
>
>
>
> On Wed, Nov 25, 2009 at 1:14 AM, Alexandre Ferrieux
> <ale...@gm...> wrote:
>> Martin, Tom,
>>
>> Thanks for your ongoing investigation of (1) the current state and (2)
>> workarounds: understanding never harms ...
>>
>> However, the aim of this thread is neither to gather more details on
>> how surprising the current behavior is, nor on script-level
>> workarounds. As it turns out, after a bit of code diving we have a
>> fairly precise idea of what's going on, there's no mystery. And for
>> workarounds, we feel Tcl deserves better than suggesting contorted
>> idioms to avoid so clearly identified shortcomings.
>>
>> Again, the aim is simply to identify whether someone on this planet
>> has real code in production actually _depending_ on this.
>>
>> -Alex
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>