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
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 wher
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
> descript
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 i
On 12/06/2012 12:03 PM, Marco Serantoni wrote:
> On 27/nov/2012, at 15:29, Dick Hollenbeck wrote:
>
> Dick,
> Sadly it doesn't work, i'll just revert to the old code and add an #ifndef to
> exclude the setvbuff call.
ftell() is returning 0?
> Cleaner and simpler :)
Nonsense.
___
On 27/nov/2012, at 15:29, Dick Hollenbeck wrote:
Dick,
Sadly it doesn't work, i'll just revert to the old code and add an #ifndef to
exclude the setvbuff call.
Cleaner and simpler :)
Marco
>
>> I know Dick, is "dirty" for this reason, but knowing that the problem is
>> more systemic
>> i've
> I know Dick, is "dirty" for this reason, but knowing that the problem is more
> systemic
> i've preferred have a leak than a non working suite.
>
> I will wait :)
>
> --
> Marco
Maybe it will work now. If you can try it for MAC now, that would be
appreciated.
if( doOwn && ftell( aFile
On 11/26/2012 03:05 AM, Marco Serantoni wrote:
> I wish to discuss about my patch #3817, that comes to me from some
> signalations of
> problems in cvpcb and i've applied that is a probably a dirt workaround for a
> more deep
> problem that i wish to describe.
>
> The code parsing the netlist doe
I wish to discuss about my patch #3817, that comes to me from some
signalations of problems in cvpcb and i've applied that is a probably a
dirt workaround for a more deep problem that i wish to describe.
The code parsing the netlist does more or less this:
[Reads the header to identify the netlis
9 matches
Mail list logo
