Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!MAPS.CS.CMU.EDU!Matthew.Diamond
From: Matthew.Diamond@MAPS.CS.CMU.EDU
Newsgroups: comp.windows.x
Subject: Xt unportability??!
Message-ID: <9007162115.AA05514@ATHENA.MIT.EDU>
Date: 16 Jul 90 21:15:27 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 25


I've noticed this problem with both R3 and R4.
For some reason, some toolkit routines malloc something
of size 0, AND EXPECT TO GET A POINTER BACK!  Surely this is a hazardous
practice?  I have a program that runs o.k., but when I link it with
a stringent implementation of malloc (that returns NULL when 0  bytes are
allocated), the toolkit prints "Error -- cannot perform malloc" and the
program stops.

In particular, the following routines seem to allocate 0 bytes regularly:
  XtOverrideTranslations (calls stuff which calls MergeTables, which calls
                          XtCalloc)
  XawTextReplace (calls stuff which calls XawAsciiSourceChanged which calls
                  XtMalloc)

I believe that the ANSI standard allows or requires mallocs to return NULL
when asked to allocate 0 bytes.  This would seem to pose portability
questions for libXt/libXaw, and in fact I am having difficulty on our Sun
with programs that work fine on our microVaxen.

On the other hand, I can't believe that someone wouldn't have seen this
already if this were actually a problem.  So is there an explanation?
Are my programs so wrong that THEY cause the toolkit to malloc 0 bytes?
Matthew Diamond
matt@maps.cs.cmu.edu