Hi Randy,
On Thu, Jan 10, 2013 at 08:12:24AM -0800, Randy Dunlap wrote:
> On 01/10/13 07:26, Michal Nazarewicz wrote:
> > On Thu, Jan 10 2013, Minchan Kim wrote:
> >> getc returns "int" so EOF could be -1 but storing getc's return
> >> value to char directly makes the vaule to 255 so below condit
Hello Michal,
On Thu, Jan 10, 2013 at 04:26:58PM +0100, Michal Nazarewicz wrote:
> On Thu, Jan 10 2013, Minchan Kim wrote:
> > getc returns "int" so EOF could be -1 but storing getc's return
> > value to char directly makes the vaule to 255 so below condition
> > is always false.
>
> Technically
On 01/10/13 07:26, Michal Nazarewicz wrote:
> On Thu, Jan 10 2013, Minchan Kim wrote:
>> getc returns "int" so EOF could be -1 but storing getc's return
>> value to char directly makes the vaule to 255 so below condition
>> is always false.
>
> Technically, this is implementation defined and I be
On Thu, Jan 10 2013, Minchan Kim wrote:
> getc returns "int" so EOF could be -1 but storing getc's return
> value to char directly makes the vaule to 255 so below condition
> is always false.
Technically, this is implementation defined and I believe on many
systems char is signed thus the loop wi
getc returns "int" so EOF could be -1 but storing getc's return
value to char directly makes the vaule to 255 so below condition
is always false.
It happens in my ARM system so loop is not ended, then segfaulted.
This patch fixes it.
*curr = getc(fin); // *curr = 255
5 matches
Mail list logo