Actually, I removed the check for a NULL pointer since str should never be NULL. str is assigned by a call to syncpipe_getstr() which will, in practice, never return a NULL pointer. The only way to get there in the old code is to have the other side of the syncpipe write an invalid string length ( <= 0).
However, it looks as though I left out the modification to syncpipe_getstr() which calls error() when an invalid length is passed and guarantees a NULL is *never* returned... (See attached patch). Regards, John Franks----- Original Message ----- From: "Josef Wolf" <[EMAIL PROTECTED]>
To: <[email protected]> Sent: Wednesday, February 08, 2006 10:04 AM Subject: Re: Release of amanda-2.5.0b2
On Wed, Feb 08, 2006 at 08:48:15AM -0800, Paddy Sreenivasan wrote:> But I am not sure whether I correctly understand the proposal. Is the > following the proposed fix? Yes. Please add test results to the bug tracker.I have arranged for the test tonight. I'll report tomorrow. Thanks! BTW: Checkin 1.111->1.112 of server-src/taper.c looks a little bit strange to me. Especially two hunks I've appended to the end of this mail. When ``str ? str : "(null)"ยดยด results in "(null)" the str was the NULL pointer. Will the called function newvstralloc() be able to cope with the passed NULL? @@ -1428,7 +1428,7 @@ "[sec ", walltime_str(runtime), " kb ", kb_str, " kps ", kps_str, - " ", str ? str : "(null)", + " ", str, "]", NULL); @@ -1469,7 +1467,7 @@"[sec ", walltime_str(curdump_rt)," kb ", kb_str, " kps ", kps_str, - " ", str ? str : "(null)", + " ", str, "]", NULL); putresult(DONE, "%s %s %d %s\n", handle, label,
syncpipe_putstr.patch
Description: Binary data
