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.
>>
> 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]
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
setvbuf()
#ifdef OSX
rewind(fp);
endif
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.
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
