On 06/dic/2012, at 20:58, Dick Hollenbeck wrote:
> On 12/06/2012 12:44 PM, Marco Serantoni wrote:
>> Sure Dick,
>> Seems that fseek returns 0L, as that is where the internal buffer points.
>> The setvbuff destroys the internal buffer and when is used the read call,
>> file operations begins where the buffer manager has leaved the real file
>> descriptor (6k ahead).
>>
>> Being the read already buffered, #ifdef it out has almost no impact on
>> performance.
>>
>> Hoping this makes now more sense,
>
> Yes more, but the picture is still not crystal clear.
>
> Does setvbuf() work under any circumstances on your OS? If it simply never
> works, then
>
> {
> be sure and make it conditional in *both* FILE_LINE_READER constructors.
>
> consider filing a bug report with your OS (glibc) maintainers.
>
> }
>
> The newer FILE_LINE_READER::FILE_LINE_READER( const wxString& ) will be
> getting more and
> more use with time.
>
Dick
I can't file any kind of bug report because reading a netlist, the call is
misused, in the other cases it worked.
As i've said in the first mail.
The code parsing the netlist does more or less this:
[Reads the header to identify the netlist type]
[Rewind the stream]
[Creates a FILE_LINE_READER]
----> calls setvbuf
[Proceed to parse the file]
And the documentation about the call explicitly says:
"This function should be called once the stream has been associated with an
open file, but before any input or output operation is performed with it."
" The setvbuf function may only be used after opening a stream and before any
other operations have been performed on it."
Ref:
http://linux.about.com/library/cmd/blcmdl3_setvbuf.htm
http://www.cplusplus.com/reference/cstdio/setvbuf/
And sadly is called after having identified the netlist kind (reads + rewind).
Marco
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
