[PATCH] [pls apply!] Bug #54281 (crash): Konsole crashes on output of certain characters

Karl Vogel karl.vogel at seagha.com
Wed Feb 19 15:26:19 GMT 2003

On 19 Feb 2003, you wrote in kde.kde-core-devel:

> On Wed, Feb 19, 2003 at 12:28:56PM +0100, Karl Vogel wrote:
>> Isn't it wise to also check for a NULL pointer?! I know this is an
>> illegal combination (ie. buflen>0 and buffer=NULL), but shouldn't
>> core functions guard against improper use, instead of dumping core?!
> no. very often return values are not checked (or the function does not
> return anything, in the first place). thus avoiding a segfault at the
> library level is equivalent to making the function silently fail.

Well in this particular case, the function doesn't need to return an
error.  It can simply return telling the caller that it has done it's
job. (same like asking to print a string of len 0). 

> one more thing to note is, that a null-pointer is only a special case
> of an invalid pointer. it's sort of unfair to check only this one. :)

Can't disagree with that! :-)

> libc functions don't check params, either.

Are you sure? Try printf("%s", null_ptr)... I'm sure it won't bomb out.

> and last but not least, it's a matter of performance (provided a
> function is performance-critical, of course).
> you can put asserts all over the place, if you're paranoid ... (they
> won't be compiled when NDEBUG is #defined).

Well if there had been an assert (or a conditional kdDebug), then the
problem would have been caught, instead of going in a recursive loop
eating all swap space until bombing out with a seg fault and possibly
bringing down some other apps because of the out-of-memory condition. 
(which btw happened in this particular case) 

Although... a good sysadmin probably has some ulimit's set which avoid
this worst case scenario. 

> anyway, it's much better to write application code that does not pass
> bad pointers in the first place. :)

True.. but coding bug's is so much more fun (and easy) !

Anyway I know this is a personal preference.. and I'm surely not
advocating this... I was merely wondering.. 

More information about the kde-core-devel mailing list