http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
--- Comment #57 from paolo at gcc dot gnu dot org 2010-09-22 19:41 ---
Subject: Bug 45628
Author: paolo
Date: Wed Sep 22 19:40:43 2010
New Revision: 164529
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164529
Log:
2010-09-22 David Krauss
PR libstdc++/45628
*
--- Comment #56 from paolo dot carlini at oracle dot com 2010-09-20 21:32
---
David himself is on it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #55 from paolo dot carlini at oracle dot com 2010-09-17 21:59
---
> I'm
> getting the impression that you guys got tired after a long redesign process
> and oversimplified the state machine.
Not me. Wh
--- Comment #54 from potswa at mac dot com 2010-09-17 21:51 ---
Well, for my part, a few years ago I played around with fstream a little,
noticed the tellg requirement was weird (I only discovered it by throwing the
kitchen sink at the problem), wasn't able to interpret the standard well
--- Comment #53 from paolo dot carlini at oracle dot com 2010-09-17 21:22
---
What can I say, I don't know anybody still using GCCs dating back to 2003. In
any case, my point wasn't really about seek(0, cur) and its optimization, etc,
my point was about the general design, where you use
--- Comment #52 from don dot wakefield at gmail dot com 2010-09-17 21:11
---
(In reply to comment #51)
> ...As a matter of fact, many users found it also quite easy to
> use, because - in case wasn't clear already from my previous comments -
> **nobody ever** complained.
I just have t
--- Comment #51 from paolo dot carlini at oracle dot com 2010-09-17 20:07
---
If you can allow writes after reads and viceversa *also* without seeks in the
middle, and without affecting performance and without adding data members,
that's fine. Let's see what you come up with it. By the
--- Comment #50 from potswa at mac dot com 2010-09-17 19:56 ---
(In reply to comment #49)
> with seeks
> switching between reading and writing via state variables, then it's fine, in
> principle.
Why require seeks? The whole point is that they are extraneous. I'm not
proposing to break
--- Comment #49 from paolo dot carlini at oracle dot com 2010-09-17 19:50
---
It was **a ton** of work and discussions in public and among the maintainers,
in private. Anyway, if you have something which doesn't touch basic_streambuf,
keeps the get and put areas of basic_filebuf complet
--- Comment #48 from potswa at mac dot com 2010-09-17 19:45 ---
I'm having trouble finding the discussion that precedes the June 24, 2003
redesign, but I'll add "unified" to the search terms.
Actually, last week I started some changes with the aim of fixing the bug, not
changing the phi
--- Comment #47 from paolo dot carlini at oracle dot com 2010-09-17 19:38
---
To further clarify: what you have in mind isn't something which can belong to a
casual PR, is a major redesign of basic_filebuf, according to a different basic
philosophy, which at the time, Nathan called unif
--- Comment #46 from paolo dot carlini at oracle dot com 2010-09-17 19:26
---
Ok, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #45 from potswa at mac dot com 2010-09-17 19:21 ---
Already did copyright assignment :vP
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #44 from paolo dot carlini at oracle dot com 2010-09-17 19:17
---
By the way, if, for the future, you mean to contribute in these areas, if you
are really interested in these topics, I would recommend starting immediately
the Copyright assignment paperwork http://gcc.gnu.org
--- Comment #43 from potswa at mac dot com 2010-09-17 19:11 ---
Thanks for the pointer, I'll read that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #42 from paolo dot carlini at oracle dot com 2010-09-17 19:10
---
Before any other bug or analysis, I would recommend going back to the ton of
discussions in 2002 / 2003 when the design of basic_filebuf has been changed to
use _M_reading and _M_writing, **on purpose**. Didn'
--- Comment #41 from potswa at mac dot com 2010-09-17 19:04 ---
Well, I'm happy if you'd like to merge the diffs. My code was written with the
intent of optimizing the output case, too, but I guess it's not too inefficient
or awkward from the perspective of input only.
I just filed a bu
--- Comment #40 from paolo dot carlini at oracle dot com 2010-09-17 18:53
---
In general, our users know that seeking allows to switch from reading to
writing, and viceversa (when the stream has been appropriately opened of
course). This assumption remained true for years and years. Thu
--- Comment #39 from potswa at mac dot com 2010-09-17 18:04 ---
Oops, no, I'm on the 4.5.2 series, not mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #38 from potswa at mac dot com 2010-09-17 17:51 ---
Created an attachment (id=21822)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21822&action=view)
Works with codecvt. Tested Tested x86_64-darwin, mainline
Ah, now I see the trick:
if (__off == 0 && !(_M_mode
--- Comment #37 from paolo dot carlini at oracle dot com 2010-09-17 12:42
---
Created an attachment (id=21819)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21819&action=view)
Tested x86_64-linux, mainline
This is a carefully tested patch (tested in mainline, per the normal polic
--- Comment #36 from paolo dot carlini at oracle dot com 2010-09-11 10:03
---
I'm traveling. Note, I don't understand how you are addressing my concerns,
thus whatever results you get from the testsuite, make sure we are not
regressing on the situation I outlined, thus write a new testc
--- Comment #35 from potswa at mac dot com 2010-09-11 09:43 ---
(In reply to comment #34)
> Run the full testsuite, and you will see.
Lol, you're still looking at this too? I *just* got those pesky four testcases
done. I wasn't manually putting the codecvt state into the fpos in the spe
--- Comment #34 from paolo dot carlini at oracle dot com 2010-09-11 09:21
---
Run the full testsuite, and you will see. In general, if you simply do fseek(0,
cur) and then start writing, when eventually you have to flush you need the
actual logical position in the file - the last fseek(
--- Comment #33 from potswa at mac dot com 2010-09-11 04:56 ---
Note, I am not attempting to tell after write with a nontrivial codecvt
installed. Maybe the issue of Comment #5 is only in the general case?
I suppose it leaves UTF-8 files still a bit slow, but I still think that's
pretty
--- Comment #32 from potswa at mac dot com 2010-09-11 04:49 ---
(In reply to comment #31)
> I'm afraid that the situation I outlined in Comment #5 is just the simple one.
> The real problem with the new scheme - which tries to deal specially with (0,
> cur) by not moving the file pointer
--- Comment #31 from paolo dot carlini at oracle dot com 2010-09-11 04:27
---
I'm afraid that the situation I outlined in Comment #5 is just the simple one.
The real problem with the new scheme - which tries to deal specially with (0,
cur) by not moving the file pointer - is when *write
--- Comment #30 from potswa at mac dot com 2010-09-10 20:33 ---
(In reply to comment #29)
> And, please, if you want to help, manage to run the testsuite, we have got
> some
> pretty nasty testcases ;)
I'll see if I can compile the latest⦠guess it's more useless to have an old
tree
--- Comment #29 from paolo dot carlini at oracle dot com 2010-09-10 19:51
---
And, please, if you want to help, manage to run the testsuite, we have got some
pretty nasty testcases ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #28 from paolo dot carlini at oracle dot com 2010-09-10 19:34
---
PS: you are right that we have to check that _M_seek succeeds before adding
back __computed_off.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #27 from paolo dot carlini at oracle dot com 2010-09-10 19:31
---
Note that certainly we don't want to use C++0x stuff here. Also, one thing at a
time of course, thus if we have been missing some error checking, etc, it's for
another time.
--
http://gcc.gnu.org/bugzilla
--- Comment #26 from potswa at mac dot com 2010-09-10 19:30 ---
(In reply to comment #25)
> Created an attachment (id=21769)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21769&action=view) [edit]
> alternative approach. untested
>
> I hope this compiles ;v) . But it seems to "col
--- Comment #25 from potswa at mac dot com 2010-09-10 19:26 ---
Created an attachment (id=21769)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21769&action=view)
alternative approach. untested
I hope this compiles ;v) . But it seems to "color within the lines."
Why does your patc
--- Comment #24 from paolo dot carlini at oracle dot com 2010-09-10 19:01
---
Created an attachment (id=21768)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21768&action=view)
Draft
This is what I have so far, unfortunately I cannot work only on this today.
Anyway, it passes test
--- Comment #23 from potswa at mac dot com 2010-09-10 18:53 ---
(In reply to comment #22)
> Good. Then I have a draft almost ready ;)
I have a very straightforward, low-impact solution, but I haven't tested it.
(My tree is pretty out of date.) Would you like to try it, if you're having
--- Comment #22 from paolo dot carlini at oracle dot com 2010-09-10 17:42
---
Good. Then I have a draft almost ready ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #21 from potswa at mac dot com 2010-09-10 17:40 ---
(In reply to comment #18)
> I'm almost ready for the patch, please be patient ;) If look at the standard,
> it says that the last step of seekoff is *always* as if calling fseek(..., off
> * width, ...). If look at the curre
--- Comment #20 from potswa at mac dot com 2010-09-10 17:35 ---
(In reply to comment #17)
> The task is to call fseek(0,cur), and then subtract the number of bytes in the
> put area plus the "external characters," right?
Er, I don't mean "bytes in the put area" exactly, but you know wh
--- Comment #19 from paolo dot carlini at oracle dot com 2010-09-10 17:30
---
Of course here I'm always under the assumption width > 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #18 from paolo dot carlini at oracle dot com 2010-09-10 17:29
---
I'm almost ready for the patch, please be patient ;) If look at the standard,
it says that the last step of seekoff is *always* as if calling fseek(..., off
* width, ...). If look at the current code, we have
--- Comment #17 from potswa at mac dot com 2010-09-10 17:25 ---
(In reply to comment #16)
> Actually, however, I don't think we can really always call fseek(off * width)
> as the Standard want us to do. In a sense I'm happy because the change is
> gonna
> be less invasive, on the other
--- Comment #16 from paolo dot carlini at oracle dot com 2010-09-10 17:11
---
Actually, however, I don't think we can really always call fseek(off * width)
as the Standard want us to do. In a sense I'm happy because the change is gonna
be less invasive, on the other hand I'm a bit puzzl
--- Comment #15 from potswa at mac dot com 2010-09-10 16:15 ---
(In reply to comment #14)
> (The result doesn't depend on
> the pointers, it comes from fseek.)
I re-read Comment 5 and understand it this time ;v) . Well, any solution should
fix both tellg and tellp, since the pointers a
--- Comment #14 from potswa at mac dot com 2010-09-10 15:59 ---
(In reply to comment #13)
> Good, I think we are close to a fix, I'm already testing something. So, do we
> have a symmetric issue with the put area or not? I'm not sure.
I believe so. tellg and tellp are both handled by se
--- Comment #13 from paolo dot carlini at oracle dot com 2010-09-10 15:45
---
Good, I think we are close to a fix, I'm already testing something. So, do we
have a symmetric issue with the put area or not? I'm not sure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #12 from don dot wakefield at gmail dot com 2010-09-10 15:24
---
(In reply to comment #11)
> Sure. What I meant - contrary to wait you said, I think - is that an elegant
> and complete solution to this issue involves changing much more generally our
> code to *always* behave
--- Comment #11 from paolo dot carlini at oracle dot com 2010-09-10 15:19
---
Sure. What I meant - contrary to wait you said, I think - is that an elegant
and complete solution to this issue involves changing much more generally our
code to *always* behave as if fseek(off * width) were
--- Comment #10 from don dot wakefield at gmail dot com 2010-09-10 15:15
---
(In reply to comment #9)
> Ok. I don't think we should change the code to deal such specially with off ==
> 0, if we are going to change it we should decouple the return value from what
> the underlying seek re
--- Comment #9 from paolo dot carlini at oracle dot com 2010-09-10 15:00
---
Ok. I don't think we should change the code to deal such specially with off ==
0, if we are going to change it we should decouple the return value from what
the underlying seek returns, and always call fseek(..
--- Comment #8 from don dot wakefield at gmail dot com 2010-09-10 14:54
---
Paolo, yes, _M_file.seekoff(0,cur) would return the current physical file
position, and then filebuf::seekoff would adjust the returned pos_type to
reflect the position within the *logical* file, framed by the b
--- Comment #7 from paolo dot carlini at oracle dot com 2010-09-10 14:39
---
Then, seekoff would also return a position beyond the buffer, right? Or you
want it to return 1 anyway? Actually, I think the standard want us to use width
* off for the underlying fseek anyway, not only for of
--- Comment #6 from don dot wakefield at gmail dot com 2010-09-10 14:06
---
Re: comment 5 - what is needed is for filebuf::seekoff(0,ios::cur) to:
1) *not* invalidate the buffer
2) *not* move the file pointer
since all that special case asks is "where am I in the 'logical' file?"
--- Comment #5 from paolo dot carlini at oracle dot com 2010-09-10 12:36
---
To clarify: when we start reading in a buffered mode, the first underflow reads
the buffer and leaves the physical file at the first char beyond the buffer. If
we do afterwards a seek to the current reading pos
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-10 12:20
---
Does not work: when we reach the end of the buffer and we access again the file
to refill it, we start reading from the wrong position, the position we seeked
to.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-10 12:09
---
I *think* it can work to minimally change what we have now to not reset the get
area buffers when (0, ios::cur) and we have been reading: as far as I can see,
if in that specific case we get back to reading aga
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-10 10:55
---
_M_terminate_output, correctly, does nothing in this case, cannot be the
problem, and there is nothing wrong wrt the standard mandated behavior. The
"problem" is that in our implementation, similarly to traditi
--- Comment #1 from potswa at mac dot com 2010-09-10 07:09 ---
Created an attachment (id=21762)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21762&action=view)
simple testcase
This little program attempts to read three characters from its own source,
checking the position each ti
59 matches
Mail list logo
