[comp.windows.x] Xt unportability??!

Matthew.Diamond@MAPS.CS.CMU.EDU (07/17/90)

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

swick@ATHENA.MIT.EDU (Ralph R. Swick) (07/17/90)

    On the other hand, I can't believe that someone wouldn't have seen this
    already if this were actually a problem.

Correct.  This was a problem in R3.  In R4, it all hinges on whether
or not Xlib was built correctly.  See MALLOC_0_RETURNS_NULL in
lib/X/Xlibos.h and look at (e.g.) config/sgi.cf