Date: Wed, 17 Oct 2001 14:56:44 +1000 From: Zero Sum <count@shalimar.net.au> To: Greg Black <gjb@gbch.net> Cc: cjclark@alum.mit.edu, "Crist J. Clark" <cristjc@earthlink.net>, Heath Nielson <heath@cs.byu.edu>, Warner Losh <imp@harmony.village.org>, David Marker <marker_d@yahoo.com>, freebsd-stable@FreeBSD.ORG Subject: Re: setenv() cores with NULL value [was Re: Gdm proplem on 4.4] Message-ID: <200110170456.f9H4ujA20210@shalimar.net.au> In-Reply-To: <nospam-1003236582.62800@mx1.gbch.net> References: <200110160353.f9G3rO728525@harmony.village.org> <200110161002.f9GA2CA08544@shalimar.net.au> <nospam-1003236582.62800@mx1.gbch.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 16 October 2001 22:49, Greg Black wrote: > Zero Sum wrote: > > | On Tuesday 16 October 2001 18:38, Crist J. Clark wrote: > | > | > > > | > > setenv("TEST1", "", 1); > | > > setenv("TEST2", NULL, 1); > | > > | > A huge difference. In the first case, the second argument is a > | > pointer aimed at a string which contains the bytes, '\0'. In the > | > second case, we have a null pointer. Null pointers point at nothing. > | > | I had that out with a compiler manufacturer long, long ago. At that > | time it was a requirement for a 'correct' C compiler to regard a null > | pointer and a pointer to a null string as sematically equivalent. > | > | Has this changed without me noticing? > > This is an absurd claim -- under K&R C and ISO C there is no > equivalence between these two things. > It might be an absurd claim, but if I recall aright, it is a factual one. Let me explain.... We are going back to arounf 1982 here. That's a long time ago and my memory may not be clear. I can point you to documents that no longer exist and a few hints I have found on the web. At that time I worked for a small company devloping an AI language. A language designed for writing AI shells. We didn't have a lot of money and equipment was not powerfull. We used NCR Towers, AT&T 3B series and an AT9800. We used a type of framing technique, but the slots in a frame were dynamic. A slot could be either full, empty or non-existent. Nonexistent having the same value as empty. This was a pretty good product for its time and eventually flogged it to Japan. But because of the efficiency constraints, and the early days, some of the code may not have been the best. We were constrained. We ported that product to many systems without a problem. Yet it consistently assumed that the value returned by the pointer value 0 would be 0. One particular compiler returned something like "^AT". As far as I am concerned that was a flaw both then and now. That was the manufacturer I was talking about. At that time there was usually a "C" page in the man system and on that page it noted that a pointer to a null string and a null pointer were semantically equivalent. I saw this in both on and off-line copies of manuals. Searching for information this to back me up, THe only thing I could find was a perl manual page which mentions the expectation in C of equality between a pointer of value 0 and a pointer to an empty string is not true in perl. [PDF] 162.105.203.94/download/books/PerlPG.pdf PERL(1) Perl Programmers ... to the null string ("") or 0 ... not) is semantically equivalent to a ... as in C. That is ... not the empty string and matches ... So, you see, I am not the only one with that expectation. Now, I am not going to make *any* claim. I'm a dodering old fart with a decaying memory. But what I have detailed above is strong in my memory. My apologies for mentioning it in the first place. -- Zero Sum<count@shalimar.net.au> Vescere bracis meis But remember, please, the Law by which we live, We are not built to comprehend a lie. We can neither live nor pity, nor forgive, If you make a slip in handling us you die! --The Secret of the Machines-- Rudyard Kipling To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110170456.f9H4ujA20210>