Draft standards OK for new compiler and libc?
James Buchanan
of C and the official ISO published standards.
For example, would the draft standard be good enough to go on when writing a
new ISO Standard C compiler and C library? Could the drafts be used as a
reference when writing C programs without any problems caused by
differences between the draft and the standard?
Thank you,
--
James Buchanan
Keith Thompson
For writing programs, a draft is probably good enough. Assuming a
compiler that conforms to the actual standard, if the program depends
on anything in the draft that differs from the standard, you're likely
to get a diagnostic from the compiler. (Consider this an invitation
to post counterexamples.)
If you're going to try to implement an ISO standard compliant compiler
and library, though, it would be insane not to spend $18 for a PDF
copy of the actual standard.
There is a post-C99 draft, n1124, but you should still have a copy of
the actual standard.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
James Buchanan
> If you're going to try to implement an ISO standard compliant compiler
> and library, though, it would be insane not to spend $18 for a PDF
> copy of the actual standard.
$18, hmm. Not too bad, but still pricey (in my currency). I was looking at
the IEEE standards online store and the download cost of POSIX was more
than $200, perhaps $260 or something. Now that is insane. I just assumed
all standards were outrageously expensive! I don't think there's anything
of interest in POSIX though if implementing an ISO C compliant compiler and
library.
--
James Buchanan
Niklas Matthies
> James Buchanan <reply.an...@nospam.thanks> writes:
>> I was wondering whether there is much difference between the draft standards
>> of C and the official ISO published standards.
>>
>> For example, would the draft standard be good enough to go on when writing a
>> new ISO Standard C compiler and C library? Could the drafts be used as a
>> reference when writing C programs without any problems caused by
>> differences between the draft and the standard?
>
> For writing programs, a draft is probably good enough. Assuming a
> compiler that conforms to the actual standard, if the program depends
> on anything in the draft that differs from the standard, you're likely
> to get a diagnostic from the compiler. (Consider this an invitation
> to post counterexamples.)
One counter-example: The possibility that an integer conversion to a
signed integer type that cannot represent the value to be converted
raises an implementation-defined signal instead of resulting in an
implementation-defined value was added after the final public draft.
-- Niklas Matthies
Dag-Erling Smørgrav
> $18, hmm. Not too bad, but still pricey (in my currency). I was looking at
> the IEEE standards online store and the download cost of POSIX was more
> than $200, perhaps $260 or something.
The Open Group makes POSIX (aka SUSv3) available for free online.
DES
--
Dag-Erling Smørgrav - d...@des.no
Keith Thompson
That's a good example, and it's certainly something you're better off
knowing than not knowing.
Interestingly, that knowledge isn't strictly necessary if you're
implementing a C compiler; it just wouldn't take advantage of the new
permission to raise a signal.
Chris Hills
01.iinet.net.au>, James Buchanan <reply.an...@nospam.thanks> writes
>I was wondering whether there is much difference between the draft standards
>of C and the official ISO published standards.
>
>For example, would the draft standard be good enough to go on when writing a
>new ISO Standard C compiler and C library?
Hardly. The fact that you are even considering it shows you are not
serious. You need the current standard + the TC's as well. Otherwise you
may just as well go and base it on K&R 2nd edition.
> Could the drafts be used as a
>reference when writing C programs without any problems caused by
>differences between the draft and the standard?
Possibly.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills
>
>> If you're going to try to implement an ISO standard compliant compiler
>> and library, though, it would be insane not to spend $18 for a PDF
>> copy of the actual standard.
>
>$18, hmm. Not too bad, but still pricey (in my currency).
What currency? FOr a standard that is quite inexpensive.
> I was looking at
>the IEEE standards online store and the download cost of POSIX was more
>than $200, perhaps $260 or something. Now that is insane.
Why? Others cost far more than that.
> I just assumed
>all standards were outrageously expensive! I don't think there's anything
>of interest in POSIX though if implementing an ISO C compliant compiler and
>library.
It depends if you need to be POSIX complient. What target is your
compiler for?
Antoine Leca
> You need the current standard + the TC's as well.
In fact, a serious implementer should have at least skimmed the Rationale
and all the DRs. Also, of course. There are a lot of hints for the
implementers there.
Antoine
Chris Hills
<ro...@localhost.invalid> writes
I agree totally.
Whilst I don't expect many programmer to have the standards, and most
don't, because they have to work to the compiler and it's documents
primarily.
The implimentors have to know the standard to know where they are
deviating from the standard, and why, so they can document this in the
compiler manuals.
those who know me have no need of my name
>Keith Thompson wrote:
>> If you're going to try to implement an ISO standard compliant compiler
>> and library, though, it would be insane not to spend $18 for a PDF
>> copy of the actual standard.
>
>$18, hmm. Not too bad, but still pricey (in my currency).
iso's price is much higher. ansi's is the exception, for this particular
standard in pdf format at least.
--
a signature
Francis Glassborow
my name <not-a-rea...@usa.net> writes
And the version published in book form (The C Standard, 0-470-84573-2)
is also much cheaper than buying direct from ISO. The cover cost is $65
but you can get it somewhat cheaper.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Mabden
news:HMSe9jEE...@robinton.demon.co.uk...
> In article <m1vezjz...@usa.net>, those who know me have no need
of
> my name <not-a-rea...@usa.net> writes
> >in comp.std.c i read:
> >>Keith Thompson wrote:
> >
> >>> If you're going to try to implement an ISO standard compliant
compiler
> >>> and library, though, it would be insane not to spend $18 for a PDF
> >>> copy of the actual standard.
> >>
> >>$18, hmm. Not too bad, but still pricey (in my currency).
> >
> >iso's price is much higher. ansi's is the exception, for this
particular
> >standard in pdf format at least.
>
> And the version published in book form (The C Standard, 0-470-84573-2)
> is also much cheaper than buying direct from ISO. The cover cost is
$65
> but you can get it somewhat cheaper.
And what does a Latin Dictionary go for?
As if people are really going to spend money on Dead Languages...
I have my K&R from when that was C. So far, there has been one
difference - they moved NULL. Otherwise, It's been a good 15 years. And
you know what, I never really cared about where NULL was, so much. Oy!
--
Mabden
Richard Tobin
About 10 pounds for a good one, but you might consider second-hand.
-- Richard
Mabden
news:djqf2h$26sq$1...@pc-news.cogsci.ed.ac.uk...
No, my first hand weighs about 10 pounds. Depends on where you cut it
off...
--
Mabden
Douglas A. Gwyn
> For example, would the draft standard be good enough to go on when writing a
> new ISO Standard C compiler and C library?
No. Changes were made up to the last minute.
Douglas A. Gwyn
> $18, hmm. Not too bad, but still pricey (in my currency).
If you're really intending to write a compiler and library
then you will be spending a vastly larger amount in terms
of your own time.
Douglas A. Gwyn
> I have my K&R from when that was C. So far, there has been one
> difference - they moved NULL.
Please don't give advice when you don't know what you're
talking about.
Mabden
news:43664C43...@null.net...
Sorry, but I don't take orders well. Telling me what to do is unlikely
to provide you with the satisfaction you desire. Your request, however
was polite, and I will take it into consideration, for that reason.
You did neglect to provide information on why the post you quoted was
objectionable. Did I say something that you didn't quote that was
objectionable? The above seems reasonable to myself, as it is my
opinion.
Are you confused about the "moved NULL" comment, because there have been
many threads about this issue, this year. I will not reference them
here, as they attract too much attention. You may email me about the
specifics, or talk to others about it.
--
Mabden
kuy...@wizard.net
> "Douglas A. Gwyn" <DAG...@null.net> wrote in message
> news:43664C43...@null.net...
> > Mabden wrote:
> > > I have my K&R from when that was C. So far, there has been one
> > > difference - they moved NULL.
> >
> > Please don't give advice when you don't know what you're
> > talking about.
> You did neglect to provide information on why the post you quoted was
> objectionable. Did I say something that you didn't quote that was
> objectionable? The above seems reasonable to myself, as it is my
> opinion.
Objectionable isn't quite the right word; it implies that you were
somehow impolite. He said that you don't know what you're talking
about. That means that the problem he was complaining about isn't
impoliteness, it's ignorance. If your statement was a deliberate troll,
rather than a display of ignorance, then it was certainly very
objectionable; but I'll give you benefit of the doubt and assume that
it wasn't a troll. You said explicitly and incorrectly that moving NULL
was the only change that had been made. That statement is so far from
the truth that it's hard for me to imagine the thought processes that
lead to writing it down (unless it was indeed intended as a troll).
> Are you confused about the "moved NULL" comment, because there have been
> many threads about this issue, this year.
Using Google, the only thread I can find in comp.std.c during the past
year which has a message containing both "moved" and "NULL" is this
thread. Could you recommend search criteria for retrieving the threads
you're referring to?
Mabden
news:1130812241.1...@g14g2000cwa.googlegroups.com...
> Mabden wrote:
> > "Douglas A. Gwyn" <DAG...@null.net> wrote in message
> > news:43664C43...@null.net...
> > > Mabden wrote:
> > > > I have my K&R from when that was C. So far, there has been one
> > > > difference - they moved NULL.
> > >
> > > Please don't give advice when you don't know what you're
> > > talking about.
> ...
> > You did neglect to provide information on why the post you quoted
was
> > objectionable. Did I say something that you didn't quote that was
> > objectionable? The above seems reasonable to myself, as it is my
> > opinion.
>
> Objectionable isn't quite the right word; it implies that you were
> somehow impolite. He said that you don't know what you're talking
> about. That means that the problem he was complaining about isn't
> impoliteness, it's ignorance. If your statement was a deliberate
troll,
I am not a deliberate troll. I have sometimes camped under a bridge,
tho, to keep the rain off. ;-)
I don't mind stepping on a few sacred toes to get to a point I'm not
clear on, and I certainly push past people who want to mislead or
misunderstand my questions. Unfortunately, for my reputation, I do so
when I am confused and not being misled nor misunderstood, as well.
Group apology, hugs all 'round.
> rather than a display of ignorance, then it was certainly very
> objectionable; but I'll give you benefit of the doubt and assume that
> it wasn't a troll. You said explicitly and incorrectly that moving
NULL
> was the only change that had been made. That statement is so far from
> the truth that it's hard for me to imagine the thought processes that
> lead to writing it down (unless it was indeed intended as a troll).
Huh? So your code from 1989 doesn't compile anymore? Mine does.
But it turns out that NULL == (void *)0, not location 0 in memory. Page
102 says that "C guarantees that zero in never a valid address for
data". Apparently, that no longer holds, so was explained to me over
MANY posts. I hope we don't get in to that again, but you asked. I
believe, I believe, stop the hate mail, I believe.
I can't think of anything else in the K&R2 that has rocked my world like
that one. Please don't spout minutia about printf %o being unsigned int
instead of int or something. Also, don't talk about a C version that has
no existing compiler. If it isn't in MSC 8.0 then I don't care; so you
are just frothing at the mouth in the village square to people who
already know what you mean, hear what you say, and agree with you.
Remember, this was JUST my opinion, and I _could_ be mistaken (also
don't post how I _am_ mistaken - too obvious). Also realize that I am
_already_ hated by many, so you don't even need to tell THEM that I am
wrong; most of those you'd like to read your post saw my name and
clicked "message read" if they saw it at all - Google "killfile" and
"plonk".
> > Are you confused about the "moved NULL" comment, because there have
been
> > many threads about this issue, this year.
>
> Using Google, the only thread I can find in comp.std.c during the past
> year which has a message containing both "moved" and "NULL" is this
> thread. Could you recommend search criteria for retrieving the threads
> you're referring to?
You MUST be new. Please don't post replies to me anymore. I reverse
plonk you!
--
Mabden
kuy...@wizard.net
> <kuy...@wizard.net> wrote in message
> news:1130812241.1...@g14g2000cwa.googlegroups.com...
> > it wasn't a troll. You said explicitly and incorrectly that moving
> NULL
> > was the only change that had been made. That statement is so far from
> > the truth that it's hard for me to imagine the thought processes that
> > lead to writing it down (unless it was indeed intended as a troll).
>
> Huh? So your code from 1989 doesn't compile anymore? Mine does.
I've written C code for 26 years now, but I don't have much, if any,
code from 1989 that I'm still using. If it did, I would most certainly
have re-written it so that it would no longer compile with a K&R
compiler.
You didn't say "I can take my old code and still compile it with the
latest compiler, except for changing the way I work with null
pointers." You said there were no other changes. There were a lots of
other changes between K&R C and C90, and smaller changes in C94 and
C99. If you're making the point that you didn't have to learn any of
those changes; that you can still write K&R C and get it to compile,
that's technically correct (but it's not what you actually said).
However, if you are still writing K&R C, you're making very poor use of
the language. At the very least, you should be making extensive use of
function prototypes, which didn't exist in K&R C.
> But it turns out that NULL == (void *)0, not location 0 in memory. Page
> 102 says that "C guarantees that zero in never a valid address for
> data". Apparently, that no longer holds, so was explained to me over
> MANY posts. I hope we don't get in to that again, but you asked. I
> believe, I believe, stop the hate mail, I believe.
I had no idea what you were referring to. I wouldn't describe that as
"moving NULL". It's a significant rearrangement of concepts, but I
can't think of anything which could be described as having moved. Note,
in particular, a couple of points:
NULL is NOT required to be (void*)0. It is still allowed to be 0.
However, NULL is allowed to be (void*)0, so code which assumes that it
isn't is non-portable.
There is a much broader concept, that of a null pointer constant; NULL
is guranteed to be a null pointer constant, but there are many other
expressions that you can write which are also null pointer constants.
"0" is one of them.
When a null pointer constant is converted to a pointer type, the result
is a null pointer. Null pointers are guaranteed to not compare equal to
any valid pointer to an object.
Even if NULL is 0, that doesn't mean that when you convert it to a
pointer type and store it in a pointer object, that all of the bits of
the object are 0. Even if it does contain all bits 0, it doesn't
necessarily describe a memory address of 0 (and vice versa). However,
it's still permitted for NULL to be 0, for null pointers to have all
bits set to 0, and to represent a memory location of 0.
> I can't think of anything else in the K&R2 that has rocked my world like
> that one. Please don't spout minutia about printf %o being unsigned int
> instead of int or something. Also, don't talk about a C version that has
> no existing compiler.
Ah, that explains a lot! You're talking about K&R2, not K&R itself.
K&R2 was NEVER the definition of C. K&R WAS the definition of C, prior
to the ANSI/ISO standard, which is why I assumed that you were
referring to it. K&R2 was merely a description of what was defined by
the standard; any discrepancy between the two would be resolved in
favor of the standard, not K&R2.
C90 very definitely has a conforming compiler, and I believe that there
do exist fully conforming compilers for C99; if not, they're at least
very close. I haven't started delivering C99 code, but I'm looking
forward to the day when such compilers are sufficiently common that our
clients will finally allow me to do so.
> > Using Google, the only thread I can find in comp.std.c during the past
> > year which has a message containing both "moved" and "NULL" is this
> > thread. Could you recommend search criteria for retrieving the threads
> > you're referring to?
>
> You MUST be new.
That depends upon your definition of "new", and in what sense you mean
that. I'm pretty "old" in most of the relevant senses: I've been
posting on usenet newsgroups since the early 1990s, and on this
newsgroup since 1996.
If you mean that I must be new because I didn't recognise the issue you
were describing, I'd like to point out that all of the messages on this
thread have been posted exclusivly on comp.std.c. The issue you
described so poorly has been mostly discussed on comp.lang.c. The
signal-to-noise ratio on comp.lang.c is too high for my tastes, so I
generally don't monitor it. I post to it from time to time, but almost
exclusively in response to messages that are cross-posted to
comp.std.c.
Douglas A. Gwyn
> ... You said explicitly and incorrectly that moving NULL
> was the only change that had been made. That statement is so far from
> the truth that it's hard for me to imagine the thought processes that
> lead to writing it down (unless it was indeed intended as a troll).
Not only that, but <stdio.h> still defines NULL.
Douglas A. Gwyn
Sort of true and sort of false. K&R2 was certainly intended to
update K&R(1) to reflect the then-new "ANSI" C standard, but
not to usurp the standard's role in defining the C language.
K&R(1) Appendix A was one of the main guides to C before there
was an official standard, but actual implementations of C did
not accurately follow the spec in that Appendix, and there were
several generally accepted changes to the language and library
beyond what K&R described. The AT&T C Reference Manual was
considered by many to be more authoritative. If K&R had been a
satisfactory definition of C, then there would have been no
need to develop the official standard.
Jordan Abel
> Huh? So your code from 1989 doesn't compile anymore? Mine does.
And your code from 1978 compiles? From what i've read [I was four
years old in 1989] a lot changed in the "landscape" of C
implementations between the publication of K&R and the final version
of C89.
Jordan Abel
> Ah, that explains a lot! You're talking about K&R2, not K&R
> itself. K&R2 was NEVER the definition of C. K&R WAS the
> definition of C, prior to the ANSI/ISO standard, which is why I
> assumed that you were referring to it. K&R2 was merely a
> description of what was defined
> by the standard;
By the yet-to-be-finalized standard: K&R2's (c) date is 1988.
That would probably be the reason for discrepancies between the two.
kuy...@wizard.net
...
> Sort of true and sort of false. K&R2 was certainly intended to
> update K&R(1) to reflect the then-new "ANSI" C standard, but
> not to usurp the standard's role in defining the C language.
> K&R(1) Appendix A was one of the main guides to C before there
> was an official standard, but actual implementations of C did
> not accurately follow the spec in that Appendix, and there were
> several generally accepted changes to the language and library
> beyond what K&R described. The AT&T C Reference Manual was
> considered by many to be more authoritative. If K&R had been a
> satisfactory definition of C, then there would have been no
> need to develop the official standard.
I've never seen the AT&T C Reference Manual, so before the ANSI
standard came out I tended to think of K&R as the ultimate authority on
the C language. I wasn't particularly aware of it's deficiencies for
that purpose at that time, though I instantly recognised how C89 was an
improvement, when it came out.
I was mainly trying to interpret Mabden's cryptic reference to "when
that [K&R] was C". IMO, the time period best described by that phrase
is the time between the publication of K&R and the publication of K&R2,
prior to the approval of the 1989 ANSI standard. Apparantly Mabden
intended to describe a somewhat later time period.
Dennis Ritchie
"Jordan Abel" <jma...@purdue.edu> wrote in message news:slrndmfb4g....@random.yi.org...> > ....K&R2 was NEVER the definition of C. K&R WAS the
> > definition of C, prior to the ANSI/ISO standard, which is why I
> > assumed that you were referring to it. K&R2 was merely a
> > description of what was defined
> > by the standard;
>
> By the yet-to-be-finalized standard: K&R2's (c) date is 1988.
>
> That would probably be the reason for discrepancies between the two.
There are few discrepancies between K&R2 and the 1989 ANSI standard
because the changes between the 1988 draft standard and the final
one are small. At one point I knew of two, of which I remember
only one: the range of the "seconds" field of the time structure.
There were of course errors (which we continue to record in its
errata) and also things not covered (e.g. wide characters) and so
the introduction is at pains to point out that the Standard rules.
And of course the book talks only of C89.
Dennis
Mabden
> On 2005-11-01, Mabden <mabden@sbc_global.net> wrote:
> > Huh? So your code from 1989 doesn't compile anymore? Mine does.
>
> years old in 1989] a lot changed in the "landscape" of C
> implementations between the publication of K&R and the final version
> of C89.
I was speaking of K&R2, (c) 1988. My early code, that I still have, is
dated from 5/24/1988. My favorite program from that time was LHXshell.c
(5/10/1990); it allows multiple player files, a top ten list, and lets
the player continue after dying on the game LHX Attack Chopper (which
was annoying because if you died your game thus far was erased, and it
kept no top ten of its own). I just compiled it in VC++ 6.0 with no
warnings or errors. I had hacked the save file to show what medals you
had won, your level, etc. out of the binary save file.
--
Mabden
Mabden
news:dk935e$j...@netnews.net.lucent.com...
But they moved NULL. Do you agree with and / or like the fact that "C
guarantees that zero is never a valid address for data" has gone away? I
have always considered this a "fact", but it has been explained to me
that it is not. I am VERY interested in you personal opinion about this
issue, Dennis.
--
Mabden
Jordan Abel
What zero? The integer value 0 converted to any pointer type still
carries such a guarantee. The result of allocating a struct
containing pointers with calloc() never has, nor have floating point
values initialized in such a way been guaranteed to be 0.
kuy...@wizard.net
...
> But it turns out that NULL == (void *)0, not location 0 in memory. Page
> 102 says that "C guarantees that zero in never a valid address for
> data". Apparently, that no longer holds, so was explained to me over
> MANY posts. I hope we don't get in to that again, but you asked. I
> believe, I believe, stop the hate mail, I believe.
>
> I can't think of anything else in the K&R2 that has rocked my world like
> that one.
How did that rock your world? What effect did it have on your code? I
don't know of any way within the C language for portably identifying
which address a pointer points at, nor any portable way of creating a
pointer which points a specific address. What code did you write that
had to be re-written to work correctly with this change?
> > > Are you confused about the "moved NULL" comment, because there have
been
> > > many threads about this issue, this year.
I tried reviewing your messages in comp.lang.c over the past year which
contained the word "NULL", and but I didn't locate any which specified
the actual problem that you ran into.
Jordan Abel
> Mabden wrote:
> ...
>> But it turns out that NULL == (void *)0, not location 0 in
>> memory. Page 102 says that "C guarantees that zero in never a
>> valid address for data". Apparently, that no longer holds, so was
>> explained to me over MANY posts. I hope we don't get in to that
>> again, but you asked. I believe, I believe, stop the hate mail, I
>> believe.
>>
>> I can't think of anything else in the K&R2 that has rocked my
>> world like that one.
>
> How did that rock your world? What effect did it have on your
> code? I don't know of any way within the C language for portably
> identifying which address a pointer points at, nor any portable
> way of creating a pointer which points a specific address. What
> code did you write that had to be re-written to work correctly
> with this change?
Well, the standard says that pointers can be converted to at least
one integer type, which is implementation-specified, and back. One
could consider the value of an integer object thus obtained to be
"the address", and a pointer converted from such an integer type to
be a pointer which points at that address. By that token, it would
be unwise for an implementation to convert a pointer to "memory
address 0" to zero, since converting that back to a pointer would
probably yield a null pointer. [though only _constant_ zero
expressions are actually guaranteed to convert from 0 to a null ptr]
In context, the use of "zero" in K&R2 on those pages appears to
refer to an integer constant expression 0.
Wojtek Lerch
> On 2005-11-02, Mabden <mabden@sbc_global.net> wrote:
>>But they moved NULL. Do you agree with and / or like the fact that
>>"C guarantees that zero is never a valid address for data" has
>>gone away? I have always considered this a "fact", but it has been
>>explained to me that it is not.
>
> What zero? The integer value 0 converted to any pointer type still
> carries such a guarantee.
Only when it's a constant expression.
Jordan Abel
yeah, that's what i meant
Skarmander
<snip>
> Well, the standard says that pointers can be converted to at least
> one integer type, which is implementation-specified, and back. One
> could consider the value of an integer object thus obtained to be
> "the address", and a pointer converted from such an integer type to
> be a pointer which points at that address. By that token, it would
> be unwise for an implementation to convert a pointer to "memory
> address 0" to zero, since converting that back to a pointer would
> probably yield a null pointer. [though only _constant_ zero
> expressions are actually guaranteed to convert from 0 to a null ptr]
>
want to make address 0 completely inaccessible to a program would in
fact make *sure* that a pointer to memory address 0 converts to integer
0 and back, regardless of what it is required to do with npcs. "int i =
0; void* p = (void*) i" should, if the conversion is supported, produce
a pointer to location 0, not a null pointer (unless they happen to be
the same thing, of course).
This does mean the programmer has to take really good care to
distinguish null pointers from "0 pointers" ("if (p == 0)" need not test
if p points to memory location 0), but at least it can be done. The
alternative is to make "pointers to 0" special and give them special
integral values for purposes of conversion, but this assumes such values
are available (without making *other* memory locations inaccessible) and
that doing so will not mess up operations on converted values (which
almost certainly will be the case).
Pretend C has a "nil" keyword for designating an npc instead of
"integral constant 0". In this case it would be illogical to convert
pointers to memory location 0 to anything but integral 0 and back, since
no assumptions are being made about the value of nps in the first place.
One guaranteed "special" value (a null pointer) should be enough;
"pointer to 0" should not also be special.
All this assumes, of course, that memory location 0 is accessible. If a
null pointer and a pointer to location 0 have the same representation
and the implementation takes care to trap accesses somehow, no manner of
conversion will help you. Likewise if "location 0" is not a valid
address in the first place.
S.
Francis Glassborow
<jma...@purdue.edu> writes
>Well, the standard says that pointers can be converted to at least
>one integer type, which is implementation-specified, and back.
From memory (haven't got time at the moment to go looking in the
Standard) it is implementation specified whether there is such and
integer type. I.e. the Standard does not say there should be such a
type, it just says what must happen if there is a sufficiently wide
integer type.
Wojtek Lerch
> Well, the standard says that pointers can be converted to at least
> one integer type, which is implementation-specified, and back. One
No, it says the opposite: "The result need not be in the range of any
integer type" (6.3.2.3p6).
> could consider the value of an integer object thus obtained to be
> "the address", and a pointer converted from such an integer type to
> be a pointer which points at that address. By that token, it would
But the numeric value of the converted pointer may depend on the type
you're converting it to. An obvious example is signed vs unsigned, for
pointers that convert to a negative signed value; but I don't think the
standard forbids more surprising combinations. If you can get several
different "addresses" from the same pointer, which one is the "true"
address? What if converting two *different* pointers to two different
integer types can produce the same numeric value?
> be unwise for an implementation to convert a pointer to "memory
> address 0" to zero, since converting that back to a pointer would
> probably yield a null pointer. [though only _constant_ zero
> expressions are actually guaranteed to convert from 0 to a null ptr]
Whether it would be wise or not depends on many factors; allowing sloppy
programming is not necessarily the most important one. And I would
*not* expect converting it back to a pointer to yield a null pointer --
I would expect it to yield the original pointer. The standard actually
guarantees that if you use intptr_t or uintptr_t for the integer type.
kuy...@wizard.net
> On 2005-11-02, kuy...@wizard.net <kuy...@wizard.net> wrote:
> > Mabden wrote:
> > ...
> >> But it turns out that NULL == (void *)0, not location 0 in
> >> memory. Page 102 says that "C guarantees that zero in never a
> >> valid address for data". Apparently, that no longer holds, so was
> >> explained to me over MANY posts. I hope we don't get in to that
> >> again, but you asked. I believe, I believe, stop the hate mail, I
> >> believe.
> >>
> >> I can't think of anything else in the K&R2 that has rocked my
> >> world like that one.
> >
> > How did that rock your world? What effect did it have on your
> > code? I don't know of any way within the C language for portably
> > identifying which address a pointer points at, nor any portable
> > way of creating a pointer which points a specific address. What
> > code did you write that had to be re-written to work correctly
> > with this change?
>
> Well, the standard says that pointers can be converted to at least
> one integer type, which is implementation-specified, and back.
Actually it doesn't: "These types are optional" (7.18.1.4p1).
> One
> could consider the value of an integer object thus obtained to be
> "the address", and a pointer converted from such an integer type to
> be a pointer which points at that address.
Yes, but the standard doesn't mandate such an interpretation, so any
code which relies upon it is not portable.
> By that token, it would
> be unwise for an implementation to convert a pointer to "memory
> address 0" to zero, since converting that back to a pointer would
> probably yield a null pointer. [though only _constant_ zero
> expressions are actually guaranteed to convert from 0 to a null ptr]
Conversion of a integer to a pointer type is completely
implementation-defined, and is therefore unwise unless you know
something more than what the standard itself says about what it will be
converted to by a given implementation. If you do know that it will
convert to a null pointer, there's nothing unwise about the conversion,
so long as you don't try to dereference the resulting pointer.
Keith Thompson
[...]
> Well, the standard says that pointers can be converted to at least
> one integer type, which is implementation-specified, and back. One
> could consider the value of an integer object thus obtained to be
> "the address", and a pointer converted from such an integer type to
> be a pointer which points at that address. By that token, it would
> be unwise for an implementation to convert a pointer to "memory
> address 0" to zero, since converting that back to a pointer would
> probably yield a null pointer. [though only _constant_ zero
> expressions are actually guaranteed to convert from 0 to a null ptr]
(Others have already pointed out that the integer type mentioned above
needn't exist.)
An implementation that stores something useful at address 0 could
still use all-bits-zero as a null pointer. Dereferencing a null
pointer invokes undefined behavior; it doesn't have to cause a trap.
If the implementation defines the behavior as access whatever system
object lives at address 0, that's perfectly legal.
It would be inconvenient in some ways (it would be more difficult to
detect buggy code that dereferences null pointers), but the standard
doesn't require convenience.
> In context, the use of "zero" in K&R2 on those pages appears to
> refer to an integer constant expression 0.
Or it may be an error (though I don't see it in the errata list).
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jordan Abel
> In article <slrndmhl27....@random.yi.org>, Jordan Abel
> <jma...@purdue.edu> writes
>>Well, the standard says that pointers can be converted to at least
>>one integer type, which is implementation-specified, and back.
>
> From memory (haven't got time at the moment to go looking in the
> Standard) it is implementation specified whether there is such and
> integer type. I.e. the Standard does not say there should be such a
> type, it just says what must happen if there is a sufficiently wide
> integer type.
>
My copy of some c89 draft says:
3.3.4 Cast operators
Semantics
Conversions that involve pointers (other than as permitted by the
constraints of §3.3.16.1) shall be specified by means of an explicit
cast; they have implementation-defined aspects: A pointer may be
converted to an integral type. The size of integer required and the
result are implementation-defined. If the space provided is not long
enough, the behavior is undefined. An arbitrary integer may be
converted to a pointer. The result is implementation-defined./37/
37. The mapping functions for converting a pointer to an integer or an
integer to a pointer are intended to be consistent with the addressing
structure of the execution environment.
Jordan Abel
>> Well, the standard says that pointers can be converted to at least
>> one integer type, which is implementation-specified, and back. One
>
> No, it says the opposite: "The result need not be in the range of
> any integer type" (6.3.2.3p6).
>
> sloppy programming is not necessarily the most important one. And I
> would *not* expect converting it back to a pointer to yield a null
> pointer -- I would expect it to yield the original pointer. The
> standard actually guarantees that if you use intptr_t or uintptr_t
> for the integer type.
C89 neither mentions intptr_t nor has a section 6. I've quoted the
relevant section elsewhere in this thread, and it seems to require
that such a type exist, but which type it is is implementation-
defined. It's possible that this requirement was not intended, or that
C99 relaxed it.
Wojtek Lerch
>>
>> No, it says the opposite... (6.3.2.3p6).
>
> C89 neither mentions intptr_t nor has a section 6.
No, I assumed that by "the standard" you meant C99; that's an easy mistake
to make in a discussion about how C has changed since K&R2.
I don't have a copy of C89 and I have to admit that even with the paragraph
you have quoted from it, it's hard for me to understand what point you were
trying to make. Or even which of James Kuyper's questions you were
addressing. Would it be a big problem for you to rephrase it?
Jordan Abel
> I don't have a copy of C89 and I have to admit that even with the
> paragraph you have quoted from it, it's hard for me to understand
> what point you were trying to make. Or even which of James
> Kuyper's questions you were addressing. Would it be a big problem
> for you to rephrase it?
My point was that it appears that in c89 there is required to be an
integer type that pointers can be converted to, as only the width is
left implementation-defined, not the existence of the type. I
conceded that this may not have been intended, but that the language
of the standard is ambiguous [i.e. I was explaining why I believed
that it was guaranteed]
Wojtek Lerch
No, I meant before that, in the reply to James Kuyper where you talked about
the result of the conversion being "the address", and it being "unwise" for
an iplementation to make it zero, and about the sentence Mabden quoted from
K&R referring to constant expressions when it talks about zero not being a
valid address for C data...
Niklas Matthies
> On 2005-11-02, Francis Glassborow <fra...@robinton.demon.co.uk> wrote:
>> Jordan Abel <jma...@purdue.edu> writes:
>>>Well, the standard says that pointers can be converted to at least
>>>one integer type, which is implementation-specified, and back.
>>
>> From memory (haven't got time at the moment to go looking in the
>> Standard) it is implementation specified whether there is such and
>> integer type. I.e. the Standard does not say there should be such a
>> type, it just says what must happen if there is a sufficiently wide
>> integer type.
>
> My copy of some c89 draft says:
>
> 3.3.4 Cast operators
>
> Semantics
>
> Conversions that involve pointers (other than as permitted by the
> constraints of §3.3.16.1) shall be specified by means of an explicit
> cast; they have implementation-defined aspects: A pointer may be
> converted to an integral type. The size of integer required and the
> result are implementation-defined. If the space provided is not long
Please read http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_057.html
-- Niklas Matthies
kuy...@wizard.net
> On 2005-11-02, Francis Glassborow <fra...@robinton.demon.co.uk> wrote:
> > In article <slrndmhl27....@random.yi.org>, Jordan Abel
> > <jma...@purdue.edu> writes
> >>Well, the standard says that pointers can be converted to at least
> >>one integer type, which is implementation-specified, and back.
> >
> > From memory (haven't got time at the moment to go looking in the
> > Standard) it is implementation specified whether there is such and
> > integer type. I.e. the Standard does not say there should be such a
> > type, it just says what must happen if there is a sufficiently wide
> > integer type.
> >
>
> My copy of some c89 draft says:
In this newsgroup, "the standard" refers to the most recently approved
C standard, unless otherwise specified.
> 3.3.4 Cast operators
>
> Semantics
>
> Conversions that involve pointers (other than as permitted by the
> constraints of §3.3.16.1) shall be specified by means of an explicit
> cast; they have implementation-defined aspects: A pointer may be
> converted to an integral type. The size of integer required and the
> result are implementation-defined. If the space provided is not long
> enough, the behavior is undefined. An arbitrary integer may be
> converted to a pointer. The result is implementation-defined./37/
I agree that this wording from C89 doesn't make it clear that the
existence of a sufficiently large integer is not guaranteed. However,
the committe resolved DR 057 by saying that this is indeed the case.
C99 has improved wording in 6.3.2.3p6 that makes it quite clear:
"Any pointer type may be converted to an integer type. Except as
previously specified, the result is implementation-defined. If the
result cannot be represented in the integer type, the behavior is
undefined. The result need not be in the range of values of any integer
type."
Dennis Ritchie
"Mabden" <mabden@sbc_global.net> wrote in message news:1sZ9f.7350$D13....@newssvr11.news.prodigy.com...
> But they moved NULL. Do you agree with and / or like the fact that "C
> guarantees that zero is never a valid address for data" has gone away? I
> have always considered this a "fact", but it has been explained to me
> that it is not. I am VERY interested in you personal opinion about this
> issue, Dennis.
Both standards certainly encourage a memory layout in which
the machine address one might describe as 0 remain unoccupied.
Sometimes one doesn't get the memory layout one wants.
Although it would have been a bit of a pain to adapt,
an '89 or '99 standard in which the only source representation
of the null pointer was NULL or nil or some other built-in token
would have had my approval.
Dennis
Douglas A. Gwyn
> <jma...@purdue.edu> writes
> >Well, the standard says that pointers can be converted to at least
> >one integer type, which is implementation-specified, and back.
> From memory (haven't got time at the moment to go looking in the
> Standard) it is implementation specified whether there is such and
> integer type. I.e. the Standard does not say there should be such a
> type, it just says what must happen if there is a sufficiently wide
> integer type.
As I recall C89 said there was such a type but exactly
which type was implementation-defined. With the
addition of <stdint.h> etc. in C99 there are now macros
that can be tested to determine whether such a type has
been defined, so now it might not be.
Douglas A. Gwyn
> But they moved NULL. Do you agree with and / or like the fact that "C
> guarantees that zero is never a valid address for data" has gone away?
NULL has never had the meaning "address 0" even though it
has often been implemented as such.
NULL was always meant as an "in-band" special marker
meaning "invalid pointer value". When C was first devised,
it was implemented for only a few fairly simple machine
architectures. It was convenient on the PDP-11 to use plain
0 for NULL, as early C was sloppy about conversion between
integer values and pointer values (reflecting its heritage),
the PDP-11 had a small address space, and indeed address 0
was of no use to Unix C programs (although if linked for
separate I&D space, it was possible for data to have address
0, which would be unfortunate since then "0" would be
ambiguous: reference to that data, or an invalid pointer?).
In order to both support traditional implementations and
newer ones, the C standard introduced the notion of "null
pointer constant" (which can look like a zero but not mean
anything to do with any address zero) and formalized the
already fairly well understood latitude for implementations
to map "0" in such contexts to some peculiar pointer value,
if necessary.
No sane program should be affected by the refinement of the
specification for what NULL might expand to.
Keith Thompson
> "Mabden" <mabden@sbc_global.net> wrote in message
> news:1sZ9f.7350$D13....@newssvr11.news.prodigy.com...
>> But they moved NULL. Do you agree with and / or like the fact that "C
>> guarantees that zero is never a valid address for data" has gone away? I
>> have always considered this a "fact", but it has been explained to me
>> that it is not. I am VERY interested in you personal opinion about this
>> issue, Dennis.
>
> Both standards certainly encourage a memory layout in which
> the machine address one might describe as 0 remain unoccupied.
> Sometimes one doesn't get the memory layout one wants.
But the encouragement is fairly limited, isn't it? For an
implementation that uses, say, 0xFFFFFFFF as a null pointer, and
perhaps stores something useful at address 0x00000000, the only real
extra effort would be that the conversion of a constant 0 from int to
pointer wouldn't be the same as the conversion of a non-constant 0
from int to pointer. For a more common implementation that uses
address 0x00000000 for null pointers, the recognition of null pointer
constants falls out naturally from the ordinary conversion rules.
> Although it would have been a bit of a pain to adapt,
> an '89 or '99 standard in which the only source representation
> of the null pointer was NULL or nil or some other built-in token
> would have had my approval.
<AOL>Me too!</AOL>
If you need help building a time machine so you can go back and
promote this change, let us know. At the very least, it would almost
entirely eliminate the need for section 5 of the comp.lang.c FAQ.
While I have your attention, K&R2 page 102 says:
C guarantees that zero is never a valid address for data, so a
return value of zero can be used to signal an abnormal event, in
this case, no space.
Is "zero" here intended to refer to the actual address 0, or to the
null pointer constant 0? Should this be mentioned in the errata?
Francis Glassborow
<DAG...@null.net> writes
As I was not around in the 80s I will take your word for it but it seems
odd to me because it places a requirement on that at least unsigned long
have a width equal to or greater than that for void*. IOWs a system
using 48-bit addresses would have had to have at least 48-bit longs.
The alternative of saying that converting an address that will not 'fit'
in an unsigned long has undefined behaviour is, IMHO, equivalent to
saying that there is no suitable integer type.
BTW, pre C99 what purpose would have been served by making the integer
type implementation defined? If it would fit in any integer type it
would have fitted in unsigned long (that is not true in C99 which
permits additional, possibly wider, integer types)
Douglas A. Gwyn
> As I was not around in the 80s I will take your word for it but it seems
> odd to me because it places a requirement on that at least unsigned long
> have a width equal to or greater than that for void*. IOWs a system
> using 48-bit addresses would have had to have at least 48-bit longs.
Indeed, that kind of argument was used to decide that the typedef
should be optional.
> The alternative of saying that converting an address that will not 'fit'
> in an unsigned long has undefined behaviour is, IMHO, equivalent to
> saying that there is no suitable integer type.
Alas, sometimes for smaller programs the integer equivalent has a
small enough value that it will work whereas for larger programs
there aren't enough bits. I agree that this sort of hit-or-miss
conversion should not be encouraged by the standard.
> BTW, pre C99 what purpose would have been served by making the integer
> type implementation defined? If it would fit in any integer type it
> would have fitted in unsigned long (that is not true in C99 which
> permits additional, possibly wider, integer types)
Typically the address would fit in type int, and there seemed no
reason to require the compiler to have to support conversion for
other sizes. (Would need more code and data in the compiler.)
Mabden
news:lnu0euj...@nuthaus.mib.org...
> "Dennis Ritchie" <d...@bell-labs.com> writes:
> > "Mabden" <mabden@sbc_global.net> wrote in message
> > news:1sZ9f.7350$D13....@newssvr11.news.prodigy.com...
> >> But they moved NULL. Do you agree with and / or like the fact that
"C
> >> guarantees that zero is never a valid address for data" has gone
away? I
> >> have always considered this a "fact", but it has been explained to
me
> >> that it is not. I am VERY interested in you personal opinion about
this
> >> issue, Dennis.
> >
> > Both standards certainly encourage a memory layout in which
> > the machine address one might describe as 0 remain unoccupied.
> > Sometimes one doesn't get the memory layout one wants.
Just to be clear, location zero (in the prior posts) means
all-bits-zero, from the discussions I have been having around here,
whereas it has been convincingly (ie: 2x4 to the head) argued that NULL
is a (void *)0, and may appear anywhere.
The latest news I have been privy to states that there may be more than
one NULL, or even a series of pointers that would equate to NULL. I was
taken aback a little by this news. I always had "known" from that little
pamphlet you provided that "zero means zero!" :-)
> But the encouragement is fairly limited, isn't it? For an
> implementation that uses, say, 0xFFFFFFFF as a null pointer, and
> perhaps stores something useful at address 0x00000000, the only real
> extra effort would be that the conversion of a constant 0 from int to
> pointer wouldn't be the same as the conversion of a non-constant 0
> from int to pointer. For a more common implementation that uses
> address 0x00000000 for null pointers, the recognition of null pointer
> constants falls out naturally from the ordinary conversion rules.
>
> > Although it would have been a bit of a pain to adapt,
> > an '89 or '99 standard in which the only source representation
> > of the null pointer was NULL or nil or some other built-in token
> > would have had my approval.
Or... location zero? What I don't get is why that is such a problem. You
put it down on paper 25 years ago, and we have to deal the the
possibility that some hardware manufacturer or compiler may allow that
address as valid?! We are talking about 4 f'ing bytes! Just let it be an
invalid address people! Who is making this a problem?! Leave the NULL
alone! ;-)
> While I have your attention, K&R2 page 102 says:
Ahem, I believe it was MY post the Great Sage was responding to, Keith.
I even did my happy dance and scared my girlfriend with my shouts. Moses
was less impressed than I was, when he heard a burning bush speak. Wow,
Dennis M. Ritchie "spoke" to me! I can die now. I know some of you are
thinking - so die already... ;-)
> C guarantees that zero is never a valid address for data, so a
> return value of zero can be used to signal an abnormal event, in
> this case, no space.
>
> Is "zero" here intended to refer to the actual address 0, or to the
> null pointer constant 0? Should this be mentioned in the errata?
Yes! Good question! But you didn't post enough, Keith! Perhaps you think
Dennis has read the book before... ;-) But others may not have.
You don't mention that we are talking about a function that returns a
pointer. Here's a bit of the preface:
"In general a pointer can be initialized just as any other variable
can...
alloc returns a pointer to the beginning of a block of characters...
If not, alloc must return some signal that no space is left. C
guarantees that zero is never a valid address for data..."
"
Just so everyone understands, the prototype is "char *alloc(int n);"
Does zero mean address 0x0000000, or (void *)0 [aka NULL], or (is there
another way of being zero)?
--
Mabden
Mabden
news:4368dfcf$0$11073$e4fe...@news.xs4all.nl...
> All this assumes, of course, that memory location 0 is accessible. If
a
> null pointer and a pointer to location 0 have the same representation
> and the implementation takes care to trap accesses somehow, no manner
of
> conversion will help you. Likewise if "location 0" is not a valid
> address in the first place.
Exactly my point. If we can't be sure from hardware to software, from
handheld to mainframe, that needs to be known. What exactly are the
rules. That is what my clumsy question is trying to get at.
--
Mabden
Mabden
news:1130972464.0...@g43g2000cwa.googlegroups.com...
>Jordan Abel wrote:
>> My copy of some c89 draft says:
>In this newsgroup, "the standard" refers to the most recently approved
>C standard, unless otherwise specified.
OK, now tell me of a compiler I can use that implements your standard.
--
Mabden
Mabden
news:MF9af.4615$J14.3...@news20.bellglobal.com...
Speak of the Devil...
I just "think" he is saying that you can move a pointer into an int, and
it may be zero, or you could assign zero to the int (x=0) but to then
assign it back to a pointer would be unwise, because, as we are
discussing in another thread RIGHT NOW, it may not be a null pointer,
and there may be multiple null pointers, etc.
What is Latin for, "Programmer Beware!"
--
Mabden
Mabden
> Jordan Abel <jma...@purdue.edu> writes:
> [...]
> > Well, the standard says that pointers can be converted to at least
> > one integer type, which is implementation-specified, and back. One
> > could consider the value of an integer object thus obtained to be
> > "the address", and a pointer converted from such an integer type to
> > be a pointer which points at that address. By that token, it would
> > be unwise for an implementation to convert a pointer to "memory
> > address 0" to zero, since converting that back to a pointer would
> > probably yield a null pointer. [though only _constant_ zero
> > expressions are actually guaranteed to convert from 0 to a null ptr]
>
> (Others have already pointed out that the integer type mentioned above
> needn't exist.)
Crazy talk. I'm just sayin'.
> An implementation that stores something useful at address 0 could
> still use all-bits-zero as a null pointer. Dereferencing a null
> pointer invokes undefined behavior; it doesn't have to cause a trap.
> If the implementation defines the behavior as access whatever system
> object lives at address 0, that's perfectly legal.
Dude, now you are just fucking with my head for sport. ;-)
Not to crossreference posts, but:
Just how would this value go into your "interesting" _Bool? As true or
false?
Or am I right that there are cases where putting a pointer into a _Bool
might result in something you don't anticipate? Just nod your head, and
we can move on. You don't even have to post.
--
Mabden
Mabden
news:43696A75...@null.net...
Not my point. Thank you for playing.
Perhaps you missed the "p.p.s please don't tell me about null and zero"
plea. You're late, and you didn't help.
We are way deeper into it than that. Please read first, and then post
about how wrong I am later - I have a list of people who consider me
wrong, and an asshole, that has I much better pedigree than your
worthless self.
--
Mabden
kuy...@wizard.net
I've read that Comeau C/C++ and Dinkum C99 are advertised as comprising
a full C99
implementation, though I can't find an explicit claim to that effect on
their web sites, and I can't vouch for it from personal experience.
Even if they're not fully conforming, they're at least pretty close,
which is to justify talking about C99 compilers as a current reality
(or nearly so). C99 is phasing in more slowly than C90 did (though that
was a pretty long process, too). However, keep in mind that C99 is less
of an improvement over it's predecessor than C90 was, because C90 had
fewer problems that needed resolving than K&R C did. With less
motivation to change, and a larger body of legacy code to cope with,
it's reasonable for this transition to be slower than the previous one.
In any event, this is comp.std.c; it's normal and intended that this
newsgroup talk about standards that haven't even been adopted yet, much
less implemented. In other newsgroups you can refer to a standard that
has been superceded for 6 years now, without specifying which one, and
have a reasonable hope that they know which one it is you're referring
to. In this newsgroup, if you don't specify it, we're entitled to
assume that you're referring to the current one. You can violate that
assumption if you wish, but I'd recommend not complaining about it if
you recieve the misunderstanding such miscommunication deserves.
kuy...@wizard.net
> "Keith Thompson" <ks...@mib.org> wrote in message
> news:lnu0euj...@nuthaus.mib.org...
> > "Dennis Ritchie" <d...@bell-labs.com> writes:
> > > Both standards certainly encourage a memory layout in which
> > > the machine address one might describe as 0 remain unoccupied.
> > > Sometimes one doesn't get the memory layout one wants.
>
> Just to be clear, location zero (in the prior posts) means
> all-bits-zero, from the discussions I have been having around here,
> whereas it has been convincingly (ie: 2x4 to the head) argued that NULL
> is a (void *)0, and may appear anywhere.
More precisely, NULL can be (void*)0. It can also be a lot of other
things.
Also, you can refer to the location pointed at by a pointer with all
bits zero as "location zero" if you wish. However, keep in mind that
such a pointer is not required to refer to the location with a hardware
address of zero.
> The latest news I have been privy to states that there may be more than
> one NULL, or even a series of pointers that would equate to NULL. I was
Technically, that may be true, but not in the sense that you mean.
There are multiple standard headers that define NULL: <locale.h>,
<stddef.h>, <stdio.h>, <stdlib.h>, <string.h>, <time.h>, and <wchar.h>.
I think it might be legal for the different headers to have different
definitions for NULL, though I wouldn't be surprised if someone cites
me a section of the standard that says otherwise.
What I think you're actually referring to is not that there can be more
than one NULL, but that there can be multiple null pointer values.
> You don't mention that we are talking about a function that returns a
> pointer. Here's a bit of the preface:
>
> "In general a pointer can be initialized just as any other variable
> can...
>
> alloc returns a pointer to the beginning of a block of characters...
> If not, alloc must return some signal that no space is left. C
> guarantees that zero is never a valid address for data..."
> "
> Just so everyone understands, the prototype is "char *alloc(int n);"
>
> Does zero mean address 0x0000000, or (void *)0 [aka NULL], or (is there
> another way of being zero)?
His use of "zero" in this context is not exactly correct; at least not
with the current standard. I imagine that he may have used that
terminology because he rembers a time when it was a correct
description, and it's certainly easier to understand than a more
precise statement would have been. The alloc() function is not actually
part of the C standard. As a practical matter, it does exist, and does
return a null pointer value when it fails, and null pointers always
compare equal to null pointer constants such as NULL.
kuy...@wizard.net
Here's the answer: you can't be sure. The representation of pointers is
pretty much completely implementation defined, and code which makes use
of knowledge of the representation is portable only to those machines
for which that knowledge is correct. There is, in general, no portable
need for a program to be aware of the representation, so this shouldn't
be a problem. Can you give an example of code where you think such
knowledge is needed?
Netocrat
> "Douglas A. Gwyn" <DAG...@null.net> wrote in message
> news:43696A75...@null.net...
>> Mabden wrote:
>> > But they moved NULL. Do you agree with and / or like the fact that "C
>> > guarantees that zero is never a valid address for data" has gone
>> > away?
>>
>> NULL has never had the meaning "address 0" even though it has often
>> been implemented as such.
> Perhaps you missed the "p.p.s please don't tell me about null and zero"
> plea.
That request was made in a separate comp.lang.c thread. It doesn't appear
in this newsgroup unless in a post that my newsreader didn't receive.
kuy...@wizard.net
...
> I just "think" he is saying that you can move a pointer into an int, and
> it may be zero, or you could assign zero to the int (x=0) but to then
> assign it back to a pointer would be unwise, because, as we are
> discussing in another thread RIGHT NOW, it may not be a null pointer,
> and there may be multiple null pointers, etc.
Yes, relying on conversion of an integer with a value of 0 to an
pointer type is unwise. However, the reason it's unwise isn't the fact
that it might result in a null pointer value. Null pointer values, if
properly dealt with, are quite safe. The real danger is the standard
doesn't guaranteed that it results in a null pointer; it doesn't
gurantee that it results in a pointer with all bits zero, it doesn't
guarantee that it results in a pointer that refers to memory address 0,
it doesn't even gurantee that the behavior is defined.
On the other hand, if you #include <stdint.h>, protect the relevant
code by checking whether INTPTR_MAX is #defined, use an intptr_t object
to store the integer, and gave that integer it's current value by
converting from a valid pointer value, then it's perfectly safe to
convert it back to that same pointer type. Just remember - if and only
if the original pointer value was null, then the final pointer value is
also guaranteed to be null; take appropriate precautions before
attempting to dereference it.
Mabden
news:1131114907.0...@z14g2000cwz.googlegroups.com...
Not really. I'm pretty much done talking about it.
It all started when Keith T mentioned you could store a pointer in a
_Bool, and I asked why that would be a useful thing to do., but that was
in comp.lang.c so I'm not sure why we're talking about it over here,
too. I didn't cross-post it, so someone else must have. Sorry if did.
--
Mabden
kuy...@wizard.net
Mabden wrote:
> "Keith Thompson" <ks...@mib.org> wrote in message
> news:lnbr12n...@nuthaus.mib.org...
> > Jordan Abel <jma...@purdue.edu> writes:
> > [...]
> > > Well, the standard says that pointers can be converted to at least
> > > one integer type, which is implementation-specified, and back. One
> > > could consider the value of an integer object thus obtained to be
> > > "the address", and a pointer converted from such an integer type to
> > > be a pointer which points at that address. By that token, it would
> > > be unwise for an implementation to convert a pointer to "memory
> > > address 0" to zero, since converting that back to a pointer would
> > > probably yield a null pointer. [though only _constant_ zero
> > > expressions are actually guaranteed to convert from 0 to a null ptr]
> >
> > (Others have already pointed out that the integer type mentioned above
> > needn't exist.)
>
> Crazy talk. I'm just sayin'.
You may consider it crazy, but it's also true.
> > An implementation that stores something useful at address 0 could
> > still use all-bits-zero as a null pointer. Dereferencing a null
> > pointer invokes undefined behavior; it doesn't have to cause a trap.
> > If the implementation defines the behavior as access whatever system
> > object lives at address 0, that's perfectly legal.
>
> Dude, now you are just fucking with my head for sport. ;-)
>
> Not to crossreference posts, but:
> Just how would this value go into your "interesting" _Bool? As true or
> false?
Any pointer value which the implementation has defined to be null must
convert to a _Bool value of false.
> Or am I right that there are cases where putting a pointer into a _Bool
> might result in something you don't anticipate?
If it's a conforming implementation of C, it has to result in a value
of false; there's nothing that can be unanticipated about it (except
possibly it's failure to conform).
Douglas A. Gwyn
> Not my point. Thank you for playing.
I tried to explain the historical origin of the artifact,
which you need to understand but so far haven't shown any
sign of understanding. If you won't make the effort,
then continuing this thread is pointless.
lawrenc...@ugs.com
>
> K&R WAS the definition of C, prior to the ANSI/ISO standard
Not really -- it was *a* definition, but it wasn't *the* definition. In
fact, there was no "the" definition, there were lots of competing
definitions, which is why the ANSI standard was so important. Prior to
the advent of a plethora of C compilers for the PC, "the" definition of
C was whatever the Unix documentation said it was. At the very least,
this included structure assignment (including function parameters and
return values) and enums, neither of which was in K&R. It may even have
included unsigned short and unsigned long. Unfortunately, the
aforementioned plethora of PC compilers were almost all based entirely
on K&R, ignoring the changes that had been made to C in the intervening
years, making the situation much less clear than it had been.
-Larry Jones
I wonder if you can refuse to inherit the world. -- Calvin
lawrenc...@ugs.com
>
> James Buchanan wrote:
>> For example, would the draft standard be good enough to go on when writing a
>> new ISO Standard C compiler and C library?
>
> No. Changes were made up to the last minute.
And beyond. :-)
-Larry Jones
What a waste to be going to school on a morning like this. -- Calvin
Unknown
> Although it would have been a bit of a pain to adapt,
> an '89 or '99 standard in which the only source representation
> of the null pointer was NULL or nil or some other built-in token
> would have had my approval.
Pity it didn't happen in 1989. It's probably too late by now...
Francis Glassborow
<mabden@sbc_global.net> writes
>Or... location zero? What I don't get is why that is such a problem. You
>put it down on paper 25 years ago, and we have to deal the the
>possibility that some hardware manufacturer or compiler may allow that
>address as valid?! We are talking about 4 f'ing bytes! Just let it be an
>invalid address people! Who is making this a problem?! Leave the NULL
>alone! ;-)
IIRC address 0 was significant in CPM machines.
lawrenc...@ugs.com
It was too late in 1989.
-Larry Jones
It COULD'VE happened by accident! -- Calvin
Keith Thompson
> Free Bird <@> wrote:
>>
>> Dennis Ritchie wrote:
>>
>>> Although it would have been a bit of a pain to adapt,
>>> an '89 or '99 standard in which the only source representation
>>> of the null pointer was NULL or nil or some other built-in token
>>> would have had my approval.
>>
>> Pity it didn't happen in 1989. It's probably too late by now...
>
> It was too late in 1989.
Perhaps. On the other hand, perhaps null pointer constants other than
a new "nil" keyword could have been deprecated in the 1989 standard.
Compilers could issue warnings for other forms of null pointer
constants; by now, it would be practical to reject other forms except
in a backward-compatible mode like gcc's "-traditional". We've nearly
eliminated old-style function declarations; we might have done the
same with old-style null pointer constants.
Either that, or this is all just wishful thinking on my part.
Casper H.S. Dik
>In article <T7Jaf.8230$BZ5....@newssvr13.news.prodigy.com>, Mabden
><mabden@sbc_global.net> writes
>>Or... location zero? What I don't get is why that is such a problem. You
>>put it down on paper 25 years ago, and we have to deal the the
>>possibility that some hardware manufacturer or compiler may allow that
>>address as valid?! We are talking about 4 f'ing bytes! Just let it be an
>>invalid address people! Who is making this a problem?! Leave the NULL
>>alone! ;-)
>IIRC address 0 was significant in CPM machines.
In many different OSes the zero address was valid. (HP-UX, many
SVR3 implementations, VAX variant of BSD unix also) SunOS always had
address 0 unmapped but catered for applications which did stuff
like printf("%s", NULL).
With the advent of the mmap() system call, most of them allowed the
remapping of address 0.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
pete
>
> Francis Glassborow <fra...@robinton.demon.co.uk> writes:
> >IIRC address 0 was significant in CPM machines.
>
> In many different OSes the zero address was valid.
In some PIC micros, the registers are addressable and
when your code looks like it's accessing register zero,
it's actually accessing the register
that register number four points to.
--
pete
Unknown
> lawrenc...@ugs.com writes:
> > Free Bird <@> wrote:
> >>
> >> Dennis Ritchie wrote:
> >>
> >>> Although it would have been a bit of a pain to adapt,
> >>> an '89 or '99 standard in which the only source representation
> >>> of the null pointer was NULL or nil or some other built-in token
> >>> would have had my approval.
> >>
> >> Pity it didn't happen in 1989. It's probably too late by now...
> >
> > It was too late in 1989.
>
> Perhaps. On the other hand, perhaps null pointer constants other than
> a new "nil" keyword could have been deprecated in the 1989 standard.
> Compilers could issue warnings for other forms of null pointer
> constants; by now, it would be practical to reject other forms except
> in a backward-compatible mode like gcc's "-traditional". We've nearly
> eliminated old-style function declarations; we might have done the
> same with old-style null pointer constants.
>
> Either that, or this is all just wishful thinking on my part.
Geoff Clare
>> OK, now tell me of a compiler I can use that implements your standard.
>
> I've read that Comeau C/C++ and Dinkum C99 are advertised as comprising a
> full C99
> implementation, though I can't find an explicit claim to that effect on
> their web sites, and I can't vouch for it from personal experience.
The current releases of Solaris and AIX are claimed (by Sun and IBM
respectively) to have C99 compilers. I don't know if the claims are
stated directly anywhere, but there is certainly an indirect claim in
effect in each case, because both systems have UNIX03 certification
from The Open Group. A full C99 implementation is part of the
requirement for UNIX03 conformance.
--
Geoff Clare <net...@gclare.org.uk>
Douglas A. Gwyn
> IIRC address 0 was significant in CPM machines.
Address 0 is a valid data and/or code address on many systems,
even on the PDp-11 where C originated. It happened that
process virtual address 0 was used for purposes other than
program data/code, so usurping it for a null-pointer value
didn't cause Unix apps any real problem.
Dave Thompson
> Casper H.S. Dik wrote:
> >
> > Francis Glassborow <fra...@robinton.demon.co.uk> writes:
>
> > >IIRC address 0 was significant in CPM machines.
<pedantic> CP/M Control Program for Microcomputers </>
I believe 0 was (warm?) reboot. 5 was definitely system-call entry,
and I think 3 and 4 were OS data manipulable but not to be clobbered
by applications, something like console and systemdisk selection.
> >
> > In many different OSes the zero address was valid.
>
> In some PIC micros, the registers are addressable and
> when your code looks like it's accessing register zero,
> it's actually accessing the register
> that register number four points to.
In PDP-10 'memory' 0-15 are directly registers 0-15, and you could
(and people sometimes did) execute a sufficiently short section of
code like an inner loop from there.
- David.Thompson1 at worldnet.att.net