Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!news.sprintlink.net!howland.reston.ans.net!gatech!news.mathworks.com!news.kei.com!nntp.et.byu.edu!news.byu.edu!hamblin.math.byu.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@cs.weber.edu>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Major strcmp bug under BSD 2.0?
Date: 2 Jun 1995 22:34:48 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 73
Message-ID: <3qo3m8$aq7@park.uvsc.edu>
References: <3qfn52$188j@troy.la.locus.com>
NNTP-Posting-Host: hecate.artisoft.com
sassan@locus.com (Sassan Behzadi) wrote:
]
] Am I imagining things or is there a bug in BSD 2.0's strcmp() function?
] If either of the string parameters is NULL the program core dumps.
] Isn't this a major bug? (Making the OS pretty much useless). Is there
] a simple fix for this ?
This is a result of the intentional unmapping of page 0 to catch
NULL pointer dereferences with a kernel "page not present" error.
SunOS and Solaris do the same thing.
SVR4.2 has a switchable mechanism (at least in UnixWare) for the
same thing.
Consider the result of continuing to process with a bogus pointer
value; by the time you arrive at a fatal error, an undetected NULL
pointers origin could have been lost, making it difficult or
impossible to track down the real bug.
Yes, I know several pieces of software use the str*() functions
on NULL pointers; the most famous of these is probably 'elm',
with the 'xdt' X desktop program second, and your particular
problem coming in a poor third.
Much of the NetWare for UNIX/NetWare for UnixWare work was done on
Sun machines because of the UnixWare intentiannally mapping a page
at 0 on first reference (the switching mechanism was not present
until very recently, and it interferes with the mapping process,
allowing a fault to occur instead).
Consider it a "programmer friendly" feature of the OS.
HP/UX works, as do several older UNIX derivatives because the page
at 0 is mapped to contain 0's at the page 0 location.
Many UNIX implementations will give indeterminite results, depending
on whether or not the compare string is less than/equal to/greater
than the crt0.o startup code (up to the first 0 byte) because the
code loads in at 0 relative.
A few implementations explicitly check for NULL pointers to str*()
routines, slowing them down considerably to benefit bad programming
practice.
My personal opinion is that bad programming practice should be
detected and corrected, rather than being worked around at a general
penalty to performance to programs that have been written correctly.
If you find this morally repugnant, you are free to add compares
to your string functions in the libc (for which sources have been
provided). If you do so, you will only need to relink (*not*
recompile) statically linked programs.
Luckily, of the programs that are distributes with FreeBSD, only
those in the /sbin and /usr/sbin directories (that's what the "s"
means) are statically linked, and you will not need to recompile
these, since they all use proper programming practice and don't
attempt to pass NULL pointers into routines that dereference the
pointers passed to them.
For further information, look at the mailing list and news archives
on freefall and minnie, where the topic was discussed at length
when the page 0 unmapping went in. Or type 'man strcmp', since it
is also discussed briefly there.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.