kicad-developers team mailing list archive
Mailing list archive
Re: Revision 3817 - netlist read and setvbuf
On 12/06/2012 02:27 PM, Marco Serantoni wrote:
> 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.
> 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]
Well then the function works?
(My remarks were conditioned on it not working.)
If setvbuf() works, and the OSX community wants this functionality, then try adding
That is, after the setvbuf() call, conditioned on OSX, but only in the constructor which
takes the fp.
This should seek the underlying file back to 0 and re-cache it.