[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer

2010-09-10 Thread don dot wakefield at gmail dot com


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

This can be accomplished by having filebuf::seekoff() recognize an off_type of
0, and a seekdir of cur, and special-case the code to call
_M_file.seekoff(0,cur) (not moving the file pointer, right?) and then adjusting
the resulting pos_type to reflect the true, earlier position held by gptr().

Am I missing something?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628



[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer

2010-09-10 Thread don dot wakefield at gmail dot com


--- 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 buffer and
pointed to by gptr().

As for the mechanics of width*off, I confess that locale issues leave me
completely befuddled, so I won't try to address that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628



[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer

2010-09-10 Thread don dot wakefield at gmail dot com


--- 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 returns, and always call fseek(..., width * off, ...) as
> the standard mandates. Then dealing with off == 0 becomes simple.

I'm not sure I understand what you are saying. My concern is that calls to
filebuf::seekoff(0,ios::cur) should not invalidate the buffer just to return a
correct answer to "where am I?". Whether this is an accident of history or not,
I've seen this usage enshrined in code as a respected idiom.

Does your text above specify this?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628



[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer

2010-09-10 Thread don dot wakefield at gmail dot com


--- 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 as if fseek(off * width) were called, not just 
> fseek(0)
> in the special case you care about.

Okay, I understand better now. My apologies, and thanks for your comments on
this issue.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628



[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer

2010-09-17 Thread don dot wakefield at gmail dot com


--- 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 to butt in here. I don't expect any sympathy, but the only reason
my company never complained about the performance issue with
filebuf::seekoff(0,cur) is that we only just started using compilers which
included that change. Our company can't be the only one beholden to
conservative customers, so I won't be surprised if you get other questions
similar to ours, years after the change went in.

In any case, I appreciate all the effort you have put into this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628