crouch@axion.bt.co.uk (Chris Rouch) (08/31/90)
Whenever XtMalloc fails to allocate memory it calls an error message handler which calls exit, thus terminating the application. What is the reason for doing it this way, rather than letting the calling procedure decide what action to take? More importantly is there any way round this? Chris ------------------------------------------------------------------------ ------ Chris Rouch crouch@axion.bt.co.uk RT3131, BTRL, Martlesham Heath, Ipswich, England. +44 473 646093 Only when we dream are we free. The rest of the time we need wages.
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (08/31/90)
What is the
reason for doing it this way, rather than letting the calling procedure
decide what action to take?
Xt was designed without seriously thinking about the problem of running out
of memory. It permitted the toolkit to be designed and implemented in a
shorter timeframe, while maximizing the number of problems downstream. :-)
(Do I need a vacation, or what? :-)
More importantly is there any way round this?
Good luck...asente@adobe.com (Paul Asente) (09/01/90)
In article <1990Aug31.105145.22656@axion.bt.co.uk> CRouch@axion.bt.co.uk writes: >Whenever XtMalloc fails to allocate memory it calls an error message >handler which calls exit, thus terminating the application. What is the >reason for doing it this way, rather than letting the calling procedure >decide what action to take? How often have you written if ((ptr = malloc(...)) == NULL) { error msg } ??? More importantly, how often have you *not* written it when you should? Most applications don't cope with malloc failing, so doing the test for them is a substantial convenience and leads to more correct programs. >More importantly is there any way round this? Sure, use malloc instead. The spec says: -These functions are completely compatible with their standard C language -runtime counterparts so you can mix and match malloc and XtMalloc as you wish. -paul asente New address! asente@adobe.com ...decwrl!adobe!asente