Re: [PATCH] Fix wrong EOF compare

2013-01-10 Thread Minchan Kim
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

Re: [PATCH] Fix wrong EOF compare

2013-01-10 Thread Minchan Kim
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

Re: [PATCH] Fix wrong EOF compare

2013-01-10 Thread Randy Dunlap
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

Re: [PATCH] Fix wrong EOF compare

2013-01-10 Thread Michal Nazarewicz
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

[PATCH] Fix wrong EOF compare

2013-01-09 Thread Minchan Kim
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