Path: csiph.com!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: rbowman Newsgroups: comp.os.linux.misc Subject: Re: VMS Date: 22 Jul 2025 02:10:00 GMT Lines: 15 Message-ID: References: <20250625093213.00002ec2@gmail.com> <20250625094418.00007fd2@gmail.com> <105iv02$3cuhr$2@dont-email.me> <20250721091242.00007573@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net ZSZLYJFWoo5KjOIxNomGeg6E/yuhYKz9Icad9y84WENuHPS3+n Cancel-Lock: sha1:3k26FvhEHpwGUb9PVoKv0v2JRqA= sha256:k7bR8LH/1PGY8VpakpU1bKxzPstWUtB+suHQ7x90Lm8= User-Agent: Pan/0.162 (Pokrosvk) Xref: csiph.com comp.os.linux.misc:69838 On Mon, 21 Jul 2025 21:14:20 GMT, Charlie Gibbs wrote: > The top entry in my list of Famous Last Words is "Oh, don't worry about > that - it'll never happen." I had learned that "never" is usually about > six months. At the very least, if your program issues an appropriate > error message before aborting, you'll have a chance of finding and > fixing the deficiency. These days, I've gotten into using realloc() to > enlarge the area in question; if it works, I quietly continue, and if > not I put out a nasty error message and quit. I test the return of malloc(), calloc(), and realloc() and attempt to log the error. I have caught a calloc() error whem the nmemb parameter was negative due to bad math but I'm not that optimistic about logging being successful when memory allocation is failing. Still, I tried...