On 02/05/2011 17.20, Carmelo AMOROSO wrote:
> On 5/2/2011 4:14 PM, Thomas De Schampheleire wrote:
>> Hi Carmelo,
>>
>
> Hi Thomas,
>
>> I tested backtrace on a powerpc system (P4080 family) with
>> uClibc-0.9.31, and the test program mentioned in the backtrace man
>> page [1].
>>
>> The good news
When the INTERP program header contains a simple name with no slash, don't
crash trying to dereference a NULL pointer, but rather set _dl_ldsopath to ".".
---
ldso/ldso/ldso.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/ldso/ldso/ldso.c b/ldso/lds
When the INTERP program header contains a simple name with no slash, don't
crash trying to dereference a NULL pointer, but rather set _dl_ldsopath to ".".
---
ldso/ldso/ldso.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/ldso/ldso/ldso.c b/ldso/lds
On Wed, Dec 21, 2011 at 10:53:30AM +1000, Daniel Wainwright wrote:
> I don't believe that buf is guaranteed to be unchanged if there is an error
> in fgets, according to the man page the contents are "indeterminate". So it
> may write some characters to buf and not null-terminate it. So if you're
>
So if one of those fgetc calls fails (say the third) is the buffer
guaranteed to be unchanged? Or will the characters read so far be in the
buffer? The patch submitted assumes that the buffer is unchanged, but I do
not think there is a guarantee of this. Checking the return value seems to
be the sa
