Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!mipos3!omepd!inteloa!smithrd
From: smithrd@inteloa.intel.com (Randy D. Smith)
Newsgroups: comp.windows.x
Subject: Re: XtAppCreateShell. What am I doing wrong?
Message-ID: <4515@omepd.UUCP>
Date: 2 Jun 89 22:33:42 GMT
References: <6979@bunny.GTE.COM> <8905261610.AA17950@expo.lcs.mit.edu>
Sender: news@omepd.UUCP
Reply-To: smithrd@inteloa.UUCP (Randy D. Smith)
Organization: BiiN (tm), Hillsboro, OR
Lines: 30

In article <8905261610.AA17950@expo.lcs.mit.edu> kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) writes:
>
>Donna's reply covered the problem I think, but there is another thing
>or two in here just waiting to bite you...
>
>                                                Chris D. Peterson
>                                                MIT X Consortium

Speaking of being bitten by the "Toolkit: cannot malloc" bug...

I notice that Xlib has code surrounded by #ifdefs on the preprocessor
variable "MALLOC_0_RETURNS_NULL".  Very nice for SVIDish systems.  I
also noticed (via the aforementioned error message) that the toolkit
was not quite so, how shall we put it, portable (sigh, I know the
word is a bit overworked, but it was the best I could do with such
little notice).

It would be really nice (pretty please?) if the toolkit (and anything
else which becomes a part of "the standard") were at least as portable
as Xlib.  Perhaps for R4?

I have no idea whether this could be the problem the original poster
was facing, but if so...just go into Xt/Alloc.c and make sure all the
allocation routines check for requests for 0 bytes, and pass on to
the libc equivalents requests for 1 (or more) bytes instead.
--
					Randy D. Smith
			 BiiN (tm),  An Information Systems Company
			     ...uunet!tektronix!inteloa!smithrd
					(503) 696-4660