[Zlib-devel] zlib 1.2.2.3 available for testing

[Greg Roelofs]

> On May 30, 2005, at 9:12 AM, Nelson H. F. Beebe wrote:
> > That single failure was DEC Alpha OSF/1 4.0 compiled with native cc: 
> > the zlib test died with a "Memory fault"
> ...
> > zlib version 1.2.2.3 = 0x1223, compile flags = 0x30000a9
> ...
> > signal Segmentation fault at >*[strlen, 0x3ff801a2ce0]  ldq_u   r1, 
> > 0(r16)
> > (dbx) where
> >>  0 strlen(0x0, 0x0, 0x0, 0x0, 0x0) [0x3ff801a2ce0]
> >    1 _doprnt(0x0, 0x0, 0x0, 0x0, 0x0) [0x3ff800ddcc8]
> >    2 sprintf(0x11fffd640, 0x140002308, 0x40002310, 0x6c6c6568, 0x7fff) 
> > [0x3ff800da08c]

> The compile flags tell me that sprintf() returns a value, which should 
> be the length of the resulting string.  (Those compile flags are 
> useful!)  A strlen() being called within sprintf(), possilbly to 
> determine that  length, never finds a terminating zero and goes 
> charging off into la la land.  Sounds like a library bug to me.

I don't think this is likely to be relevant, but Ultrix (precursor to
OSF/1) was one of the few systems still returning a char pointer from
sprintf() as of the mid-1990s.  (SunOS was another.)  I'd be surprised
if that were still the case in OSF/1, but one never knows.  (Either way,
it's hard to see how that would affect an internally called strlen()
unless you overran your buffer.)

Greg