View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0038351 | FPC | FCL | public | 2021-01-13 14:34 | 2021-01-21 23:05 |
Reporter | Andrey Zubarev | Assigned To | Florian | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Fixed in Version | 3.3.1 | ||||
Summary | 0038351: TBufferedFileStream.Seek(0,soBeginning) not working | ||||
Description | function TBufferedFileStream.Seek(const Offset: Int64; Origin: TSeekOrigin): Int64; var lNewOffset: int64; begin Case Origin of soEnd: begin lNewOffset:=FCacheStreamSize+Offset; end; soBeginning: begin lNewOffset:=0+Offset; end; soCurrent: begin lNewOffset:=FCacheStreamPosition+Offset; end; end; if lNewOffset>0 then begin FCacheStreamPosition:=lNewOffset; Result:=lNewOffset; end else begin // This is compatible with FPC stream // as it returns the negative value :-? // but in fact does not move the read pointer. Result:=-1; end; end; Need "if lNewOffset>=0 then begin", offset can be zero | ||||
Tags | No tags attached. | ||||
Fixed in Revision | 48282 | ||||
FPCOldBugId | |||||
FPCTarget | - | ||||
Attached Files |
|
|
Confirm. |
|
project1.lpr (449 bytes)
{$MODE OBJFPC} {$APPTYPE CONSOLE} uses Classes, BufStream; procedure Test; var F: TStream; begin F := TBufferedFileStream.Create('project1.lpr', fmOpenRead); //F := TFileStream.Create('project1.lpr', fmOpenRead); try Writeln(F.Position); Writeln(F.Seek(0, soBeginning)); // TFileStream = 0, TBufferedFileStream = -1 Writeln(F.Position); finally F.Free; end; end; begin Test; Readln; end. |
|
looks like that class was part of someone's pet project and did only exactly what they needed by the looks of it.. Use A TMemoryStream instead and maybe this BufStream unit can be evaluated ? Removal sounds good to me because I don't see much value in it the way it is now.. |
|
no, TBufferedFileStream is very necessary. It is not always to read the entire file in memory, it can be huge |
|
Well then live with it... I don't think you'll get much traction on changes because then the current behavior of SEEK would be changed and thus most likely crash software that is using it in its present state. This is what I gathered from looking at the code, And yes, I know that sounds stupid/. |
|
And it is also needed for Delphi compatibility :) |
|
And you cannot argue with 'would crash existing software' as this is clearly a bug and nobody should write code which depends on undocumented things and expect it'll always work. Btw the Seek() calls FileSeek() and there it's documented that 'On error, -1 is returned. ' which is definitely wrong in the case above. So a bugfix is needed. |
|
Thanks! |
Date Modified | Username | Field | Change |
---|---|---|---|
2021-01-13 14:34 | Andrey Zubarev | New Issue | |
2021-01-15 18:15 | Serge Anvarov | Note Added: 0128360 | |
2021-01-15 18:16 | Serge Anvarov | Note Added: 0128361 | |
2021-01-15 18:16 | Serge Anvarov | File Added: project1.lpr | |
2021-01-16 17:51 | jamie philbrook | Note Added: 0128371 | |
2021-01-16 18:53 | Andrey Zubarev | Note Added: 0128373 | |
2021-01-16 20:46 | jamie philbrook | Note Added: 0128375 | |
2021-01-16 20:57 | ravi dion | Note Added: 0128377 | |
2021-01-16 21:07 | ravi dion | Note Added: 0128378 | |
2021-01-21 22:08 | Florian | Assigned To | => Florian |
2021-01-21 22:08 | Florian | Status | new => resolved |
2021-01-21 22:08 | Florian | Resolution | open => fixed |
2021-01-21 22:08 | Florian | Fixed in Version | => 3.3.1 |
2021-01-21 22:08 | Florian | Fixed in Revision | => 48282 |
2021-01-21 22:08 | Florian | FPCTarget | => - |
2021-01-21 23:05 | Andrey Zubarev | Status | resolved => closed |
2021-01-21 23:05 | Andrey Zubarev | Note Added: 0128475 |