Xref: utzoo comp.bugs.4bsd:1748 comp.lang.c:35906 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!udel!haven!mimsy!mojo!eng.umd.edu!stripes From: stripes@eng.umd.edu (Joshua Osborne) Newsgroups: comp.bugs.4bsd,comp.lang.c Subject: Re: Complexity of reallocating storage Message-ID: <1991Feb7.191150.27058@eng.umd.edu> Date: 7 Feb 91 19:11:50 GMT References: <21548@yunexus.YorkU.CA> <5883:Feb102:05:4991@kramden.acf.nyu.edu> <1991Feb4.195805.16710@ora.com> Sender: news@eng.umd.edu (C-News) Reply-To: stripes@eng.umd.edu (Joshua Osborne) Followup-To: user Organization: College of Engineering, Maryversity of Uniland, College Park Lines: 29 In article <1991Feb4.195805.16710@ora.com>, ambar@ora.com (Jean Marie Diaz) writes: [...] > Since "anything that can go wrong will go wrong", it is a programmer's > responsibility to deal with Murphy as gracefully as possible. Dumping > core is never graceful. It isn't normally graceful, but in bizzare failure cases I *want* a core dump so I can see what went on to get me to the "can't happen" default in a switch (I want to know more then just the improper switch control variable). That's why my code has a ton of asserts, or for more end-user style code a assert-like call "make_core(int expr, char *reason)" which prints some standard message, the reason string, dumps some stuff in a file, dumps a core the tells the user to save the core & the error file, and who to mail or phone... (the core file isn't kept with that name, too many autodeleters nail core files...) Of corse more normal error conditions get more normal messages! I have redirected follow-ups to me because I don't know what newsgroup generic programing flames/tips should go to. Hopefully I did this right, I couldn't find it in the manpages, so I'll have to rely on my faulty memmory... -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Multitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "CNN is the only nuclear capable news network..." - lbruck@eng.umd.edu (Lewis Bruck)