[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: libc string routines don't check for NULL pointers
From:       Julian Assange <proff () suburbia ! net>
Date:       1996-10-22 15:02:52
[Download RAW message or body]

> 
> In message
> <Pine.BSF.3.91.961022180422.548J-100000@panda.hilink.com.au> "Daniel
> O'Callaghan" writes: 
> : The string comparison (and other) routines in libc don't check for null 
> : pointers being passed.  This results in SEGVs if one or both of the 
> : string pointers being passed is NULL.  I can see a religious debate here, 
> : but I'm going to raise the issue:  Should str*cmp() handle NULL arguments.
> 
> str*cmp and friends should be hard asses about this and should give
> the programer a nice core file when this happens, subject to local
> security constraints.  NULL pointer checking can slow down these
> routines, but I've never seen numbers to back up speed differences.
> 
> Just my humble opinion from about 10 years of doing this stick.
> Others may disagree.

No need to do this, just make sure the vm system never maps page 0.

-- 
"Of all tyrannies a tyranny sincerely  exercised for the good of its victims  
 may be the most  oppressive.  It may be better to live under  robber barons  
 than  under  omnipotent  moral busybodies,  The robber baron's  cruelty may  
 sometimes sleep,  his cupidity may at some point be satiated; but those who  
 torment us for own good  will torment us  without end,  for they do so with 
 the approval of their own conscience."    -   C.S. Lewis, _God in the Dock_ 
+---------------------+--------------------+----------------------------------+
|Julian Assange RSO   | PO Box 2031 BARKER | Secret Analytic Guy Union        |
|proff@suburbia.net   | VIC 3122 AUSTRALIA | finger for PGP key hash ID =     |
|proff@gnu.ai.mit.edu | FAX +61-3-98199066 | C7F81C2AA32D7D4E4D360A2ED2098E0D |
+---------------------+--------------------+----------------------------------+

[prev in list] [next in list] [prev in thread] [next in thread]