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>