tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Inconsistent buffered I/O

[Alexandre F. <ale...@gm...>]

Tom,

Thanks for this tirade. If nothing else, when I find the time to read
you, it is a nice exercise  of apnea, and it improves my English.
Cool.

Now I will use the sovereign right of _not_ quoting sentence by
sentence; I have already fallen into that trap, and that never ends.
Instead, I'll just give you a summary of the technical details of the
fix we (== Andreas and I, in case you wonder) are envisioning.

 Solution 2a, preferred over 2b by Andreas because it doesn't lift the
hood of the complex buffering system, means "insert a flush/invalidate
between reads and writes" (in both directions). Yes it is a
generalization of what's needed to resolve just the bug under
scrutiny, but it is what we mean by "ironing out": the bug only served
as a signal to let us dive in there.

 Now since you mentioned performance, and whatever detail we omit will
be used for our prosecution, I'll immediately add the following
precisions:

         - this only applies to seekable r/w channels

         - this could be refined by adding "IF THE BUFFERS OVERLAP"

 Of course the notion of "between reads and writes" needs "history".
Are we infringing a patent of yours when we write a patch involving a
new field in a struct, or a new bit in an existing "flags" field ?

-Alex

Re: [TCLCORE] Inconsistent buffered I/O

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

I know I'm not the best at expressing myself, but I'm not wasting my
time spouting off theory.

Instead of guessing at the extent of the "bug" I did actual tests. The
original bug report contained a file with three chars and did one
cycle of read/write.

My testing showed that there are many more variables involved, the
buffer size (even if -buffering is set to none), flushing/seeking
prior to each puts/read. And results depend on more than  one cycle of
read/puts.

So I know in advance that the proposed solutions will not work.

What will work, if it is possible, a solution which will not affect
any working code (but will impact performance for all channel
commands) will do the following:

Establish a two bit of history for each fd. 10 indicates safe for
reading, 01 indicates safe for writing and 11 indicates safe for both
(typical initial condition, or after flush/seek/etc.)

If such a history, or an equivalent cannot be established, then it is
guaranteed that you will change the operation of the channel code so
that buffering will not exist.

One of the proposed solutions (2a) is a flush prior to read. This
applies to every read? If not, how do you figure out when to apply it?
(Using a history avoids this overhead.)

But the problem is that my testing clearly shows that you must also do
something prior to a write, if you previously did a read (and no
intervening seek or flush).

So following the 2a solution, a seek (which includes a flush) or a
flush is required prior to any read or write/puts.

This situation would appear to be equivalent to no buffering. But in
Tcl it isn't.

With no buffering (-buffering none) but without the seek/flush prior
to each read/puts, you will get unexpected results (you must also set
a -buffersize to get correct results).

The solution (seek/flush prior to any read/puts) will solve the
current "bug", but it will result in poor performance and behavior
changes.

Performance: this is the reason we use buffers.

Maybe ask yourself: do you really think you have discovered a 20 year
old bug, a bug so severe that nobody could possibly be using code
which reads and writes without intervening seek/flush?

Really? You found a 20 year old serious bug?

My experience suggests that you pay a price for everything. You want
consistency between buffered read and write? It will cost you. Telling
you guys you don't know what you are doing? Yes it will cost me. You
can have a cheerleading pep talk if you want. Pump yourselves up if
you want. But you are not going to discover some magic and free way to
get around this.

Scientist require lots of proof to overturn long believed theories. If
code has held up for 20 years, I think the proof should be a little
more than a three char file. I've already proved this is an incomplete
picture.

BTW, the problem also infects w+, assuming it is a problem.

Did anyone besides me check that? No.

If the problem took 20 years to identify, the first step should be
establishing expected results for every combination of options.
Otherwise the fix may break something else. Nobody is affected by the
current "bug", somebody may be affected by the fix.

If I have breached the decorum of this list, sorry.

Just remember, you propose to change the way tcl works. The way tcl
works is important to me, maybe you don't like the way it works. Most
people like it, nobody has complained about this particular issue in
20 years. The silence is deafening.

Ever heard of the story of Chicken Little? The sky is falling?
Chickens! The sky is not falling. If the sky was falling, someone else
would have noticed by now. Or maybe the original tclers were just a
bunch of dumb-shits, and all the users for the last 20 years, total
morons. Or maybe they figured out what I figured out with a few hours
of research? Twenty years worth of code, twenty years worth of users
and nobody noticed such a trivial bug...one which can be demonstrated
with a three char long file.

Somehow 20 years worth of tclers never got it right, never even
noticed it was wrong! According to this group. This represents either
an extreme amount of hubris or an extremely low opinion of the
programming skills of everyone else.

I admit I never noticed, but for good reason: I never open a file for
reading and writing. But it didn't take me too long to come up with a
solution. I guess I'm an idiot for figuring out something which is
guaranteed to work and never impact anyone else who uses read/puts.
That is what I call doing it right. I don't believe in babysitting
novice programmers.

tom jackson

The hardest bug to find is one which doesn't exist.




On Thu, Nov 26, 2009 at 8:17 AM, Kevin Kenny <kev...@gm...> wrote:
> Donal K. Fellows wrote:
>>
>> In short: Damnit! We're Tclers! We'll do this _Right_!
>
> Preach it, brother!

Re: [TCLCORE] Inconsistent buffered I/O

[Kevin K. <kev...@gm...>]

Donal K. Fellows wrote:
> In short: Damnit! We're Tclers! We'll do this _Right_!

Preach it, brother!

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] Inconsistent buffered I/O

[Alexandre F. <ale...@gm...>]

On 11/26/09, Donal K. Fellows <don...@ma...> wrote:
>
> [...]
>  It's just a bug. Now we're aware of it, we can fix it. Then we all live
>  happily ever after. The End.

OK. So shall I conclude that the POTENTIAL INCOMPATIBILITY is
accepted, and proceed with the patch ? See details of the proposed fix
in the tracker.

-Alex

Re: [TCLCORE] Inconsistent buffered I/O

[Donal K. F. <don...@ma...>]

Tom Jackson wrote:
> I decided to refer to _Advanced Programming in the UNIX Environment_
> for insight into this particular problem.
> 
> On page 126 (Chapter 5: Standard I/O Library):
[...]
> I think this pretty much explains my success with using [seek] prior
> to every read/puts.

We don't use the C standard library for I/O. This was originally because 
it sucked on Windows, but now is because it allows us to implement more 
operations correctly (EOL translation, encoding handling, the notifier, 
etc.) It seems that we've not got buffer flushing correct yet so that we 
can drop more of the restrictions that C imposes.

In short: Damnit! We're Tclers! We'll do this _Right_!

Donal.

Re: [TCLCORE] Inconsistent buffered I/O

[Donal K. F. <don...@ma...>]

Tom Jackson wrote:
> On Wed, Nov 25, 2009 at 2:10 PM, Kevin Kenny <kev...@gm...> wrote:
>> (By the way, I'm pretty much in agreement with you and Alex that
>> the failure to flush in the scenario under discussion is a bug.
>> But I'm annoyed at the heights of rhetoric that have been reached
>> in this thread.)
> 
> Something weird is going on, exactly what is not apparent (to me) at
> the tcl level. I don't think the problem is just a misunderstanding of
> how to use the different channel commands (my example showing how to
> equalize different options doesn't prove a bug doesn't exist), but the
> expected behavior is, at best, poorly defined.

There's a general goal in Tcl of avoiding getting into the situation 
where "something weird is going on" is the best diagnosis. When we're in 
that situation, we just call it a bug and try to change things so that 
behaviour is both not weird and clearly documented. Looks like there's 
more to do with buffer flushing in the presence of [seek]; not an area 
of Tcl where I work for preference (my expertise is elsewhere).

I also agree with Kevin that the rhetoric level isn't justified. It's 
just a bug. Now we're aware of it, we can fix it. Then we all live 
happily ever after. The End.

Donal.

Re: [TCLCORE] Inconsistent buffered I/O

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

I decided to refer to _Advanced Programming in the UNIX Environment_
for insight into this particular problem.

On page 126 (Chapter 5: Standard I/O Library):

"When a file is opened for reading and writing (the plus sign in the
type) the following restrictions apply:

* Output cannot be directly followed by input without an intervening
fflush, fseek, fsetpos, or rewind.
* Input cannot be directly followed by output without an intervening
fseek, fsetpos or rewind, or an input operation that encounters an end
of file."

I think this pretty much explains my success with using [seek] prior
to every read/puts.

tom jackson


On Wed, Nov 25, 2009 at 8:57 PM, Tom Jackson <tom...@gm...> wrote:
> On Wed, Nov 25, 2009 at 2:10 PM, Kevin Kenny <kev...@gm...> wrote:
>> Tom Jackson wrote:
>>
>>> 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.
>>
>> Totally a red herring if the encoding of the channel is *not* UTF-8.
>
> If? Sorry if I didn't realize that this fix was directed at only *not*
> UTF-8 stuff.
>
>> UTF-8 is seldom used in the scenario where you're seeking around.
>
> Yet nothing prevents (nor should prevent) code which includes such scenarios.
>
>> If you have to write UTF-8 data to the channel, you use
>> [encoding convertto] to encode it, and use binary encoding on the
>> channel.
>
> Yet when I recommend using [seek $fd 0 current] this in not okay. Your
> perfectly valid and correct interpretation implies that command
> sequences are more important than individual commands in determining
> expected results.
>
> As a basic premise I assume that different code should or at least
> could produce different results. Different code includes different
> configuration. Otherwise the only conclusion is that multiple initial
> conditions converge to one solution. If multiple starting conditions
> lead to the same result, why not consolidate these apparently
> different starting conditions into one?
>
> In summary: every distinct initial condition should produce a distinct
> and unique result. Can there be overlap? Yes. But I would be more
> concerned if two distinct initial conditions produced the same
> results.
>
>> Also, there's an important special case where you seek only to
>> the position of an earlier [tell].  That surely works no matter
>> what encoding is in use for the channel.
>
> I just performed an experiment. I have no idea why the results were
> identical, regardless of buffering mode or buffer size. I merely made
> an observation. I was actually surprised by the result. No other
> experiment produced the expected result.
>
> But I have to admit I am basically confused. If there is a bug in the
> code how can I demonstrate the bug unless I specify the expected
> result? This has got to be the most fundamental requirement. I still
> have no idea what the expected results are for each situation.
>
>>> Maybe disable r+? Seems like a totally pointless feature.
>>
>> What on Earth are you yammering about here?  The commonest case
>> for r+ is to open the channel, read some set of content, rewind
>> (seek to 0) and rewrite the content.  The purpose of the [r+] is
>> to acquire the write lock immediately on those filesystems where it
>> matters, and to fail fast if the file is not writable.
>
> Could someone provide an example? When I look at the options for
> opening a file I don't find any that allows opening an existing file,
> exclusively and for writing.
>
> r+ = open a file for reading and writing (is this exclusive access?)
> [open $file {RDWR}] = open a file for reading and writing
> [open $file {RDWR CREAT EXCL} ] = exclusive read/write access to a new file
>
>
>> (By the way, I'm pretty much in agreement with you and Alex that
>> the failure to flush in the scenario under discussion is a bug.
>> But I'm annoyed at the heights of rhetoric that have been reached
>> in this thread.)
>
> Something weird is going on, exactly what is not apparent (to me) at
> the tcl level. I don't think the problem is just a misunderstanding of
> how to use the different channel commands (my example showing how to
> equalize different options doesn't prove a bug doesn't exist), but the
> expected behavior is, at best, poorly defined.
>

Re: [TCLCORE] Inconsistent buffered I/O

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

On Wed, Nov 25, 2009 at 2:10 PM, Kevin Kenny <kev...@gm...> wrote:
> Tom Jackson wrote:
>
>> 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.
>
> Totally a red herring if the encoding of the channel is *not* UTF-8.

If? Sorry if I didn't realize that this fix was directed at only *not*
UTF-8 stuff.

> UTF-8 is seldom used in the scenario where you're seeking around.

Yet nothing prevents (nor should prevent) code which includes such scenarios.

> If you have to write UTF-8 data to the channel, you use
> [encoding convertto] to encode it, and use binary encoding on the
> channel.

Yet when I recommend using [seek $fd 0 current] this in not okay. Your
perfectly valid and correct interpretation implies that command
sequences are more important than individual commands in determining
expected results.

As a basic premise I assume that different code should or at least
could produce different results. Different code includes different
configuration. Otherwise the only conclusion is that multiple initial
conditions converge to one solution. If multiple starting conditions
lead to the same result, why not consolidate these apparently
different starting conditions into one?

In summary: every distinct initial condition should produce a distinct
and unique result. Can there be overlap? Yes. But I would be more
concerned if two distinct initial conditions produced the same
results.

> Also, there's an important special case where you seek only to
> the position of an earlier [tell].  That surely works no matter
> what encoding is in use for the channel.

I just performed an experiment. I have no idea why the results were
identical, regardless of buffering mode or buffer size. I merely made
an observation. I was actually surprised by the result. No other
experiment produced the expected result.

But I have to admit I am basically confused. If there is a bug in the
code how can I demonstrate the bug unless I specify the expected
result? This has got to be the most fundamental requirement. I still
have no idea what the expected results are for each situation.

>> Maybe disable r+? Seems like a totally pointless feature.
>
> What on Earth are you yammering about here?  The commonest case
> for r+ is to open the channel, read some set of content, rewind
> (seek to 0) and rewrite the content.  The purpose of the [r+] is
> to acquire the write lock immediately on those filesystems where it
> matters, and to fail fast if the file is not writable.

Could someone provide an example? When I look at the options for
opening a file I don't find any that allows opening an existing file,
exclusively and for writing.

r+ = open a file for reading and writing (is this exclusive access?)
[open $file {RDWR}] = open a file for reading and writing
[open $file {RDWR CREAT EXCL} ] = exclusive read/write access to a new file


> (By the way, I'm pretty much in agreement with you and Alex that
> the failure to flush in the scenario under discussion is a bug.
> But I'm annoyed at the heights of rhetoric that have been reached
> in this thread.)

Something weird is going on, exactly what is not apparent (to me) at
the tcl level. I don't think the problem is just a misunderstanding of
how to use the different channel commands (my example showing how to
equalize different options doesn't prove a bug doesn't exist), but the
expected behavior is, at best, poorly defined.

Re: [TCLCORE] Inconsistent buffered I/O

[Kevin K. <kev...@gm...>]

Tom Jackson wrote:

> 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.

Totally a red herring if the encoding of the channel is *not* UTF-8.
UTF-8 is seldom used in the scenario where you're seeking around.
If you have to write UTF-8 data to the channel, you use
[encoding convertto] to encode it, and use binary encoding on the
channel.

Also, there's an important special case where you seek only to
the position of an earlier [tell].  That surely works no matter
what encoding is in use for the channel.

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

What on Earth are you yammering about here?  The commonest case
for r+ is to open the channel, read some set of content, rewind
(seek to 0) and rewrite the content.  The purpose of the [r+] is
to acquire the write lock immediately on those filesystems where it
matters, and to fail fast if the file is not writable.

(By the way, I'm pretty much in agreement with you and Alex that
the failure to flush in the scenario under discussion is a bug.
But I'm annoyed at the heights of rhetoric that have been reached
in this thread.)

-- 
73 de ke9tv/2, Kevin

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
>>
>

Re: [TCLCORE] Inconsistent buffered I/O

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

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
>

Re: [TCLCORE] Inconsistent buffered I/O

[Alexandre F. <ale...@gm...>]

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

Re: [TCLCORE] Inconsistent buffered I/O

[Martin L. <mar...@gm...>]

Hi,

isn't it still the way, that the buffer size can not be set to 0 Bytes?

The minimum buffer size is 10 Bytes - says the documentation!

% set fd [open c:/temp/new.txt w]
filec63098
% fconfigure $fd -buffering full -buffersize 0
% fconfigure $fd
-blocking 1 -buffering full -buffersize 1 -encoding cp1252 -eofchar {} -translation crlf
% fconfigure $fd -buffering full -buffersize 10000000
% fconfigure $fd
-blocking 1 -buffering full -buffersize 1048576 -encoding cp1252 -eofchar {} -translation crlf

The example in tcl 8.5.7 tells me, that the minimum buffer size seems to be 1 Byte not 10 Bytes and the maximum buffersize is not 1'000'000 Bytes, but 1 MByte = 1'048'576 Bytes. Strange!

I get more and more the impression, that at first the documentation of the current behaviour with all the obstacles should be updated (with examples), even for the next releases (8.5.9, 8.6.0) perhaps not containing a "bug" fix.

Best regards,

Martin Lemburg


-------- Original-Nachricht --------
> Datum: Tue, 24 Nov 2009 10:47:15 -0800
> Von: Tom Jackson <tom...@gm...>
> An: tcl...@li...
> Betreff: Re: [TCLCORE] Inconsistent buffered I/O

> BTW, I'm not really for or against any change, I was just starting off
> by looking at a few more examples than the original description of the
> "bug". The original examples did not include the fact that in both
> buffering cases, r+ moves the input "cursor" to the end of the file
> after some channel operations. And both start with the file open at
> the beginning of the file.
> 
> Notice the definitions of a and a+. In a mode, the file opens at the
> end of the file, but you can move the cursor before you write. With
> a+, the under the covers code always positions the input cursor at the
> end of the file just before it performs the write. So "a+" is atomic
> in positioning/write, but "a" does not guarantee that. r+ is similar
> to "a" except it starts at file end and would require a [seek] to
> guarantee moving to the end of file before a write.
> 
> The above analysis  is the result of too few examples. The largest
> effect on results appears to be the buffersize.
> 
> Here's an example:
> #!/usr/bin/env /home/tom/bin/tclsh8.6
> 
> set 30count 123456789012345678901234567890
> set alpha   ABCDEFGHIJKLMNOPQRSTUVWXYZ
> set lalpha  abcdefghijklmnopqrstuvwxyz
> 
> exec echo $alpha > abc.txt
> 
> set fd [open abc.txt r+]
> 
> fconfigure $fd -buffering full -buffersize 13
> 
> puts -nonewline $fd 123456
> seek $fd 3
> set char [read $fd 2]
> puts -nonewline $fd 789
> set char2 [read $fd 2]
> flush $fd
> 
> close $fd
> 
> puts "$char $char2"
> 
> The result is:
> 45 6G
> 1234567HIJKLMNOP789TUVWXYZ
> 
> Second input position = 13+3+1 = 17
> The last 1  is due to reading two chars and advancing one position.
> 
> Change the buffersize to 12:
> 45 6G
> 123456GHIJKLMNO789STUVWXYZ
> Second input position = 12+3+1 = 16
> 
> The example also shows that what you are reading is the new file, not
> the original file., but seeking and reading advance both cursors. With
> a buffer size of zero:
> 
> 45 6G
> 123456GHIJKLMNOPQRSTUVWXYZ
> 789
> 
> (second insert at end of file).
> 
> tom jackson
> 
> On Tue, Nov 24, 2009 at 4:58 AM, Alexandre Ferrieux
> <ale...@gm...> wrote:
> > On 11/24/09, Martin Lemburg <mar...@gm...> wrote:
> >
> >>  This problem of buffered channels, needed to write to and to read
> from, is a part of the
> >> things a developer should be able to think of!
> >
> > Yes, but it's not a question about whether to expose or not a
> > low-level, powerful tool.
> > It is about whether to expose or not a complex, unpredictable[*], and
> > useless behavior.
> >
> > [*] unpredictable, because in the buffered case, flushes may occur
> > depending on the past (ie buffer filling), so the same [puts];[read]
> > sequence will have varied outcomes.
> >
> > In other words, I came here to hear about people explaining why they
> > _depend_ on the current behavior (so that the proposed change would be
> > disruptive to them), not boilerplate statements about power vs.
> > simplicity ;-)
> >
> > -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
> >
> 
> ------------------------------------------------------------------------------
> 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

-- 
Martin Lemburg - 10551 Berlin - Germany

Re: [TCLCORE] Inconsistent buffered I/O

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

Hey, I stumbled across a way to get consistent results for -buffering
full/none with any size buffer.

The -buffersize seems to be important when you use -buffering none.

Here is the script. Just change the variables buffer and bufsize and
run the file.

The read/write loop doesn't require using flush for either full/none,
but both [seek] calls are required to get consistent and the expected
results with "none" and to avoid an error with "full".

Here it is:
#!/usr/bin/env /home/tom/bin/tclsh8.6

set AAA     [string repeat ABCDEFGHIJKLMNOPQRSTUVWXY 4]
set 123     [string repeat 1234567890 10]

exec echo $AAA > AAA100.txt
exec echo $123 >> AAA100.txt

set fd [open AAA100.txt r+]

# Select full/none and choose buffer size
set buffer full
set bufsize 20
fconfigure $fd -buffering $buffer -buffersize $bufsize

foreach num {1 2 3 4 5} {
    seek $fd 0 current
    set start [tell $fd]
    puts -nonewline $fd [string repeat $num 11]
    set end [tell $fd]
    seek $fd 0 current
    set repos [tell $fd]
    set char  [read $fd 1]
    set final [tell $fd]
    puts stdout "$num start = $start end = $end repos = $repos final =
$final char = $char"
}
close $fd

Expected results regardless of buffer type and bufsize:

tom@boron:~/bin$ ./rwplus-multiline.tcl
1 start = 0 end = 11 repos = 11 final = 12 char = L
2 start = 12 end = 23 repos = 23 final = 24 char = X
3 start = 24 end = 35 repos = 35 final = 36 char = K
4 start = 36 end = 47 repos = 47 final = 48 char = W
5 start = 48 end = 59 repos = 59 final = 60 char = J
tom@boron:~/bin$ cat AAA100.txt
11111111111L22222222222X33333333333K44444444444W55555555555JKLMNOPQRSTUVWXYABCDEFGHIJKLMNOPQRSTUVWXY
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890

tom jackson

Re: [TCLCORE] Inconsistent buffered I/O

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

BTW, I'm not really for or against any change, I was just starting off
by looking at a few more examples than the original description of the
"bug". The original examples did not include the fact that in both
buffering cases, r+ moves the input "cursor" to the end of the file
after some channel operations. And both start with the file open at
the beginning of the file.

Notice the definitions of a and a+. In a mode, the file opens at the
end of the file, but you can move the cursor before you write. With
a+, the under the covers code always positions the input cursor at the
end of the file just before it performs the write. So "a+" is atomic
in positioning/write, but "a" does not guarantee that. r+ is similar
to "a" except it starts at file end and would require a [seek] to
guarantee moving to the end of file before a write.

The above analysis  is the result of too few examples. The largest
effect on results appears to be the buffersize.

Here's an example:
#!/usr/bin/env /home/tom/bin/tclsh8.6

set 30count 123456789012345678901234567890
set alpha   ABCDEFGHIJKLMNOPQRSTUVWXYZ
set lalpha  abcdefghijklmnopqrstuvwxyz

exec echo $alpha > abc.txt

set fd [open abc.txt r+]

fconfigure $fd -buffering full -buffersize 13

puts -nonewline $fd 123456
seek $fd 3
set char [read $fd 2]
puts -nonewline $fd 789
set char2 [read $fd 2]
flush $fd

close $fd

puts "$char $char2"

The result is:
45 6G
1234567HIJKLMNOP789TUVWXYZ

Second input position = 13+3+1 = 17
The last 1  is due to reading two chars and advancing one position.

Change the buffersize to 12:
45 6G
123456GHIJKLMNO789STUVWXYZ
Second input position = 12+3+1 = 16

The example also shows that what you are reading is the new file, not
the original file., but seeking and reading advance both cursors. With
a buffer size of zero:

45 6G
123456GHIJKLMNOPQRSTUVWXYZ
789

(second insert at end of file).

tom jackson

On Tue, Nov 24, 2009 at 4:58 AM, Alexandre Ferrieux
<ale...@gm...> wrote:
> On 11/24/09, Martin Lemburg <mar...@gm...> wrote:
>
>>  This problem of buffered channels, needed to write to and to read from, is a part of the
>> things a developer should be able to think of!
>
> Yes, but it's not a question about whether to expose or not a
> low-level, powerful tool.
> It is about whether to expose or not a complex, unpredictable[*], and
> useless behavior.
>
> [*] unpredictable, because in the buffered case, flushes may occur
> depending on the past (ie buffer filling), so the same [puts];[read]
> sequence will have varied outcomes.
>
> In other words, I came here to hear about people explaining why they
> _depend_ on the current behavior (so that the proposed change would be
> disruptive to them), not boilerplate statements about power vs.
> simplicity ;-)
>
> -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
>

Re: [TCLCORE] Inconsistent buffered I/O

[Alexandre F. <ale...@gm...>]

On 11/24/09, Martin Lemburg <mar...@gm...> wrote:

>  This problem of buffered channels, needed to write to and to read from, is a part of the
> things a developer should be able to think of!

Yes, but it's not a question about whether to expose or not a
low-level, powerful tool.
It is about whether to expose or not a complex, unpredictable[*], and
useless behavior.

[*] unpredictable, because in the buffered case, flushes may occur
depending on the past (ie buffer filling), so the same [puts];[read]
sequence will have varied outcomes.

In other words, I came here to hear about people explaining why they
_depend_ on the current behavior (so that the proposed change would be
disruptive to them), not boilerplate statements about power vs.
simplicity ;-)

-Alex

Re: [TCLCORE] Inconsistent buffered I/O

[Martin L. <mar...@gm...>]

Hi Alex,

> Anyway, it seems we can count you as +1 for the proposed change, right ?

I can live with a change in behaviour. But I still do not see the absolute necessarity for this change. Why ... see below ...

> >  Using buffering on read/write IO every developer should think about
> > "racing conditions" and take care for them.
> 
> Leaving this complexity in the script writer's lap is not good IMO.
> Tcl is appreciated for providing useful abstractions, not for exposing
> self-created contradictions.

Yes, tcl is providing useful abstractions, but tcl is a wonderful high level development language and developing complex applications needs to think in a clear way of the consequences of those things.

Developing complex scripts with tcl needs to be conscious about complex relations, consequences and needs!

This problem of buffered channels, needed to write to and to read from, is a part of the things a developer should be able to think of!

To explain the tcl developers the complexity of IO and to leave it to him to care for side effects is normal and my favorite.
To change the IO flush policy is surely to easier the life of developers, but hides only away complexity.

What's about the following:
1. don't do automatic flush on channels by default
2. extend fconfigure with a -flushing (synonym to -buffering) option
3. allow the following values for -flushing:
   - none - default
   - always - after each write, no matter with "-nonewline" or not, a flush will done and the buffer will be emptied - disabling in consequence the write buffer 
   - automatic - before each seek and read or other actions needing a correct current IO position, a flush is done, if a write action succeeded in filling the buffer

So the developers can switch on the automatic flush, if they want and the default behaviour won't be changed by your proposed changes.

Best regards,

Martin Lemburg

-------- Original-Nachricht --------
> Datum: Tue, 24 Nov 2009 10:12:03 +0100
> Von: Alexandre Ferrieux <ale...@gm...>
> An: Martin Lemburg <mar...@gm...>
> CC: tcl...@li...
> Betreff: Re: [TCLCORE] Inconsistent buffered I/O

> On 11/24/09, Martin Lemburg <mar...@gm...> wrote:
> >
> >  Using buffering on read/write IO every developer should think about
> "racing conditions" and take care for them.
> 
> Leaving this complexity in the script writer's lap is not good IMO.
> Tcl is appreciated for providing useful abstractions, not for exposing
> self-created contradictions.
> 
> >  But ... we could "install" just this rule above, like Tom suggested.
> >  Every buffered channel opened in r+ or w+ mode could flush a non-empty
> buffer if already written to this channel before processing a read access:
> 
> Ahem, not sure it's Tom who suggested it ;-)
> Anyway, it seems we can count you as +1 for the proposed change, right ?
> 
> >  This is IMO only a change of policy, but not a bug fix, because I still
> does not see a bug in this "logical" behaviour.
> 
> Whatever. The purpose of this thread is to evaluate the feasibility of
> the change, not to fight on terminology.
> 
> -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

-- 
Martin Lemburg - 10551 Berlin - Germany

Re: [TCLCORE] Inconsistent buffered I/O

[Alexandre F. <ale...@gm...>]

On 11/24/09, Martin Lemburg <mar...@gm...> wrote:
>
>  Using buffering on read/write IO every developer should think about "racing conditions" and take care for them.

Leaving this complexity in the script writer's lap is not good IMO.
Tcl is appreciated for providing useful abstractions, not for exposing
self-created contradictions.

>  But ... we could "install" just this rule above, like Tom suggested.
>  Every buffered channel opened in r+ or w+ mode could flush a non-empty buffer if already written to this channel before processing a read access:

Ahem, not sure it's Tom who suggested it ;-)
Anyway, it seems we can count you as +1 for the proposed change, right ?

>  This is IMO only a change of policy, but not a bug fix, because I still does not see a bug in this "logical" behaviour.

Whatever. The purpose of this thread is to evaluate the feasibility of
the change, not to fight on terminology.

-Alex

Re: [TCLCORE] Inconsistent buffered I/O

[Martin L. <mar...@gm...>]

Hi Alex,

yes, my point of view is not that "easy".

It is the result of a learning curve, having used buffering while writing/reading from files and wondering about a "strange" behaviour.

So I set rules for me, like flush a buffered channel after writing before reading.

But the reason for the behaviour of buffered channels in a mixture of writing and reading is the collision of an explicetly set buffering and the channel access and the resulting physical effects.

Using buffering on read/write IO every developer should think about "racing conditions" and take care for them.

But ... we could "install" just this rule above, like Tom suggested.
Every buffered channel opened in r+ or w+ mode could flush a non-empty buffer if already written to this channel before processing a read access:

    if {   [$channel mode] in {r+ w+}
        && [$channel buffer mode] ne "none"
        && [$channel justwrittento]
        && ![$channel buffer isempty]} {
        flush $channel;
    }

This is IMO only a change of policy, but not a bug fix, because I still does not see a bug in this "logical" behaviour.

Another question is, if seek should flush or not - even if it is documented.
Changing this will cause troubles, because some software may rely on this behaviour, even if it would be better to explicitely flush and then seek.

We could refine the "seek flush" rule to be like the one above about "read after write" rule - flush in seek only if the buffer is non-empty after a write access to prevent mismatching positions before the next positioned write or read access:

    if {   [$channel mode] in {r+ w+}
        && [$channel buffer mode] ne "none"
        && [$channel justwrittento]
        && ![$channel buffer isempty]} {
        flush $channel;
    }

Introducing this rule for seek and read on r+ and w+ channels after a write access introduces automatisms, developers will rely on and changing them afterwards could be impossible.

But telling developers, that they have to flush a buffered r+, w+ channel before reading from it, that is less complex for the tcl core and does not introduce such automatisms, other will rely on.

Currently I'm not able to try Toms examples for misleading IO access, but he pointed out some other strangers not really related to the question above, if to introduce a kind of "flush" rule.

Best regards,

Martin Lemburg
-------- Original-Nachricht --------
> Datum: Tue, 24 Nov 2009 09:11:11 +0100
> Von: Alexandre Ferrieux <ale...@gm...>
> An: mar...@gm...
> CC: tcl...@li...
> Betreff: Re: [TCLCORE] Inconsistent buffered I/O

> On 11/23/09, Martin Lemburg <mar...@gm...> wrote:
> >
> >  Hello Alex,
> >
> >  since I know tcl, the described consequence of the following code is
> well
> > known for me and no bug (in my eyes):
> >
> >  set f [open foo r+]
> >  fconfigure $f -buffering full
> >  puts -nonewline $f Z
> >  puts [read $f] ----> ABC
> >  Since not flushing the buffer is not written to the file and so reading
> the
> > file brings up the non-manipulated, original contents.
> >
> >  This is IMO obvious and not a bug. This problem is about physical
> effects
> > of programmatical settings.
> 
> Ah, everything is obvious ? Just add [seek $f 0] after the [puts] and
> you get "ZBC". Do you think that this effect is a crystalline
> consequence of the well-known semantics of all primitives ? (Yes, the
> fact that [seek] causes a flush is documented. We have a long
> tradition of documenting bugs before fixing them).
> 
> -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

-- 
Martin Lemburg - 10551 Berlin - Germany

Re: [TCLCORE] Inconsistent buffered I/O

[Alexandre F. <ale...@gm...>]

On 11/23/09, Tom Jackson <tom...@gm...> wrote:
>
> [...]
>  This demonstrates that the "cursor" for read and write are
>  independent, since the read position stayed at 2 even after the seek
>  and flush.

Yes. This "split" of _the_ cursor into two is exactly what bug 2901998
is about ;-)
The existence of (only) [seek/tell] implies that there is just one
cursor, so having two of them under the cover is a violation of the
contract.

My point is that _if_ we accept a potential incompatibility by ironing
this out, all the other weird things that you observe will vanish
instantly. The driving idea is that rather than saying that
[-buffering full] follows a precisely documented algorithm to decide
when to flush (and endlessly struggle with the contradictions of that
algorithm), we'd say that it is merely an optimization achieving a
smaller number of write() syscalls on average, the details staying
under the hood.

 I believe this intentional hiding of the details is in the same
spirit as Tcl's internal representations which stay hidden below the
polished EIAS surface. Here the polished surface would be that of the
single [seek/tell] pointer.

-Alex

Re: [TCLCORE] Inconsistent buffered I/O

[Alexandre F. <ale...@gm...>]

On 11/23/09, Martin Lemburg <mar...@gm...> wrote:
>
>  Hello Alex,
>
>  since I know tcl, the described consequence of the following code is well
> known for me and no bug (in my eyes):
>
>  set f [open foo r+]
>  fconfigure $f -buffering full
>  puts -nonewline $f Z
>  puts [read $f] ----> ABC
>  Since not flushing the buffer is not written to the file and so reading the
> file brings up the non-manipulated, original contents.
>
>  This is IMO obvious and not a bug. This problem is about physical effects
> of programmatical settings.

Ah, everything is obvious ? Just add [seek $f 0] after the [puts] and
you get "ZBC". Do you think that this effect is a crystalline
consequence of the well-known semantics of all primitives ? (Yes, the
fact that [seek] causes a flush is documented. We have a long
tradition of documenting bugs before fixing them).

-Alex

Re: [TCLCORE] Inconsistent buffered I/O

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

I'm not sure what the inconsistency is here. Nothing is written to the
file until the buffer is filled up.

But I think there is another issue here which isn't covered in the use case.

What happens to the Z written with [puts -nonewline $fd Z]?

If you don't flush the buffer to file, you lose the contents during
the read operation:

% echo ABC > abc.txt
% set fd [open abc.txt r+]
file164c9a0
% fconfigure $fd -buffering full
% puts -nonewline $fd Z
% set char [read $fd 1]
A
% flush $fd
% set char [read $fd 1]
B
% seek $fd 0
% read $fd 1
A
% read $fd 1
B
% read $fd 1
C

I guess you could claim that the attempt to read on the channel should
force the write buffer to flush.

What happens if you puts, seek and then write:

% echo ABC > abc.txt
% set fd [open abc.txt r+]
file164d320
% fconfigure $fd -buffering full
% puts -nonewline $fd Z
% seek $fd 2
% flush $fd
% tell $fd
2
% read $fd 1
C
% seek $fd 0
% read $fd 1
Z

This demonstrates that the "cursor" for read and write are
independent, since the read position stayed at 2 even after the seek
and flush.

But here is something weird:

% echo ABC > abc.txt
% set fd [open abc.txt r+]
file164ca20
% fconfigure $fd -buffering full
% puts -nonewline $fd H
% tell $fd
1
% read $fd 1
A
% tell $fd
-1
% seek $fd 0
error during seek on "file164ca20": bad address in system call argument
% tell $fd
-1
% flush $fd
% tell $fd
2
% read $fd 1
B
% seek $fd 0
% read $fd
ABC
H

So what is happening here is different than what my original example
seemed to show. The flush actually just appends the buffer to the end
of the file.

But the same thing happens with -buffering none, after the first [puts]:

% echo ABC > abc.txt
% set fd [open abc.txt r+]
file164c9a0
% fconfigure $fd -buffering none
% seek $fd 1
% puts -nonewline $fd T
% read $fd 1
C
% seek $fd 1
% read $fd 1
T
% seek $fd 0
% read $fd
ATC
           ;# this is a newline \r\n
% seek $fd 1
% puts -nonewline $fd Y
% read $fd 1
C
% seek $fd 1
% read $fd 1
Y
% puts -nonewline $fd 7
% puts -nonewline $fd E
% seek $fd 0
% read $fd
AYC
7E

What seems to happen is if you "read" even one char from a fd, the
next puts will append to the end of the file, not at the current
position of the read. This happens for both buffered and unbuffered
input. The difference seems to be that with buffered writes, you can
do something after the [puts] which moves the input position "cursor"
to the end of the file.

tom jackson


On Mon, Nov 23, 2009 at 10:10 AM, Alexandre Ferrieux
<ale...@gm...> wrote:
> Hello,
>
> This is a heads-up on
> https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2901998&group_id=10894
>
> It turns out that for many years (possibly since day-one ?) we've had
> a very disturbing inconsistency between the buffered and unbuffered
> cases, in the effect of intertwined reads and writes on the file
> position (and I/O results).
>
> After concertation with Andreas, we believe it is important to get
> reliable community feedback about whether this bug can be just fixed
> (by sticking to the unbuffered semantics as suggested in the report),
> or whether a plane or power plant actually relies on that strange
> behavior.
>
> -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
>

Re: [TCLCORE] Inconsistent buffered I/O

[Martin L. <mar...@gm...>]

Hello Alex,

since I know tcl, the described consequence of the following code is
well known for me and no bug (in my eyes):

    set f [open foo r+]
    fconfigure $f -buffering full
    puts -nonewline $f Z
    puts [read $f] ----> ABC

Since not flushing the buffer is not written to the file and so reading
the file brings up the non-manipulated, original contents.

This is IMO obvious and not a bug. This problem is about physical
effects of programmatical settings.

Using buffering and "-nonewline", I always would force a flush on the
related channel!

I would advice to update the documentation related to "fconfigure" and
"-buffering" and "puts" and "-nonewline"!

Or do the following instead of the one above:

    set f [open foo r+]
    fconfigure $f -buffering full
    puts -nonewline $f Z
    seek $f [tell $f] start
    puts [read $f]
    ----> BC

Best regards,

Martin Lemburg

------------------------------------------------------------------------
Martin Lemburg, D-10551 Berlin
------------------------------------------------------------------------
"We are all individualists!" "No, I’m the only non-individualist!"
(Monty Pythons "Life of Brian")
------------------------------------------------------------------------


Alexandre Ferrieux wrote:
> Hello,
>
> This is a heads-up on
> https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2901998&group_id=10894
>
> It turns out that for many years (possibly since day-one ?) we've had
> a very disturbing inconsistency between the buffered and unbuffered
> cases, in the effect of intertwined reads and writes on the file
> position (and I/O results).
>
> After concertation with Andreas, we believe it is important to get
> reliable community feedback about whether this bug can be just fixed
> (by sticking to the unbuffered semantics as suggested in the report),
> or whether a plane or power plant actually relies on that strange
> behavior.
>
> -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
>   

[TCLCORE] Inconsistent buffered I/O

[Alexandre F. <ale...@gm...>]

Hello,

This is a heads-up on
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2901998&group_id=10894

It turns out that for many years (possibly since day-one ?) we've had
a very disturbing inconsistency between the buffered and unbuffered
cases, in the effect of intertwined reads and writes on the file
position (and I/O results).

After concertation with Andreas, we believe it is important to get
reliable community feedback about whether this bug can be just fixed
(by sticking to the unbuffered semantics as suggested in the report),
or whether a plane or power plant actually relies on that strange
behavior.

-Alex

[TCLCORE] 8.6 package compile fix

[Rene Z. <r.z...@fr...>]

Hi,

I had to patch the current HEAD to compile the additional packages
(see tracker # 2902333). Is it possible to fix this in the next release?

Thanks
rene