Woof!

On Wed, 10 Sep 2008 13:48:19 -0400, Martin Steinmann  
<[EMAIL PROTECTED]> wrote:

> If I recall correctly (Woof help me out), there are still a lot of
> printf statements that somehow need to be changed because of a
> difference in glibc. Would be very interesting to get this back on
> track.

Among the major issues with Solaris is that Sun's vsprintf (and all the  
*printfs that end up using it) will core dump if a NULL string is printed  
with the %s format.  As Linux (well glibc) will instead print "(nil)" in  
that case, much of the code in sipX relied on the glibc behavior,  
especially in debug code where the whole point was to see if the string  
was null or not!

There was a systematic attempt to replace all printed strings with a macro  
that checked for null, but it became untennable.  I looked into changing  
the Sun libc code, at it wouldn't have been hard, but the Sun guys were  
quite adament that the core dump behavior was a *good* thing, and would  
not have accepted the change, and I wasn't about to delve into shipping a  
private version of libc just to support sipX.  I even looked into a way of  
trying to dynamically preload a custom version of just the low level  
function that did the formatting ahead of libc's, but that didn't work due  
to the way the linker pre-resolved functions in the same library--the  
existing low level function continued to be called by the *printf code.   
It would thus require replacing ALL the *printf functions to get the  
desired behavior, and that turned out to be too large a task.

Sun has a version of the libc library that will NOT core dump on accesses  
to address 0 (aka NULL), but it that prevents ALL SEGV's due to ALL NULL  
pointers, not just strings.  This goes too far in the other direction!

At the time this was going on, there was an ongoing project to port glibc  
(the one Linux uses) to Solaris, which would make the whole thing easier.   
I do not know if any of that work is ready for use now or not.  Sun's take  
now seems to be "run Linux in an xVM container" instead of porting.

As a Solaris enthusiast, I would love to see sipX running natively.  I  
don't think replacing all %s arguments with a macro is the right answer  
however, as new code will certainly forget to do this, and it swells the  
code size and considerably.  I'd love to find a "fix it in one place" type  
of solution, but it hasn't happend yet.

--Woof!
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev

Reply via email to