Date: Fri, 6 Oct 1995 11:07:07 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: Andrew White <awhite@dca.net> Cc: bugs@freebsd.org Subject: Re: bug with gcc 2.6.2? Message-ID: <199510061007.AA21760@Sysiphos> In-Reply-To: Andrew White <awhite@dca.net> "Re: bug with gcc 2.6.2?" (Oct 5, 21:56)
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 5, 21:56, Andrew White wrote: } Subject: Re: bug with gcc 2.6.2? } Thanks for your response. Of course you are right, a null string and a } null pointer are not the same. } } However, it would be nice if the str* functions would not SIGSEV when } called with a null pointer, but rather failed more nicely. Well, they fail rather nicely, in fact :) As a library function, they don't have the slightest idea which line of your code code called them. The SIGSEV lets you look at the code with the tool designed to not only show the line of failure, but also help you diagnose the occurances that lead to this situation (i.e. the stack backtrace and access to calling functions local variables help understand **why** it was possible for a NULL to make its way into the library function ...) Since there is no obvious way to correctly deal with NULL pointers (treating them as empty strings is possible, but not obviously right), you can't continue program execution at that place anyway. So making all information available to your friendly debugger of choice seems a rather nice way of failure to me :) STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html <se@ZPR.Uni-Koeln.DE>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510061007.AA21760>