hubble@cae780.TEK.COM (Larry Hubble) (05/03/87)
The library routine getenv() has a bug in it. If the environment variable you
are requesting does not happen to be the first one in the environment table,
getenv() goes into an infinite loop.
The fix is very simple. The first executable line is:
while ((p = *v) != NULL) {
It should be:
while ((p = *v++) != NULL) {
Getenv() then seems to work properly. I believe there is also a bug in the
library routine strncpy -- it doesn't null terminate the string if the string
to copy is really longer that "n" characters. I have not verified or fixed
this yet, but will post it when I get a chance to cure it.
---------------------------------------------------------------------------
Larry R. Hubble Tektronix/CAE Systems Division
(408) 748-4782 5302 Betsy Ross Dr.
{hplabs,tektronix}hubble@cae780 Santa Clara, CA 95054dcm@mimir.dmt.oz (Dennis Mills) (05/05/87)
in article <3860@cae780.TEK.COM>, hubble@cae780.TEK.COM (Larry Hubble) says: > > I believe there is also a bug in the > library routine strncpy -- it doesn't null terminate the string if the string > to copy is really longer that "n" characters. This is the correct documented behaviour of 'strncpy'. Dennis -- Dennis Mills, PHONE: +61 (03)487-9258 CSIRO Division of Manufacturing Technology, ACSNET: dcm@mimir.dmt.oz Cnr Albert and Raglan Streets, Preston Victoria, Australia, 3072. CSNET: dcm@mimir.dmt.oz ARPA: dcm%mimir.dmt.oz@seismo.arpa UUCP: {decvax,pesnta,vax135}!mulga!mimir.dmt!dcm {seismo,ukc,mcvax}!munnari!mimir.dmt!dcm
go@orstcs.UUCP (05/05/87)
hubble@cae780.UUCP writes: > I believe there is also a bug in the > library routine strncpy -- it doesn't null terminate the string if the string > to copy is really longer that "n" characters. I have not verified or fixed > this yet, but will post it when I get a chance to cure it. Alas, according to my copy of SystemV Interface Definition, strncpy: "... copies exactly n characters, truncating s2 or adding null characters to s1 if necessary. The reult will *not* [my emphasis added] be null- terminated if the length of s2 is n or more." Since Minix is based upon Version 7, the adherence to this "standard" is expected. Gary Oliver ...!hplabs!hp-pcd!orstcs!go
rpw3@amdcad.AMD.COM (Rob Warnock) (05/06/87)
In article <3860@cae780.TEK.COM> hubble@cae780.UUCP (Larry Hubble) writes: >Getenv() then seems to work properly. I believe there is also a bug in the >library routine strncpy -- it doesn't null terminate the string if the string >to copy is really longer that "n" characters. I have not verified or fixed >this yet, but will post it when I get a chance to cure it. This is *NOT* a bug, so don't try to "fix" it -- you will break many working programs! Read any System-V or POSIX man page for "strncpy": "...The result is not null-terminated if the source string contained 'n' or more characters..." This allows "strncpy" to be used to "insert" pieces of one string into another. (Sorry if it's not to your taste, but that's the way it was defined a long time ago...) Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun,attmail}!redwood!rpw3 ATTmail: !rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403
allbery@ncoast.UUCP (05/10/87)
As quoted from <868@mimir.dmt.oz> by dcm@mimir.dmt.oz (Dennis Mills): +--------------- | in article <3860@cae780.TEK.COM>, hubble@cae780.TEK.COM (Larry Hubble) says: | > | > I believe there is also a bug in the | > library routine strncpy -- it doesn't null terminate the string if the string | > to copy is really longer that "n" characters. | | This is the correct documented behaviour of 'strncpy'. +--------------- I can see where he would get confised, though; System V documents it as *always* null-terminating the string. No idea how V7 does it. System III and Xenix don't say one way or the other. ++Brando -- Copyright (C) 1987 Brandon S. Allbery -- you can redistribute only if your recipients can. Brandon S. Allbery {decvax,cbatt,cbosgd}!cwruecmp!ncoast!allbery Tridelta Industries {ames,mit-eddie,talcott}!necntc!ncoast!allbery 7350 Corporate Blvd. necntc!ncoast!allbery@harvard.HARVARD.EDU Mentor, OH 44060 +01 216 255 1080 (also eddie.MIT.EDU)
lm@cottage.WISC.EDU (Larry McVoy) (05/12/87)
(Brandon Allbery) claims: >| > I believe there is also a bug in the >| > library routine strncpy -- it doesn't null terminate the string >>> if the string >| > to copy is really longer that "n" characters. > >I can see where he would get confised, though; System V documents it as >*always* null-terminating the string. No idea how V7 does it. System III >and Xenix don't say one way or the other. > >++Brando I quote from the System V Interface Definition "The function strncpy copies exactly n characters... The result will not be null terminated if the length of s2 is n or more." Brandon, please don't spread ignorance. I don't think you realize how many people are going to assume that you are right and then find out you were wrong when their code bombs. Check your facts or clause them. Larry McVoy lm@cottage.wisc.edu or uwvax!mcvoy
cmf@cisunx.UUCP (Carl M. Fongheiser) (05/13/87)
According to my V7 manual:
"Strncpy copies exactly n characters, truncating or null-padding s2; the
target may not be null-terminated if the length of s2 is n or more."
^^^ ^^^ ^^ ^^^^^^^^^^^^^^^
In other words, V7 won't guarantee which way it works, and if you want
to run on a V7 machine, you better not depend on any particular behavior.
Carl Fongheiser
University of Pittsburgh
Computing & Information Systems
...!pitt!cisunx!cmf
cmf@pittvms.BITNET