NULL and 0
flippant...@my-deja.com
such, and I feel that I'm still a bit hazy on what "turns into" a null
pointer and what does not. Mostly, my confusion is in code like this:
int i = 0;
int *ptr = i; /* hmm...is this null? */
Does that make ptr into a NULL pointer? Or does it literally have to
initialized with a constant like this:
int *ptr = 0; /* now we have a null pointer? */
or
int *ptr = NULL;
I guess my main concern is that old code that I wrote for a linked list
won't work, because there are some lines where I allowed this to work:
anode->next = bnode->next; /* where bnode is pointing to NULL */
Since the constant 0 is not used (however, it was assigned to
bnode->next at one point to terminate the list), will the compiler still
handle everything so a test like this:
if (bnode->next != NULL)
still works?
fs
Sent via Deja.com http://www.deja.com/
Before you buy.
mike burrell
this is implementation defined. while the standard says that one can
convert an integer type into a pointer (and vice versa), it says that it's
implementation defined as to how it works exactly.
the answer is "usually".
i'm wondering about what would happen if 'i' were declared as being 'const',
though.
> int *ptr = 0; /* now we have a null pointer? */
yes, that is a null pointer.
> int *ptr = NULL;
as is this.
> I guess my main concern is that old code that I wrote for a linked list
> won't work, because there are some lines where I allowed this to work:
> anode->next = bnode->next; /* where bnode is pointing to NULL */
> Since the constant 0 is not used (however, it was assigned to
> bnode->next at one point to terminate the list), will the compiler still
> handle everything so a test like this:
> if (bnode->next != NULL)
> still works?
yes that is good.
--
/"\ m i k e b u r r e l l
\ / ASCII RIBBON CAMPAIGN mik...@home.com
X AGAINST HTML MAIL
/ \
Jack Klein
in comp.lang.c:
> I've been following the recent threads concerning NULL pointers, and
> such, and I feel that I'm still a bit hazy on what "turns into" a null
> pointer and what does not. Mostly, my confusion is in code like this:
>
> int i = 0;
> int *ptr = i; /* hmm...is this null? */
>
> Does that make ptr into a NULL pointer? Or does it literally have to
> initialized with a constant like this:
>
> int *ptr = 0; /* now we have a null pointer? */
>
> or
>
> int *ptr = NULL;
>
> I guess my main concern is that old code that I wrote for a linked list
> won't work, because there are some lines where I allowed this to work:
>
> anode->next = bnode->next; /* where bnode is pointing to NULL */
>
> Since the constant 0 is not used (however, it was assigned to
> bnode->next at one point to terminate the list), will the compiler still
> handle everything so a test like this:
>
> if (bnode->next != NULL)
>
> still works?
>
> fs
Here is the point...
On some architectures it is not practical to use a value of all bits 0
for null pointers, on others it is. Due to hardware requirements, let
us assume that on some particular computer the memory management unit
only traps access to the address 0xdeadbeef, and we want out compiler
to use this value to accesses to null pointers halt the program.
char *p = 0; /* or NULL */
The compiler is required to recognize this AT COMPILE TIME and
translate it to:
char *p = (char *)0xdeadbeef;
Now lets assume this:
void f(int i)
{
char *p = (char *)i;
/* stuff */
}
int main(void)
{
int i = 0;
f(i);
return 0;
}
In this case it is quite easy to see that the assignment to the
pointer is not done at compile time, but at run time. Your question
is whether the compiler is supposed to inspect the value of the int,
find out that it is 0, and because of this set p to 0xdeadbeef. The
answer is probably not.
Most likely (because it is implementation-defined) p will wind up with
a value of all bits 0, and it will be NULL if all bits 0 happens to be
the internal representation of null pointers for the platform, and not
NULL if all bits 0 is not the representation of a null pointer.
But since it is implementation-defined, a compiler could generate run
time code to check the value of the int for 0 and set the pointer to
NULL if so. I have never heard of a compiler doing so, but that is
the essence of implementation-defined.
In the case of:
char *p = NULL;
char *q;
/* and later */
q = p;
This assignment will result in q being a null pointer. Even if a
bitwise copy is performed, the bit pattern in p represented a null
pointer, so the same bit pattern in q represents one as well.
Jack Klein
--
Home: http://jackklein.home.att.net
-hs-
<8f1p1m$83s$1...@nnrp1.deja.com>...
>I've been following the recent threads concerning NULL pointers, and
>such, and I feel that I'm still a bit hazy on what "turns into" a null
>pointer and what does not. Mostly, my confusion is in code like this:
>
>int i = 0;
>int *ptr = i; /* hmm...is this null? */
This is a pointer that has been set to all-bits-to-zero. Same as:
memset (ptr,0,sizeof ptr);
From the language point of view, it is not a NULL pointer.
>Does that make ptr into a NULL pointer? Or does it literally have to
No.
>initialized with a constant like this:
Yes
>int *ptr = 0; /* now we have a null pointer? */
>
>or
>
>int *ptr = NULL;
You are right : There are two ways to initialize a pointer to NULL with a
constant:
int *ptr = 0;
int *ptr = NULL; /* include <stddef.h> */
In addition you can use a NULL pointer.
int *ptr = 0;
int *p = ptr;
>I guess my main concern is that old code that I wrote for a linked list
>won't work, because there are some lines where I allowed this to work:
>
>anode->next = bnode->next; /* where bnode is pointing to NULL */
No doubt, this is an undefined behaviour. Anything can happen:
- Nothing
- Protection error
- System error
- Disk formatting
- Send ILOVEYOU across the world... who knows...
>Since the constant 0 is not used (however, it was assigned to
>bnode->next at one point to terminate the list), will the compiler still
>handle everything so a test like this:
>
>if (bnode->next != NULL)
>
>still works?
Yes. The following pointer tests are valid
void *p;
if (p)
if (p!=0)
if (p!=NULL)
if (!p)
if (p==0)
if (p==NULL)
I am not sure, but I think that you can also compare pointers... (I hope so,
because my personnal memory checker is based on that ! I know that "it
works", but is is portable ?)
--
-hs- "Stove"
CLC-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
ISO-C Library: http://www.dinkum.com/htm_cl
"Show us your source code, and let us, like
rapacious vultures half-crazed by starvation, rip it to shreds until
there's practically nothing left" --Richard Heathfield CLC
Michael Rubenstein
<email....@server.invalid> wrote:
>flippant...@my-deja.com a écrit dans le message
><8f1p1m$83s$1...@nnrp1.deja.com>...
>>I've been following the recent threads concerning NULL pointers, and
>>such, and I feel that I'm still a bit hazy on what "turns into" a null
>>pointer and what does not. Mostly, my confusion is in code like this:
>>
>>int i = 0;
>>int *ptr = i; /* hmm...is this null? */
>
>This is a pointer that has been set to all-bits-to-zero. Same as:
>
>memset (ptr,0,sizeof ptr);
Not necessarily. The conversion from integer to pointer is
implementation defined -- there is nothing in the standard that
requires the bit representation to be preserved.
Note that the initialization of ptr is incorrect and requires a
diagnostic. There is no standard conversion from int (other than
a constant integer 0) to pointer.
Steve Summit
>flippant...@my-deja.com a écrit dans le message
><8f1p1m$83s$1...@nnrp1.deja.com>...
>> won't work, because there are some lines where I allowed this to work:
>>
>> anode->next = bnode->next; /* where bnode is pointing to NULL */
>
I read Flippant Squirrel's post as saying that bnode->next was
a null pointer. In that case, of course, the assignment is
perfectly valid and well-behaved.
>> Since the constant 0 is not used (however, it was assigned to
>> bnode->next at one point to terminate the list), will the compiler
>> still handle everything so a test like this:
>>
>> if (bnode->next != NULL)
>>
>> still works?
Yes.
When you say
bnode->next = NULL;
the compiler recognizes NULL (strictly speaking, it recognizes
NULL's valid expansion) as a null pointer constant, and sets
bnode->next to a null pointer, of a type appropriate for
bnode->next.
Later, when you say
anode->next = bnode->next;
you're doing a simple pointer assignment (presuming anode->next
and bnode->next are of the same type), and this assignment is
perfectly valid as long as bnode->next's value is a valid pointer
or a null pointer.
Still later, when you test
if(anode->next == NULL)
or
if(bnode->next != NULL)
the compiler again recognizes NULL as a null pointer constant,
converts it (in effect) to a null pointer value appropriate to
the type of anode->next or bnode->next, and performs the pointer
comparison. This is, again, perfectly well-defined,
well-behaved, and appropriate.
Your wording "since the constant 0 is not used" suggests that
you're assuming that 0 is the only official, or the best, way to
"get" a null pointer value. In fact, using the constant 0 is the
fishiest way of getting a null pointer value, because the null
pointer constant 0 looks an awful lot like the integer constant
0, and the compiler has to do a certain amount of special-casing
to make it work, and inordinate amounts of confusion often occur
in the minds of human observers who witness the spectacle. All
the *other* valid ways of "getting" a null pointer -- that is,
having malloc return you one, or having fopen return you one,
or performing a pointer assignment of the form
anode->next = bnode->next;
where bnode->next happens, by hook or by crook, to contain a
proper null pointer value -- all these other ways are perfectly
valid, too, and don't (or shouldn't) have any of the fishiness
or suspicions surrounding them that null pointer constants do.
Steve Summit
s...@eskimo.com
-hs-
>In article <8f1tkm$2qfi$1...@news5.isdnet.net>, hs wrote:
>>flippant...@my-deja.com a écrit dans le message
>><8f1p1m$83s$1...@nnrp1.deja.com>...
>>> I guess my main concern is that old code that I wrote for a linked list
>>> won't work, because there are some lines where I allowed this to work:
>>>
>>> anode->next = bnode->next; /* where bnode is pointing to NULL */
>>
>> No doubt, this is an undefined behaviour. Anything can happen...
>
>I read Flippant Squirrel's post as saying that bnode->next was
>a null pointer. In that case, of course, the assignment is
>perfectly valid and well-behaved.
What about his comment ? He said "bnode is pointing to NULL" !
Obviouslly, in this conditions, the value of bnode->next is undefined. We
don't need another Chernobyl...
Stef
<8f1p1m$83s$1...@nnrp1.deja.com>...
>I've been following the recent threads concerning NULL pointers, and
>such, and I feel that I'm still a bit hazy on what "turns into" a null
>pointer and what does not. Mostly, my confusion is in code like this:
>
>int i = 0;
>int *ptr = i; /* hmm...is this null? */
>
>
You declare a pointer to int, but you do not make it point anywhere. Then
you assign i to the location ptr is pointing to (where would this be?). I
think you meant to write:
int i = 0;
ptr = i; /* No asterix */
>Or does it literally have to
>initialized with a constant like this:
>
>int *ptr = 0; /* now we have a null pointer? */
>
>or
>
>int *ptr = NULL;
>
Same here:
int *ptr;
ptr = 0;
/ *or */
ptr = NULL;
Now you can start the discussion on which will assign NULL to ptr. That
subject is already discussed on other replies.
Regards,
Stef
Richard Heathfield
>
> flippant...@my-deja.com wrote in message
> <8f1p1m$83s$1...@nnrp1.deja.com>...
> >I've been following the recent threads concerning NULL pointers, and
> >such, and I feel that I'm still a bit hazy on what "turns into" a null
> >pointer and what does not. Mostly, my confusion is in code like this:
> >
> >int i = 0;
> >int *ptr = i; /* hmm...is this null? */
> >
> >Does that make ptr into a NULL pointer?
> >
> No, this will invoke undefined behavior!
Possibly. I think that's the reason he posted the code - to find out
whether it does or does not invoke undefined behaviour.
> You declare a pointer to int, but you do not make it point anywhere. Then
> you assign i to the location ptr is pointing to
Not so. This is an initialisation, not a mere assignment. The statement
int *ptr = i; defines a pointer and assigns its value (i.e. the address
to which it points) using the value of i (i.e. 0).
> (where would this be?). I
> think you meant to write:
> int i = 0;
> int *ptr;
> ptr = i; /* No asterix */
There is no functional difference between the two forms
int *ptr = i;
and
int *ptr;
ptr = i;
as far as I am aware. Shame about no asterix. Perhaps Obelix will get a
search party together?
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
35 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (62
to go)
Stef
<39168C98...@eton.powernet.co.uk>...
>> >int i = 0;
>> >int *ptr = i; /* hmm...is this null? */
>> >
>> >Does that make ptr into a NULL pointer?
>> >
>> No, this will invoke undefined behavior!
>
>Possibly. I think that's the reason he posted the code - to find out
>whether it does or does not invoke undefined behaviour.
>
>> You declare a pointer to int, but you do not make it point anywhere. Then
>> you assign i to the location ptr is pointing to
>
>Not so. This is an initialisation, not a mere assignment. The statement
>
>int *ptr = i; defines a pointer and assigns its value (i.e. the address
>to which it points) using the value of i (i.e. 0).
>
>> (where would this be?). I
>> think you meant to write:
>> int i = 0;
>> int *ptr;
>> ptr = i; /* No asterix */
>
>There is no functional difference between the two forms
>
>int *ptr = i;
>
>and
>
>int *ptr;
>
>ptr = i;
>
>as far as I am aware. Shame about no asterix. Perhaps Obelix will get a
>search party together?
>
1) Never reply to a question before coffee (add a few cups on monday
mornings)
2) Always consult your reference book before posting, even when the problem
looks simple.
3) Double-doubt yourself if other posters have ignored a 'typo' for a few
days.
4) Can save myself a bit of typing.
5) Thought could have saved bits of typing already [1].
6) Consult a dictionary when using a foreign language (oops, forgot it
again).
7) Idefix makes an excellent search dog.
Stef
[1] Why use this all the time?:
char *ptr = "Initialize a char pointer";
And never use this?:
int *ptr = NULL;
Tjeez, the quarter must have got stuck somewhere :-)
--
Much of the excitement we get out of our work is that we don't really
know what we are doing.
-- E. Dijkstra
Chris Mears
Heathfield <bin...@eton.powernet.co.uk> wrote:
>Stef wrote:
[snip]
>> (where would this be?). I
>> think you meant to write:
>> int i = 0;
>> int *ptr;
>> ptr = i; /* No asterix */
>
>There is no functional difference between the two forms
>
>int *ptr = i;
>
>and
>
>int *ptr;
>
>ptr = i;
>
>as far as I am aware. Shame about no asterix. Perhaps Obelix will get a
>search party together?
As long as we don't have to listen to that bard. I always liked the
name "Vitalstatistix," which I have most probably misspelt.
You've just inspired me to go to my local library and look up the
kids' section... :-)
--
Chris Mears
ICQ: 36697123
Christian Bau
> I've been following the recent threads concerning NULL pointers, and
> such, and I feel that I'm still a bit hazy on what "turns into" a null
> pointer and what does not. Mostly, my confusion is in code like this:
>
> int i = 0;
> int *ptr = i; /* hmm...is this null? */
>
> Does that make ptr into a NULL pointer? Or does it literally have to
> initialized with a constant like this:
>
> int *ptr = 0; /* now we have a null pointer? */
>
> or
>
> int *ptr = NULL;
The first example
int i = 0;
int *ptr = i;
is not legal C. i is an int, not a pointer. You cannot assign it at all.
Slightly different example:
int i = 0;
int *ptr = (int *) i;
is legal C. You cast an int to a pointer, and the result is implementation
defined. It is NOT necessarily a null pointer.
Next examples:
int *ptr = 0;
int *ptr = (void *) 0;
int *ptr = NULL;
0 and (void *) 0 are called "null pointer constants" and NULL is defined
to be either 0 or (void *) 0 so it is also a "null pointer constant".
There is a very special rule that says:
If a null pointer constant is assigned to a pointer, or compared to a
pointer with "==" or "!=", then the compiler must replace the "null
pointer constant" with a null pointer of the correct type.
So in the last three examples, the compiler will replace that line with
int *ptr = < null pointer of type int* >;
Joona I Palaste
: Slightly different example:
: int i = 0;
: int *ptr = (int *) i;
: is legal C. You cast an int to a pointer, and the result is implementation
: defined. It is NOT necessarily a null pointer.
Depends on the system used. Most home computer systems (Amiga, Linux,
Windows?...) have numerical addresses, so this simply assigns an
absolute address (in contrast of a dynamically allocated one) to the
pointer. On systems that don't have numerical addresses (like big
servers or old mainframes), this can lead to all sorts of weird errors.
(But it isn't safe to do on a numerical-address system, either!)
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #80 D+ ADA N+++ |
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"I am not very happy acting pleased whenever prominent scientists overmagnify
intellectual enlightenment."
- Anon
Richard Stamp
news:8f1p1m$83s$1...@nnrp1.deja.com...
> I've been following the recent threads concerning NULL pointers, and
> such, and I feel that I'm still a bit hazy on what "turns into" a null
> pointer and what does not. Mostly, my confusion is in code like this:
>
> int *ptr = i; /* hmm...is this null? */
I'm a bit surprised by all the discussion, because isn't this a constrant
violation?
C90 6.5.7: "The initialiser for a scalar ... the same type constraints and
conversions as for simple assignment apply."
Then C90 6.3.16.1 has, in a constraint, a list of allowable type
combinations, and pointer = int isn't one of them.
I think, however, that this doesn't answer the question flippant_squirrel
(what an excellent name) was trying to ask. The following is perfectly OK:
int *ptr1 = 0; /* or NULL */
int *ptr2 = ptr1;
if (ptr2 == NULL)
{
printf("This message must get printed.\n");
}
So ptr2 doesn't literally have to be initialised with a constant -- it can
be initialised from a variable, but there are rules about what the type of
that variable can be, which your example unfortunately fell foul of. And
the linked list code is fine, assuming you meant to write that bnode->next
is NULL rather than bnode itself.
Cheers
Richard
--
The FAQ is at http://www.eskimo.com/~scs/C-faq/top.html
New users try http://www.sin.khk.be/~emulov/c.l.c/welcome_to_clc.htm
ke...@hplb.hpl.hp.com
"Stef" <ste...@my-deja.com> writes:
> flippant...@my-deja.com wrote in message
> <8f1p1m$83s$1...@nnrp1.deja.com>...
>>such, and I feel that I'm still a bit hazy on what "turns into" a null
>>pointer and what does not. Mostly, my confusion is in code like this:
>>
>>int i = 0;
>>int *ptr = i; /* hmm...is this null? */
>>
>>
> think you meant to write:
> int *ptr;
> ptr = i; /* No asterix */
You appear to be under a misapprehension. The declaration
int *ptr = i;
is more-or-less equivalent to:
int *ptr;
ptr = i;
That is, `int *ptr = i` declares a pointer to int, and initialises it with
the *contents* of `i`, cast to pointer type.
>>int *ptr = NULL;
>>
> Same here:
> int *ptr;
> ptr = 0;
> / *or */
> ptr = NULL;
`int *ptr = NULL;` says what you want it to say, ie, make me a pointer
what is initialised to NULL; inflating it to two statements doesn't make
it more correct, nor clearer.
--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
-hs-
<099dhsgb9bqnheh3r...@4ax.com>...
>>> ptr = i; /* No asterix */
>>search party together?
>
>As long as we don't have to listen to that bard. I always liked the
>name "Vitalstatistix," which I have most probably misspelt.
>
>You've just inspired me to go to my local library and look up the
>kids' section... :-)
I'am glad to see that these French characters are so popular around the
world...
Joona I Palaste
: Chris Mears a écrit dans le message
: <099dhsgb9bqnheh3r...@4ax.com>...
:>>> ptr = i; /* No asterix */
:>>as far as I am aware. Shame about no asterix. Perhaps Obelix will get a
:>>search party together?
:>
:>As long as we don't have to listen to that bard. I always liked the
:>name "Vitalstatistix," which I have most probably misspelt.
:>
:>You've just inspired me to go to my local library and look up the
:>kids' section... :-)
: I'am glad to see that these French characters are so popular around the
: world...
Except in the USA, where the general knowledge of European cartoons is
about the same as the amount of daffodils growing on the Moon.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #80 D+ ADA N+++ |
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Normal is what everyone else is, and you're not."
- Dr. Tolian Soran
flippant...@my-deja.com
"-hs-" <email....@server.invalid> wrote:
> Steve Summit a écrit dans le message
<8f2ako$sdg$1...@eskinews.eskimo.com>...
> >In article <8f1tkm$2qfi$1...@news5.isdnet.net>, hs wrote:
> >>flippant...@my-deja.com a écrit dans le message
> >><8f1p1m$83s$1...@nnrp1.deja.com>...
> >>> I guess my main concern is that old code that I wrote for a
linked list
> >>> won't work, because there are some lines where I allowed this to
work:
> >>>
> >>> anode->next = bnode->next; /* where bnode is pointing to NULL */
> >>
> >> No doubt, this is an undefined behaviour. Anything can happen...
> >
> >I read Flippant Squirrel's post as saying that bnode->next was
> >a null pointer. In that case, of course, the assignment is
> >perfectly valid and well-behaved.
>
> What about his comment ? He said "bnode is pointing to NULL" !
>
> Obviouslly, in this conditions, the value of bnode->next is
undefined. We
> don't need another Chernobyl...
>
> -hs- "Stove"
> CLC-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> ISO-C Library: http://www.dinkum.com/htm_cl
> "Show us your source code, and let us, like
> rapacious vultures half-crazed by starvation, rip it to shreds until
> there's practically nothing left" --Richard Heathfield CLC
>
>
I messed up a bit in part of my post.
As most have pointed out, dereferencing a null pointer is indeed
undefined. I meant :
anode->next = bnode->next; /* where bnode->next is pointing to NULL */
I appreciate the extremely informative responses, and I feel I have a
very clear understanding of the entire NULL pointer fiasco. In short,
here is what I feel I understand:
int i = 0;
int *ptr = i;
This ptr assignment doesn't really make any sense, a pointer w/ all
bits 0 (or whatever the bit representation of 0 is) is not necessarily
the "NULL pointer".
Comparing NULL pointers against NULL also works because the compiler
turns the expression NULL to the appropriate value to compare against,
ie:
if (bnode->next == NULL)
The compiler generates code that compares them correctly. I am also
assuming that comparing pointers of the same type (ie, int * against
and int *) also works correctly, but that comparing pointers of
different types (char * to int *) is not guaranteed to work (since
their representation of NULL pointers could very well be different).
Functionally, NULL and 0 are not different as long as they are used in
pointer contexts, otherwise, all bets are off, as NULL can be defined
in ways that 0 cannot (ie, (void *)0).
If any of these points is flawed, I would appreciate some more
wonderful comments!
-hs-
<8f6gkg$jd9$1...@oravannahka.helsinki.fi>...
>-hs- <email....@server.invalid> scribbled the following:
>: Chris Mears a écrit dans le message
>: <099dhsgb9bqnheh3r...@4ax.com>...
>:>>> ptr = i; /* No asterix */
>:>>as far as I am aware. Shame about no asterix. Perhaps Obelix will get a
>:>>search party together?
>:>
>:>As long as we don't have to listen to that bard. I always liked the
>:>name "Vitalstatistix," which I have most probably misspelt.
>:>
>:>You've just inspired me to go to my local library and look up the
>:>kids' section... :-)
>
>: I'am glad to see that these French characters are so popular around the
>: world...
>
>Except in the USA, where the general knowledge of European cartoons is
>about the same as the amount of daffodils growing on the Moon.
U.S.A. ? Where is it ?
Marco Natoni
-hs- wrote:
> U.S.A. ? Where is it ?
<cite viz="John Lennon">
On the left of Greenland
</cite>
Best regards,
Marco
-hs-
<8f6jeu$7n6$1...@nnrp1.deja.com>...
>As most have pointed out, dereferencing a null pointer is indeed
>undefined. I meant :
>
>anode->next = bnode->next; /* where bnode->next is pointing to NULL */
This is correct : anode->next is receiving the value of bnode->next, that is
NULL.
>I appreciate the extremely informative responses, and I feel I have a
>very clear understanding of the entire NULL pointer fiasco. In short,
>here is what I feel I understand:
>
>int i = 0;
>int *ptr = i;
Despite what I have said, this should be written
int i = 0;
int *ptr = (int*)i;
>This ptr assignment doesn't really make any sense, a pointer w/ all
>bits 0 (or whatever the bit representation of 0 is) is not necessarily
>the "NULL pointer".
Yes.
>Comparing NULL pointers against NULL also works because the compiler
>turns the expression NULL to the appropriate value to compare against,
>ie:
>
>if (bnode->next == NULL)
Correct.
>The compiler generates code that compares them correctly. I am also
>assuming that comparing pointers of the same type (ie, int * against
>and int *) also works correctly, but that comparing pointers of
>different types (char * to int *) is not guaranteed to work (since
>their representation of NULL pointers could very well be different).
Yes, specially on DS9k !
>Functionally, NULL and 0 are not different as long as they are used in
>pointer contexts, otherwise, all bets are off, as NULL can be defined
>in ways that 0 cannot (ie, (void *)0).
Absolutely.
>If any of these points is flawed, I would appreciate some more
>wonderful comments!
Sounds correct to me. Wait for the peer's review.
Dave Vandervies
Marco Natoni <m.na...@kybernes.it> wrote:
>Hi -hs-,
>
>-hs- wrote:
>> U.S.A. ? Where is it ?
>
><cite viz="John Lennon">
> On the left of Greenland
></cite>
Ahem.
On *my* map, Canada is on the left of Greenland, and USA is below that.
Mistaking Canadians for Americans (or Canada for USA) is a mistake that
you probably don't want to make too often.
dave
--
Dave Vandervies dj3v...@student.math.uwaterloo.ca
I love that the net is responsible for the propagation of the ILOVEYOU worm,
according to Microsoft. In much the same manner that air is responsible for
the propagation of bullets. -D. Joseph Creighton in the Scary Devil Monastery
Nick Keighley
"-hs-" <email....@server.invalid> wrote:
> Joona I Palaste a écrit dans le message
>
> >Except in the USA, where the general knowledge of European cartoons
> >is about the same as the amount of daffodils growing on the Moon.
>
Etats Unis
:-)
--
"Perilous to us all are the devices of an art deeper than we possess
ourselves."
Gandalf The Grey (discussing Windows NT)
Marco Natoni
Dave Vandervies wrote:
>>> U.S.A. ? Where is it ?
>><cite viz="John Lennon"> On the left of Greenland </cite>
> Ahem. On *my* map, Canada is on the left of Greenland, and USA
> is below that.
Are your sure that your map is an ISO/ANSI compliant one? What you
are saying seems too map-dependent: ISO/ANSI maps do not care about
"above" and "below", since these are not portable concepts... :)
However, Lennon had said that and, all things considered, in an
"horizontal" point of view, U.S.A. are on the left of Greenland, so to
speak, on the left of Europe and Africa... :))
> Mistaking Canadians for Americans (or Canada for USA) is a
> mistake that you probably don't want to make too often.
Canadians are Americans, since they live in the continent called
America, as Paraguayans and Panamanians are. USAmericans--just
following the monetary agreement used in USDollar--are Americans too or,
better, twice (I beg your pardon for the calembour). :)))
> dj3v...@student.math.uwaterloo.ca
^^
Muble... I form the hypothesis that '.ca' stands not for California,
isn't it? :))))
Best regards,
Marco
Chris Kern
posted the following:
>Christian Bau <christ...@isltd.insignia.com> scribbled the following:
>: Slightly different example:
>
>: int i = 0;
>: int *ptr = (int *) i;
>
>: is legal C. You cast an int to a pointer, and the result is implementation
>: defined. It is NOT necessarily a null pointer.
>
>Depends on the system used.
That's what "implementation defined" means. :)
-Chris
Dave Vandervies
Marco Natoni <m.na...@kybernes.it> wrote:
>Hi Dave,
>
>Dave Vandervies wrote:
>
>> Mistaking Canadians for Americans (or Canada for USA) is a
>> mistake that you probably don't want to make too often.
>
> Canadians are Americans, since they live in the continent called
>America, as Paraguayans and Panamanians are. USAmericans--just
>following the monetary agreement used in USDollar--are Americans too or,
>better, twice (I beg your pardon for the calembour). :)))
That argument could be made; however, you won't win too many friends
among Canadians by making it. :)
>> dj3v...@student.math.uwaterloo.ca
> ^^
> Muble... I form the hypothesis that '.ca' stands not for California,
>isn't it? :))))
.ca as a top-level domain is Canada. California is .ca.us .
dave
--
Dave Vandervies dj3v...@student.math.uwaterloo.ca
Try doing it the right way. Show us your source code, and let us, like
rapacious vultures half-crazed by starvation, rip it to shreds until there's
practically nothing left. -Richard Heathfield in comp.lang.c
Gregory Pietsch
>
> Hi Dave,
>
> Dave Vandervies wrote:
> >><cite viz="John Lennon"> On the left of Greenland </cite>
> > Ahem. On *my* map, Canada is on the left of Greenland, and USA
> > is below that.
<increatingly OT>
And Alaska (a U.S. state) is to the left of Canada, and Hawaii (another
U.S. state) is in the middle of the Pacific Ocean.
>
> Are your sure that your map is an ISO/ANSI compliant one? What you
> are saying seems too map-dependent: ISO/ANSI maps do not care about
> "above" and "below", since these are not portable concepts... :)
>
> However, Lennon had said that and, all things considered, in an
> "horizontal" point of view, U.S.A. are on the left of Greenland, so to
> speak, on the left of Europe and Africa... :))
>
> > Mistaking Canadians for Americans (or Canada for USA) is a
> > mistake that you probably don't want to make too often.
>
> Canadians are Americans, since they live in the continent called
> America, as Paraguayans and Panamanians are. USAmericans--just
> following the monetary agreement used in USDollar--are Americans too or,
> better, twice (I beg your pardon for the calembour). :)))
<flame bait>
Yeah, and the British are Europeans since they're connected to the
continent by an underground isthmian link.
</flame bait>
We tend to distinguish North America from South America, even though
they're connected by an isthmus. How would you like it if I said that
Europe, Asia, and Africa are one continent, even though Africa's
connected at one or possibly two points depending on how high the water
is at the mouth of the Red Sea, and the distinction between Europe and
Asia becomes fuzzy in Istanbul, Turkey, and near the Ural River?
>
> > dj3v...@student.math.uwaterloo.ca
> ^^
> Muble... I form the hypothesis that '.ca' stands not for California,
> isn't it? :))))
Nope, it stands for Canada, The United States's wholly-owned subsidiary
nation to the north.
Later, Gregory Pietsch
>
> Best regards,
> Marco
</OT>
glen herrmannsfeldt
>flippant...@my-deja.com wrote:
>> int i = 0;
>> int *ptr = i; /* hmm...is this null? */
>this is implementation defined. while the standard says that one can
>convert an integer type into a pointer (and vice versa), it says that it's
>implementation defined as to how it works exactly.
>the answer is "usually".
I have wondered about architectures where it is not possible to look
at the value of a pointer, though it can be tested for null. Also, it
can't be assigned arbitrary int values. In this case, I believe that ALL
int values assigned will convert to a NULL pointer, and all comparisons
of a NULL pointer against an int will be true.
char *p;
p=1;
if(p==2) printf("this is funny!\n");
-- glen
glen herrmannsfeldt
Someone else wrote:
>>
>>int i = 0;
>>int *ptr = i; /* hmm...is this null? */
>This is a pointer that has been set to all-bits-to-zero. Same as:
>memset (ptr,0,sizeof ptr);
I don't see this at all. Why should a compiler do that? It could,
but there is no reason it needs to do that. If I wrote a compiler for
a machine that allowed arbitrary bit values to be assigned to pointers,
and used a non all zero bits null pointer, I would add (or xor) the
difference. This would map (int)0 to (char*)NULL reversibly.
However, the only architcture that I know of that isn't known to use
all zero bits doesn't allow one to see inside a pointer, other than to
check it for NULL. In that case, all (int) values might end up NULL.
If the compiler has to special case constant int 0's, it might as well
special case all int to pointer conversions.
-- glen
Mark McIntyre
Vandervies) wrote:
>In article <3916CCF2...@nospam.com>,
>Marco Natoni <m.na...@kybernes.it> wrote:
>>Hi -hs-,
>>
>>-hs- wrote:
>>> U.S.A. ? Where is it ?
>>
>><cite viz="John Lennon">
>> On the left of Greenland
>></cite>
>
>Ahem.
>
>On *my* map, Canada is on the left of Greenland, and USA is below that.
>
>Mistaking Canadians for Americans (or Canada for USA) is a mistake that
>you probably don't want to make too often.
Only because the citizens of the USA usurped the name of an entire
continent for themselves...
--
Mark McIntyre
C- FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Richard Heathfield
>
>
> <flame bait>
>
> Yeah, and the British are Europeans since they're connected to the
> continent by an underground isthmian link.
>
> </flame bait>
I'll bite.
You've got it exactly the wrong way around. The Europeans, by virtue of
their connection to the mainland of the British Isles via the Channel
tunnel, have become just a little bit more British, and this trend will
continue to grow apace. Don't expect any dramatic changes just yet, but
I understand that the Europeans are about to adopt a Single European
Currency - the pound.
(Hey, every rumour's got to start somewhere...)
Keith Thompson
> anode->next = bnode->next; /* where bnode->next is pointing to NULL */
What do you mean by "is pointing to NULL"? I think you mean that
bnode->next *has the value* NULL, or bnode->next has a null pointer
value.
Remember, a null pointer doesn't point to anything.
Now, if bnode->next is a pointer to a pointer, and the object it
points to is a null pointer, then the phrase "pointing to NULL" makes
sense, but I don't think that's what you meant.
--
Keith Thompson (The_Other_Keith) k...@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.
mike burrell
> On 8 May 2000 16:05:17 GMT, dj3v...@student.math.uwaterloo.ca (Dave
> Vandervies) wrote:
>>Mistaking Canadians for Americans (or Canada for USA) is a mistake that
>>you probably don't want to make too often.
> Only because the citizens of the USA usurped the name of an entire
> continent for themselves...
an entire hemisphere rather.
--
/"\ m i k e b u r r e l l
\ / ASCII RIBBON CAMPAIGN mik...@home.com
X AGAINST HTML MAIL
/ \
Selim Levy
>
> Gregory Pietsch wrote:
> >
> >
> > <flame bait>
> >
> > Yeah, and the British are Europeans since they're connected to the
> > continent by an underground isthmian link.
> >
> > </flame bait>
>
> I'll bite.
>
> You've got it exactly the wrong way around. The Europeans, by virtue of
> their connection to the mainland of the British Isles via the Channel
> tunnel, have become just a little bit more British, and this trend will
> continue to grow apace. Don't expect any dramatic changes just yet, but
> I understand that the Europeans are about to adopt a Single European
> Currency - the pound.
>
> (Hey, every rumour's got to start somewhere...)
Maybe so. But there's no better way to spread a rumour than by placing
it in your sigfile. Any objections to that?
Cheers,
Selim
--
"Although personally I am quite content with existing explosives, I feel
we must not stand in the way of improvement."
- Sir Winston Churchill, from "The Second World War" in reference to the
possibility of making a nuclear bomb
Selim Levy
>
> On 8 May 2000 16:05:17 GMT, dj3v...@student.math.uwaterloo.ca (Dave
> Vandervies) wrote:
>
> >Marco Natoni <m.na...@kybernes.it> wrote:
> >>Hi -hs-,
> >>
> >>-hs- wrote:
> >>> U.S.A. ? Where is it ?
> >>
> >><cite viz="John Lennon">
> >> On the left of Greenland
> >></cite>
> >
> >Ahem.
> >
> >On *my* map, Canada is on the left of Greenland, and USA is below that.
> >
> >you probably don't want to make too often.
>
> Only because the citizens of the USA usurped the name of an entire
> continent for themselves...
Actually, I see it rather differently. I always thought they weren't
enlightened enough to think of a country name, so they said "We got
plenty of 'em states, and they're all like friends, y'a know, so we'll
call this place the united states. Yeah, that's it, the united states
of america. Pass the moonshine, Joe."
Richard Heathfield
>
> Richard Heathfield wrote:
> >
> > (Hey, every rumour's got to start somewhere...)
>
> Maybe so. But there's no better way to spread a rumour than by placing
> it in your sigfile. Any objections to that?
FYIATOAOIP[*] I have no objections to anything I post being used in sig
blocks.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
35 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (62
to go)
*I'd better explain this one before I forget it myself. For Your
Information And That Of All Other Interested Parties...
Chris F.A. Johnson
: Hi -hs-,
: -hs- wrote:
: > U.S.A. ? Where is it ?
: <cite viz="John Lennon">
: On the left of Greenland
: </cite>
Only if you are looking north. In most respects, it's to the right of
everywhere.
--
Chris F.A. Johnson
bq...@torfree.net http://members.home.net/c.f.a.johnson
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Everything in moderation - including moderation
Chris Mears
Heathfield <bin...@eton.powernet.co.uk> wrote:
>Selim Levy wrote:
>>
>> Richard Heathfield wrote:
>> >
>> > (Hey, every rumour's got to start somewhere...)
>>
>> Maybe so. But there's no better way to spread a rumour than by placing
>> it in your sigfile. Any objections to that?
>
>FYIATOAOIP[*] I have no objections to anything I post being used in sig
>blocks.
Can we edit it profusely? Your above sentence could be:
"I have... objections to anything I post..."
"I have... objections to... 'I' being used in sig blocks."
"I have... objections to anything... being used in sig blocks."
"I have... objections to... sig blocks."
Pick one.
--
Chris Mears
ICQ: 36697123
Marco Natoni
Richard Heathfield wrote:
>> Yeah, and the British are Europeans since they're connected to
>> the continent by an underground isthmian link.
> You've got it exactly the wrong way around. The Europeans, by
> virtue of their connection to the mainland of the British Isles
> via the Channel tunnel, have become just a little bit more
> British, and this trend will continue to grow apace.
I rembember an old and short funny story: "Storm on the Channel, the
Mainland is isolated.". ;)
Best regards,
Marco
Marco Natoni
Dave Vandervies wrote:
>> Canadians are Americans, since they live in the continent
>> called America, as Paraguayans and Panamanians are.
> That argument could be made; however, you won't win too many
> friends among Canadians by making it. :)
Well, I will speak about the weather with Canadians... :)
Best regards,
Marco
Richard Heathfield
>
> On Tue, 09 May 2000 07:59:30 +0100, that hoopy frood Richard
> Heathfield <bin...@eton.powernet.co.uk> wrote:
>
> >Selim Levy wrote:
> >>
> >> Richard Heathfield wrote:
> >> >
> >> > (Hey, every rumour's got to start somewhere...)
> >>
> >> Maybe so. But there's no better way to spread a rumour than by placing
> >> it in your sigfile. Any objections to that?
> >
> >FYIATOAOIP[*] I have no objections to anything I post being used in sig
> >blocks.
>
> Can we edit it profusely?
I've saved you the trouble (two can play at this game). See below.
> Your above sentence could be:
>
> "I have... objections to anything I post..."
> "I have... objections to... 'I' being used in sig blocks."
> "I have... objections to anything... being used in sig blocks."
> "I have... objections to... Chris Mears
>
> ICQ: 36697123
>
> C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
;-)
Dan
news:3917E68E...@nospam.com...
> Hi Dave,
>
> Dave Vandervies wrote:
> >> Canadians are Americans, since they live in the continent
> >> called America, as Paraguayans and Panamanians are.
> > That argument could be made; however, you won't win too many
> > friends among Canadians by making it. :)
True...but just how many Canadian friends does one *really* need? ;-)
Dan
Dan
news:391787DC...@ms2.cc.ntu.edu.tw...
>
> Actually, I see it rather differently. I always thought they weren't
> enlightened enough to think of a country name, so they said "We got
> plenty of 'em states, and they're all like friends, y'a know, so we'll
> call this place the united states. Yeah, that's it, the united states
> of america. Pass the moonshine, Joe."
I'm always greatly amused when I see gratuitous U.S. bashing (tongue in
cheek or otherwise) expressed via this medium, which owes its very existence
(right down to the transistor) to us unenlightened barbarians ;-)
Dan
Dave Vandervies
Dan <dan.p...@sterling.com> wrote:
>
>I'm always greatly amused when I see gratuitous U.S. bashing (tongue in
>cheek or otherwise) expressed via this medium, which owes its very existence
>(right down to the transistor) to us unenlightened barbarians ;-)
>
Hmmm. If you hadn't done it, somebody else would've, and probably done
a better job of it. ;P
dave
--
Dave Vandervies
dj3v...@student.math.uwaterloo.ca
Remember, amateurs built the Ark. It was experts that built the Titanic.
Morris M. Keesan
wrote:
>flippant...@my-deja.com a écrit dans le message
><8f1p1m$83s$1...@nnrp1.deja.com>...
>>I've been following the recent threads concerning NULL pointers, and
>>such, and I feel that I'm still a bit hazy on what "turns into" a null
>>pointer and what does not. Mostly, my confusion is in code like this:
>>
>>int i = 0;
>>int *ptr = i; /* hmm...is this null? */
>
>This is a pointer that has been set to all-bits-to-zero. Same as:
>
>memset (ptr,0,sizeof ptr);
No, it's not. Once the necessary cast has been added, it's a pointer which
results from the implementation-defined conversion of int-with-value-zero to
pointer. The mapping function for this conversion is "intended to be
consistent with the addressing structure of the execution environment," but
that intention is documented only in a footnote in C90, so it's
non-normative, and in any case doesn't require an all-zero-bits integer to
convert to an all-zero-bits pointer.
>You are right : There are two ways to initialize a pointer to NULL with a
>constant:
>
>int *ptr = 0;
>int *ptr = NULL; /* include <stddef.h> */
THREE ways:
int *ptr = 0;
int *ptr = NULL;
int *ptr = (void *)0;
int *ptr = (1 - 1);
er, FOUR ways:
int *ptr = 0;
int *ptr = NULL;
int *ptr = (void *)0;
int *ptr = (1 - 1);
int *ptr = (void *)(1/2);
uh, FIVE ways:
Fear
Surprise
...
--
Morris M. Keesan -- mke...@kenan.com
Kenan Systems Corp., a wholly-owned subsidiary of Lucent Technologies
Mark McIntyre
wrote:
>Selim Levy <s810...@ms2.cc.ntu.edu.tw> wrote in message
>news:391787DC...@ms2.cc.ntu.edu.tw...
>>
>> Actually, I see it rather differently. I always thought they weren't
>> enlightened enough to think of a country name, so they said "We got
>> plenty of 'em states, and they're all like friends, y'a know, so we'll
>> call this place the united states. Yeah, that's it, the united states
>> of america. Pass the moonshine, Joe."
>
>I'm always greatly amused when I see gratuitous U.S. bashing (tongue in
>cheek or otherwise) expressed via this medium, which owes its very existence
>(right down to the transistor) to us unenlightened barbarians ;-)
Erm, and Stalin invented the tractor?
Chris Mears
Heathfield <bin...@eton.powernet.co.uk> wrote:
>Chris Mears wrote:
>>
>> On Tue, 09 May 2000 07:59:30 +0100, that hoopy frood Richard
>> Heathfield <bin...@eton.powernet.co.uk> wrote:
>>
>> >Selim Levy wrote:
>> >>
>> >> Richard Heathfield wrote:
>> >> >
>> >> > (Hey, every rumour's got to start somewhere...)
>> >>
>> >> Maybe so. But there's no better way to spread a rumour than by placing
>> >> it in your sigfile. Any objections to that?
>> >
>> >FYIATOAOIP[*] I have no objections to anything I post being used in sig
>> >blocks.
>>
>> Can we edit it profusely?
>
>I've saved you the trouble (two can play at this game). See below.
>
>> Your above sentence could be:
>>
>> "I have... objections to anything I post..."
>> "I have... objections to... 'I' being used in sig blocks."
>> "I have... objections to anything... being used in sig blocks."
>> "I have... objections to... Chris Mears
Now that's just cruel.
>;-)
:o)
--
Dan
news:8f9bjr$d2k$1...@watserv3.uwaterloo.ca...
> >cheek or otherwise) expressed via this medium, which owes its very
existence
> >(right down to the transistor) to us unenlightened barbarians ;-)
> >
>
> a better job of it. ;P
Gee...do you think our inferior implementation will ever catch on? We
barbarians have a saying: "You snooze, you lose" ;-)
Dan
Dan
news:de3hhskniv3cke7gh...@4ax.com...
> On Tue, 9 May 2000 10:20:26 -0500, "Dan" <dan.p...@sterling.com>
> wrote:
>
> >Selim Levy <s810...@ms2.cc.ntu.edu.tw> wrote in message
> >news:391787DC...@ms2.cc.ntu.edu.tw...
> >>
> >> Actually, I see it rather differently. I always thought they weren't
> >> enlightened enough to think of a country name, so they said "We got
> >> plenty of 'em states, and they're all like friends, y'a know, so we'll
> >> call this place the united states. Yeah, that's it, the united states
> >> of america. Pass the moonshine, Joe."
> >
> >cheek or otherwise) expressed via this medium, which owes its very
existence
> >(right down to the transistor) to us unenlightened barbarians ;-)
>
I'm certain there's some point being made here, but I'll be damned if I can
unearth it....
Dan
Dave Vandervies
Dan <dan.p...@sterling.com> wrote:
>Dave Vandervies <dj3v...@student.math.uwaterloo.ca> wrote in message
>news:8f9bjr$d2k$1...@watserv3.uwaterloo.ca...
>> In article <8f9abr$4d7$1...@reuters.plano.sterling.com>,
>> Dan <dan.p...@sterling.com> wrote:
>> >
>> >cheek or otherwise) expressed via this medium, which owes its very
>existence
>> >(right down to the transistor) to us unenlightened barbarians ;-)
>> >
>>
>> a better job of it. ;P
>
>Gee...do you think our inferior implementation will ever catch on? We
>barbarians have a saying: "You snooze, you lose" ;-)
Funny, I always though it was ``Better is the enemy of done''. I'm not
going to claim that I'd prefer to still be waiting for a completely
correct version, but I'd rather have seen the balance a lot more toward
`better' than it is.
dave
--
Dave Vandervies dj3v...@student.math.uwaterloo.ca
Great humans are about as wrong as lay humans, but at least they are wrong
about *important* things.
Dan
> In article <8fchoe$mas$1...@reuters.plano.sterling.com>,
> Dan <dan.p...@sterling.com> wrote:
> >Dave Vandervies <dj3v...@student.math.uwaterloo.ca> wrote in message
> >news:8f9bjr$d2k$1...@watserv3.uwaterloo.ca...
> >> In article <8f9abr$4d7$1...@reuters.plano.sterling.com>,
> >> Dan <dan.p...@sterling.com> wrote:
> >> >
> >> >I'm always greatly amused when I see gratuitous U.S. bashing (tongue
in
> >> >cheek or otherwise) expressed via this medium, which owes its very
> >existence
> >> >(right down to the transistor) to us unenlightened barbarians ;-)
> >> >
> >>
> >> Hmmm. If you hadn't done it, somebody else would've, and probably done
> >> a better job of it. ;P
> >
> >Gee...do you think our inferior implementation will ever catch on? We
> >barbarians have a saying: "You snooze, you lose" ;-)
>
> Funny, I always though it was ``Better is the enemy of done''. I'm not
> going to claim that I'd prefer to still be waiting for a completely
> correct version, but I'd rather have seen the balance a lot more toward
> `better' than it is.
Then what, pray tell, prevented you (or others) from doing something
"better"?
Dan
Dave Vandervies
Dan <dan.p...@sterling.com> wrote:
>Dave Vandervies <dj3v...@student.math.uwaterloo.ca> wrote in message
>news:8fclik$lej$1...@watserv3.uwaterloo.ca...
>> In article <8fchoe$mas$1...@reuters.plano.sterling.com>,
>> Dan <dan.p...@sterling.com> wrote:
>> >Dave Vandervies <dj3v...@student.math.uwaterloo.ca> wrote in message
>> >news:8f9bjr$d2k$1...@watserv3.uwaterloo.ca...
>> >>
>> >> a better job of it. ;P
>> >
>> >Gee...do you think our inferior implementation will ever catch on? We
>> >barbarians have a saying: "You snooze, you lose" ;-)
>>
>> Funny, I always though it was ``Better is the enemy of done''. I'm not
>> going to claim that I'd prefer to still be waiting for a completely
>> correct version, but I'd rather have seen the balance a lot more toward
>> `better' than it is.
>
>Then what, pray tell, prevented you (or others) from doing something
>"better"?
We (for values of `we' meaning `not you') were working on it, when you
came along and dumped your inferior but more quickly produced one on
us. ;P
dave
--
Dave Vandervies dj3v...@student.math.uwaterloo.ca
``In other words, if we could get rid of the lusers, things could be done
right. This isn't exactly a newsworthy discovery...''
-Chris Adams in the scary devil monastery
386sx
So why didn't yours catch on after it was finally finished? Or are you
still working on it? What's taking so long? Or is it just an empty
promise and you can't deliver your "superior" implementation?
--
The comp.lang.c FAQ:
http://www.eskimo.com/~scs/C-faq/top.html
http://www.cp-tel.net/miller/BilLee/quotes/
"In Cyberspace, the First Amendment
is a local ordinance."
- John Perry Barlow
"Prediction is extremely difficult.
Especially about the future."
- Niels Bohr
Sent via Deja.com http://www.deja.com/
Before you buy.
raw...@my-deja.com
The context is so completely lost that it is impossible to
determine who is on each side or what either side was/is
trying to implement. I'm pretty sure it's not C. Please,
please, do not explain; rather, just end this tiresome
thread now.
--
MJSR
Mark McIntyre
wrote:
>Mark McIntyre <ma...@garthorn.demon.co.uk> wrote in message
>news:de3hhskniv3cke7gh...@4ax.com...
>> On Tue, 9 May 2000 10:20:26 -0500, "Dan" <dan.p...@sterling.com>
>> wrote:
>>
>> >Selim Levy <s810...@ms2.cc.ntu.edu.tw> wrote in message
>> >news:391787DC...@ms2.cc.ntu.edu.tw...
>> >>
>> >> Actually, I see it rather differently. I always thought they weren't
>> >> enlightened enough to think of a country name, so they said "We got
>> >> plenty of 'em states, and they're all like friends, y'a know, so we'll
>> >> call this place the united states. Yeah, that's it, the united states
>> >> of america. Pass the moonshine, Joe."
>> >
>> >I'm always greatly amused when I see gratuitous U.S. bashing (tongue in
>> >cheek or otherwise) expressed via this medium, which owes its very
>existence
>> >(right down to the transistor) to us unenlightened barbarians ;-)
>>
>> Erm, and Stalin invented the tractor?
>
>I'm certain there's some point being made here, but I'll be damned if I can
>unearth it....
I was thinking of unusual claims to be the "inventor"of something.
I'm fairly sure that William Shockley and Walter Brattain would
complain about being described as "American" even if John Bardeen was
happy....
Anyway lets hand it to Tesla and Serbia, the "inventor" of AC
electricity without ...
Mark McIntyre
wrote:
>Dave Vandervies <dj3v...@student.math.uwaterloo.ca> wrote in message
>news:8fclik$lej$1...@watserv3.uwaterloo.ca...
>> In article <8fchoe$mas$1...@reuters.plano.sterling.com>,
>> Dan <dan.p...@sterling.com> wrote:
>> >Dave Vandervies <dj3v...@student.math.uwaterloo.ca> wrote in message
>> >news:8f9bjr$d2k$1...@watserv3.uwaterloo.ca...
>> >> In article <8f9abr$4d7$1...@reuters.plano.sterling.com>,
>> >> Dan <dan.p...@sterling.com> wrote:
>> >> >
>> >> >I'm always greatly amused when I see gratuitous U.S. bashing (tongue
>in
>> >> >cheek or otherwise) expressed via this medium, which owes its very
>> >existence
>> >> >(right down to the transistor) to us unenlightened barbarians ;-)
>> >> >
>> >>
>> >> Hmmm. If you hadn't done it, somebody else would've, and probably done
>> >> a better job of it. ;P
>> >
>> >Gee...do you think our inferior implementation will ever catch on? We
>> >barbarians have a saying: "You snooze, you lose" ;-)
>>
>> Funny, I always though it was ``Better is the enemy of done''. I'm not
>> going to claim that I'd prefer to still be waiting for a completely
>> correct version, but I'd rather have seen the balance a lot more toward
>> `better' than it is.
>
>Then what, pray tell, prevented you (or others) from doing something
>"better"?
We did.
Bryan Williams
Hey, look over there guys, I think if you squint you can just make out the topic
on the horizon.... :)
--
Bryan Williams
"Guns don't kill people, undefined behaviour kills people.."
Steve Summit
Sorry for the intrusion. Hey, hs: what's your e-mail address, anyway?]
In article <8f39gq$3h4$1...@news6.isdnet.net>, "-hs-"
<email....@server.invalid> writes:
>Steve Summit a écrit dans le message <8f2ako$sdg$1...@eskinews.eskimo.com>...
>>In article <8f1tkm$2qfi$1...@news5.isdnet.net>, hs wrote:
>>>flippant...@my-deja.com a écrit dans le message
>>><8f1p1m$83s$1...@nnrp1.deja.com>...
>>>> anode->next = bnode->next; /* where bnode is pointing to NULL */
>>>
>>> No doubt, this is an undefined behaviour. Anything can happen...
>>
>> I read Flippant Squirrel's post as saying that bnode->next was
>> a null pointer. In that case, of course, the assignment is
>> perfectly valid and well-behaved.
>
> What about his comment ? He said "bnode is pointing to NULL" !
Obviously he meant that the node bnode (that is, the node pointed
to by bnode) pointed to NULL (that is, had no successor, had its
next pointer set to NULL).
Steve Summit
s...@eskimo.com
-hs-
>[This reply for "-hs-" only; everyone else can safely ignore.
>Sorry for the intrusion. Hey, hs: what's your e-mail address, anyway?]
Sorry, I have no public e-mail, but I was hounoured you wanted to reach me
directly.
--
-hs- "Stove"
CLC-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
ISO-C Library: http://www.dinkum.com/htm_cl
"Show us your source code, and let us, like
rapacious vultures half-crazed by starvation, rip it to shreds until
there's practically nothing left" --Richard Heathfield CLC