In math this expression:
(a < b) && (b < c)
would be described as:
a < b < c
But why is it that in C these two expressions evaluate to something
different for the same values of a, b and c?
e.g:
for a = 0, b = 3 and c = 2:
a < b < c = 1
(a < b) && (b < c) = 0
when typed in C.
Nov 15 '05
72  4105 
Mabden wrote: "Flash Gordon" <sp**@flash-gordon.me.uk> wrote in message
news:a9************@news.flash-gordon.me.uk...
Mabden wrote:
"Netocrat" <ne******@dodo.com.au> wrote in message
news:pa****************************@dodo.com.au ...
On Fri, 21 Oct 2005 09:39:56 +0000, Mabden wrote:
>"Keith Thompson" <ks***@mib.org> wrote in message
>news:ln************@nuthaus.mib.org...
<snip>
Am I missing something?
Yes, you are missing that a null pointer *never* evaluates to true and
a
null pointer *always* evaluates to true.
Well, that helps clear it up. Let me write that down. never = always.
Got it.
That was a typo. A non-null pointer always evaluates to true. This is
obvious from the further explanation I gave.
<snip>
MAY be all zeroes, assigning a pointer to a _Bool is a "random"
operation.
The representation of pointers is *completely* irrelevant. If the bit
pattern of the null pointer is the same as the bit pattern of the int
1
it will *still* evaluate to false in a boolean context. If a non null
pointer happens to have a bit representation of all bits zero it will
*still* evaluate to true in a boolean context.
The best thing to do is completely forget that pointers even *have*
bit patterns, just treat them as opaque objects.
OK, assume that I have. What do I do with a boolean value of a pointer?
What program needs this device? Why am I turning a things that points
into a thing that is TRUE or FALSE? Is North true? Is East false? Why is
this being done?
Because that is how the C language defines it. See
http://www.eskimo.com/~scs/C-faq/q5.3.html which does not mention the
_Bool type but is talking about boolean expressions and pointers.
And why does it take 3 emails to get this question answered? Did I
stutter the first time???
People assumed, obviously erroneously, that you could do some reasoning
given a hint.
It seems to me. I'm sure I could find something Zen-like to sum this
up if I wasn't late for work.
We'll have to go with: "each state of mind not touching on things,
each step not positioned anywhere."
Zen is irrelevant to clear black and white problems of fact where
there is an absolute reference. Try reading a C text book such as K&R2
instead of relying on philosophy and you might actually stand a chance.
Zen is never irrelevant; you merely chose to ignore wisdom, and eschew
thought.
Considering Zen irrelevant to the definition of the C language,
something completely documented, give you no clue as to what I think of
Zen in other respects.
Seriously, you don't think that quote describes pointers and NULL
pointers, even a little...? :-(
That quote is to stimulate thought about the nature of certain aspects
of reality which are not clearly defined.
Are you taking into consideration that the words are from thousands of
years ago, and there may not have been as many computers in common usage
back then?!
I'm fully aware of that.
What about the fact that I only had 10 minutes to answer
your post... You wanted something about an arrow, didn't you? I'll try
to find something about an arrow.
No, I expect you to continue to make stupid posts. On the other hand, I
want you to actually try reading the relevant documentation such as the
comp.lang.c FAQ and a decent text book.
Use Zen to look at the nature of reality, use books on C to look at the
definition of C.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
"Flash Gordon" <sp**@flash-gordon.me.uk> wrote in message
news:3v************@news.flash-gordon.me.uk... Mabden wrote: "Flash Gordon" <sp**@flash-gordon.me.uk> wrote in message
news:a9************@news.flash-gordon.me.uk...Mabden wrote:
Am I missing something?
Yes, you are missing that a null pointer *never* evaluates to true
anda null pointer *always* evaluates to true.
Well, that helps clear it up. Let me write that down. never =
always. Got it.
I just had to leave that in...
<snip>
The best thing to do is completely forget that pointers even *have*
bit patterns, just treat them as opaque objects.
OK, assume that I have. What do I do with a boolean value of a
pointer? What program needs this device? Why am I turning a things that
points into a thing that is TRUE or FALSE? Is North true? Is East false?
Why is this being done?
Because that is how the C language defines it. See
http://www.eskimo.com/~scs/C-faq/q5.3.html which does not mention the
_Bool type but is talking about boolean expressions and pointers.
Ah. So you are showing me FAQ about something that doesn't actually talk
about the subject at hand, thanks for that. The part of the message the
you conviently snipped to make me look like (more of) an idiot is
reproduced here (the K lines are Keith's and the M are my own):
K> >> I was about to disagree. Fortunately, I looked it up first; you
K> >> can assign a pointer value directly to a _Bool. Interesting.
M> > What does that mean? Assign the pointer to a _Bool or the value
M> > pointed at to a _Bool? The former seems nonsensical,
The rest was snipped, but I think you get my question. I am asking why
people would be recording the TRUE and FALSE values somewhere and using
them somehow (I don't know, saving them to a file or something) - it
didn't make any sense to me.
The standard you linked to just talks about checking whether a pointer
is NULL or not. I was responding to Keith's comment. Again, why would
you assign a pointer address to a _Bool variable, and if you did
wouldn't that result change depending on the hardware / software
platform? You seem to be saying (but don't actually say) that the _Bool
variable will be TRUE for any valid pointer, well no you don't say
valid. You seem to be saying that if the pointer is set to NULL then my
variable, say Bpval, will be false. If my pointer is initialized, then
Bpval will be true. You also say that these values will be consistant
across any Standard C implementation, and it doesn't matter where NULL
is (all zeroes, some special hardware address, a random point in memory,
etc.) AND it doesn't matter if NULL is somewhere other that all-zeros,
but my pointer points to all-zeros.
You don't address the case of a pointer that has not been initialized
yet, and I suppose it might depend on whether it is a global or an
automatic variable. I'm assuming an automatic variable that is a pointer
is init'ed to all-zeros by the compiler, like all the other automatic
variables - what does the Standard say about that?
Side note:
For some reason I seem to prefer "zeroes" with an e when it stands
alone, but "zeros" when it's a compound word like "all-zeros". Hmmm...
new OT topic?...
And why does it take 3 emails to get this question answered? Did I
stutter the first time???
People assumed, obviously erroneously, that you could do some
reasoning given a hint.
Ah. Yeah. That might be a mistake. I think it is also obvious that
because some people don't like some of my posts they assume I am new at
this. I would find it hard to believe that many experts have dug into
this particular aspect of the C language.
<snip>
No, I expect you to continue to make stupid posts. On the other hand,
I want you to actually try reading the relevant documentation such as
the comp.lang.c FAQ and a decent text book.
Good assumption. Ah, homework. Doh!
Use Zen to look at the nature of reality, use books on C to look at
the definition of C.
I use various tools at various times for various reasons. I do not
actually have a copy of the Standard, so I rely on the kindness of
strangers in this regard. BTW people, if you are going to tell someone
to read the FAQ, please put a link in your post, every time. Please
don't assume the OP has the link handy on their desktop. I don't me you,
Flash, you did post a link, which I read immediately. Unfortunately, it
was not what we were talking about, but A for effort, esp. since you
think I'm an idiot. Way to go above and beyond.
--
Mabden
Mabden wrote: "Flash Gordon" <sp**@flash-gordon.me.uk> wrote in message
news:3v************@news.flash-gordon.me.uk...
Mabden wrote:
"Flash Gordon" <sp**@flash-gordon.me.uk> wrote in message
news:a9************@news.flash-gordon.me.uk...
Mabden wrote:
<snip>
Because that is how the C language defines it. See
http://www.eskimo.com/~scs/C-faq/q5.3.html which does not mention the
_Bool type but is talking about boolean expressions and pointers.
Ah. So you are showing me FAQ about something that doesn't actually talk
about the subject at hand, thanks for that. The part of the message the
Because it is relevant showing the usage of pointers in a boolean
context, including when you get true and when false.
<snip>
you conviently snipped to make me look like (more of) an idiot is
reproduced here (the K lines are Keith's and the M are my own):
K> >> I was about to disagree. Fortunately, I looked it up first; you
K> >> can assign a pointer value directly to a _Bool. Interesting.
M> > What does that mean? Assign the pointer to a _Bool or the value
M> > pointed at to a _Bool? The former seems nonsensical,
The rest was snipped, but I think you get my question. I am asking why
people would be recording the TRUE and FALSE values somewhere and using
them somehow (I don't know, saving them to a file or something) - it
didn't make any sense to me.
You were also giving clear indication of not understanding when a
pointer in a boolean context gives true and when false.
The standard you linked to just talks about checking whether a pointer
is NULL or not. I was responding to Keith's comment. Again, why would
you assign a pointer address to a _Bool variable, and if you did
wouldn't that result change depending on the hardware / software
platform?
There reason it talks about whether it is null or not is because that,
and ONLY that determines whether a pointer yeald a true or false in a
boolean context.
You seem to be saying (but don't actually say) that the _Bool
variable will be TRUE for any valid pointer, well no you don't say
valid. You seem to be saying that if the pointer is set to NULL then my
variable, say Bpval, will be false.
Because, as stated many times, it is whether the pointer is null or not
that matters.
If my pointer is initialized, then
Bpval will be true. You also say that these values will be consistant
across any Standard C implementation, and it doesn't matter where NULL
is (all zeroes, some special hardware address, a random point in memory,
etc.) AND it doesn't matter if NULL is somewhere other that all-zeros,
but my pointer points to all-zeros.
I stated in one post that it does not matter if the pointer is all bits
zero, only whether it is a null pointer or not.
You don't address the case of a pointer that has not been initialized
yet, and I suppose it might depend on whether it is a global or an
automatic variable. I'm assuming an automatic variable that is a pointer
is init'ed to all-zeros by the compiler, like all the other automatic
variables - what does the Standard say about that?
Reading the value of ANY uninitialised variable is undefined behaviour,
whether that variable is _Bool, char, int, pointer or anything else. So
literally ANYTHING can happen when you read it, whether to assign to a
_Bool or for any other purpose. You've been here long enough to have
seen this stated many times.
<snip>
And why does it take 3 emails to get this question answered? Did I
stutter the first time???
People assumed, obviously erroneously, that you could do some
reasoning given a hint.
Ah. Yeah. That might be a mistake. I think it is also obvious that
because some people don't like some of my posts they assume I am new at
this.
No, most people assume you are terminally stupid or a troll.
I would find it hard to believe that many experts have dug into
this particular aspect of the C language.
There is no digging involved. All you nead to know is the behaviour of
pointers in a boolean context and you know what happens when they are
assigned to a _Bool, because such an assignment is *obviously* a boolean
context.
<snip>
No, I expect you to continue to make stupid posts. On the other hand,
I want you to actually try reading the relevant documentation such as
the comp.lang.c FAQ and a decent text book.
Good assumption. Ah, homework. Doh!
So ready a text book.
Use Zen to look at the nature of reality, use books on C to look at
the definition of C.
I use various tools at various times for various reasons. I do not
actually have a copy of the Standard,
So search for a draft, links have been posted here plenty of times. Or
buy it for 18USD.
Or BUY A TEXT BOOK! The bulk of what you are asking will be covered in
ANY decent beginners text book.
so I rely on the kindness of
strangers in this regard. BTW people, if you are going to tell someone
to read the FAQ, please put a link in your post, every time.
If you can't be bothered to even type "comp.lang.c FAQ" in to a search
engine then why should we bother doing it for you? I have no bookmark to
the FAQ, I don't remember the URL, I get it from Google every time.
Please
don't assume the OP has the link handy on their desktop. I don't me you,
Flash, you did post a link, which I read immediately. Unfortunately, it
was not what we were talking about,
It was entirely relevant to you questioning of when you would get true
and when false. If you can't understand that even though I explained
*why* it was relevant, then you are obviously incapable of understanding.
but A for effort, esp. since you
think I'm an idiot. Way to go above and beyond.
Your score is highly negative for effort and achievement. You are either
a troll, or terminally stupid, and my starting to read your posts
again was obviously a mistake.
*PLONK*
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
"Flash Gordon" <sp**@flash-gordon.me.uk> wrote in message
news:c3************@news.flash-gordon.me.uk... Mabden wrote: "Flash Gordon" <sp**@flash-gordon.me.uk> wrote in message
news:3v************@news.flash-gordon.me.uk...
Mabden wrote:
"Flash Gordon" <sp**@flash-gordon.me.uk> wrote in message
news:a9************@news.flash-gordon.me.uk...
>Mabden wrote:
Because it is relevant showing the usage of pointers in a boolean
context, including when you get true and when false.
OK, I understand when they are true and false. You keep going back to
that. I am NOT confused about that. I'm not sure what I'm saying that
makes you keep repeating the same statements over and over.
<snip>
you conviently snipped to make me look like (more of) an idiot is
reproduced here (the K lines are Keith's and the M are my own):
K> >> I was about to disagree. Fortunately, I looked it up first;
you K> >> can assign a pointer value directly to a _Bool. Interesting.
M> > What does that mean? Assign the pointer to a _Bool or the value
M> > pointed at to a _Bool? The former seems nonsensical,
The rest was snipped, but I think you get my question. I am asking
why people would be recording the TRUE and FALSE values somewhere and
using them somehow (I don't know, saving them to a file or something) - it
didn't make any sense to me.
You were also giving clear indication of not understanding when a
pointer in a boolean context gives true and when false.
Well I didn't mean to. The question, as stated about three or four times
above and below, is why would you would write the boolean value to a
variable. I was wondering what the use was to "assign a pointer value
directly to a _Bool". What does one do with this information at a later
time, that wouldn't be better done by examining the actual pointer
itself? What practical reason, I mean, not just as a homework question.
For instance:
_Bool EndOfString (char *p)
{
_Bool bpVal=false;
while (*p != '\0')
bpVal = p++; /* flag if p becomes null?! WTF? */
return bpVal; /* return "the end of the string was once pointed to" flag
*/
}
Note on above: nothing about pointing to null.
There reason it talks about whether it is null or not is because that,
and ONLY that determines whether a pointer yeald a true or false in a
boolean context.
Avoiding the question to lecture about null pointers, again.
Because, as stated many times, it is whether the pointer is null or
not that matters.
And again.
I stated in one post that it does not matter if the pointer is all
bits zero, only whether it is a null pointer or not.
Didn't I just repeat that back to you? I'm trying to say what I
understand you to be saying, in the hopes that you will get that I
understand what you are saying. So stop repeating it over and over.
> I would find it hard to believe that many experts have dug into
this particular aspect of the C language.
There is no digging involved. All you nead to know is the behaviour of
pointers in a boolean context and you know what happens when they are
assigned to a _Bool, because such an assignment is *obviously* a
boolean context.
And then what does one DO with the variable? If you want to test the
pointer, you would test the pointer. By assigning to the boolean
variable you get to know that a pointer was once null, but you don't
have the pointer so how does that help? Why would you pass around a
variable that told you that a pointer was once valid and pointing to
something, since the pointer may have been moved by the time you check
the boolean variable?
*PLONK*
Oh good, no more pedantic hyperbole.
--
Mabden
On Mon, 24 Oct 2005 07:18:45 +0000, Mabden wrote: [W]hy would you would write the boolean value [of a pointer] to
a variable[?]
Here's a contrived snippet (not compilable or verified correct):
#include <stdbool.h>
_Bool demofunc(char **argv) /* final member of argv array is NULL */
{
_Bool ret;
char **argp = argv;
/* do something with argp */
...
/* store whether argp ended on final array member */
ret = argp;
/* reset argp and do something else with it */
argp = argv;
...
return ret; /* or otherwise utilise the value of ret */
}
-- http://members.dodo.com.au/~netocrat
"Netocrat" <ne******@dodo.com.au> wrote in message
news:pa****************************@dodo.com.au... On Mon, 24 Oct 2005 07:18:45 +0000, Mabden wrote:
[W]hy would you would write the boolean value [of a pointer] to
a variable[?]
Here's a contrived snippet (not compilable or verified correct):
Thank you for your help.
#include <stdbool.h>
_Bool demofunc(char **argv) /* final member of argv array is NULL */
{
_Bool ret;
char **argp = argv;
/* do something with argp */
...
/* store whether argp ended on final array member */
ret = argp;
/* reset argp and do something else with it */
argp = argv;
...
return ret; /* or otherwise utilise the value of ret */
}
Why? "utilize the value of ret" how? By your own code, argp is now
pointing somewhere else. ret is merely providing the information that a
pointer once pointed to something, without the pointer itself or any tie
to the pointer to say whether it is still pointing to anything, and, if
it is an INVALID, UNITITIALIZED pointer - it's probably still going to
be "true" except on SOME machines or compilers where it may NOT be true.
Sometimes. And global pointer may have differences than automatic
variables (in functions).
Didn't you see my example:
_Bool EndOfString (char *p)
{
_Bool bpVal=false;
while (*p != '\0')
bpVal = p++; /* flag if p becomes null?! WTF? */
return bpVal; /* return "the end of the string was once pointed to" flag
*/
}
I'm not saying code can't be written. I just can't see why anyone would.
Why not pass around the actual pointer.
What value does this actually have in Real Life?!!! Has ANYONE even /
ever done this?? Can you think of ANY reason to do this that wouldn't be
a Bad Idea?!
--
Mabden
On Mon, 24 Oct 2005 13:00:58 +0000, Mabden wrote: "Netocrat" <ne******@dodo.com.au> wrote in message
news:pa****************************@dodo.com.au... On Mon, 24 Oct 2005 07:18:45 +0000, Mabden wrote:
> [W]hy would you would write the boolean value [of a pointer] to
> a variable[?]
Here's a contrived snippet (not compilable or verified correct):
Thank you for your help.
#include <stdbool.h>
_Bool demofunc(char **argv) /* final member of argv array is NULL */
{
_Bool ret;
char **argp = argv;
/* do something with argp */
...
/* store whether argp ended on final array member */
ret = argp;
/* reset argp and do something else with it */
argp = argv;
...
return ret; /* or otherwise utilise the value of ret */
}
Why? "utilize the value of ret" how?
Read the code, use your imagination and [insert appropriate Zen saying of
your preference].
By your own code, argp is now pointing somewhere else.
Right - that's the whole point - you wanted a situation where one couldn't
simply use the value of the pointer. This is such a situation: the
pointer's value is now different so we can't use it anymore.
ret is merely providing the information that
a pointer once pointed to something,
More importantly, it indicates whether the initial processing block
reached the end of the array (false) or not (true).
[...]
-- http://members.dodo.com.au/~netocrat
Mabden wrote: "Netocrat" <ne******@dodo.com.au> wrote in message
news:pa****************************@dodo.com.au...
On Mon, 24 Oct 2005 07:18:45 +0000, Mabden wrote:
[W]hy would you would write the boolean value [of a pointer] to
a variable[?]
Here's a contrived snippet (not compilable or verified correct):
Thank you for your help.
#include <stdbool.h>
_Bool demofunc(char **argv) /* final member of argv array is NULL */
{
_Bool ret;
char **argp = argv;
/* do something with argp */
...
/* store whether argp ended on final array member */
ret = argp;
/* reset argp and do something else with it */
argp = argv;
...
return ret; /* or otherwise utilise the value of ret */
}
Why? "utilize the value of ret" how? By your own code, argp is now
pointing somewhere else. ret is merely providing the information that a
pointer once pointed to something, without the pointer itself or any tie
to the pointer to say whether it is still pointing to anything, and, if
it is an INVALID, UNITITIALIZED pointer - it's probably still going to
be "true" except on SOME machines or compilers where it may NOT be true.
Sometimes. And global pointer may have differences than automatic
variables (in functions).
Didn't you see my example:
_Bool EndOfString (char *p)
{
_Bool bpVal=false;
while (*p != '\0')
bpVal = p++; /* flag if p becomes null?! WTF? */
return bpVal; /* return "the end of the string was once pointed to" flag
*/
}
I'm not saying code can't be written. I just can't see why anyone would.
Why not pass around the actual pointer.
What value does this actually have in Real Life?!!! Has ANYONE even /
ever done this?? Can you think of ANY reason to do this that wouldn't be
a Bad Idea?!
_Bool success = true;
success = isBla(.....) && success;
success = isBlub(....) && success;
pFoo = getFoo();
if (success = pFoo && success)
{
....
}
.....
return success;
for your arbitrary company's SESE policy. Or whatever.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
"Michael Mair" <Mi**********@invalid.invalid> wrote in message
news:3s************@individual.net... Mabden wrote: "Netocrat" <ne******@dodo.com.au> wrote in message
news:pa****************************@dodo.com.au...
I'm not saying code can't be written. I just can't see why anyone
would. Why not pass around the actual pointer.
What value does this actually have in Real Life?!!! Has ANYONE even
/ ever done this?? Can you think of ANY reason to do this that
wouldn't be a Bad Idea?!
_Bool success = true;
success = isBla(.....) && success;
success = isBlub(....) && success;
pFoo = getFoo();
if (success = pFoo && success)
{
....
}
....
return success;
for your arbitrary company's SESE policy. Or whatever.
OK, good answer Michael. Thank you for understanding my question.
At first glance I thought you had missed the point (so to speak), as I
thought the = in the if() was a typo. The code doesn't look like
"natural C" to me, however, and I doubt I would code it that way. Plus,
the compiler is going to scold you. ;-)
Note that your "success" is determined by pFoo not being equal to null.
I still have a question as to whether an automatic pointer (in a
function, initialized by the compiler) is set to all-bits-zero or to the
address of NULL (void *(0)). If pointers are init'ed to zero as other
automatic variables are in a function, and NULL points to somewhere else
in memory aren't they different?
I'm going to give an example as I keep getting "answers" that miss the
point, so sorry if you understand and this bores you - it bores me more
to try to explain my point a thousand times over, but here goes:
NULL is a pointer to a zero in memory at 0x11112222.
My function has a pointer that gets initialized automagically. I don't
know whether it gets init'ed to NULL (0x11112222) or all-zeros
(0x00000000). What does The Standard say?
Now, if the automatic pointer is actually init'ed to NULL, then there is
no problem that I can see.
IFF it is the second case of 0x00000000, then it seems to me that
0x00000000 != 0x11112222. Does that seem reasonable? In this case,
assigning the 0x00000000 to a _Bool would seem, to me, to produce a
false since it is not NULL. This is what I was saying to Flash that
turned into a lecture about NULL not being all-zeros (which is the point
I was actually making).
If they are different, and your getFoo() returns a pointer that is not
NULL, but is all-bits-zero then wouldn't storing that pointer in a _Bool
variable give a false value? I believe it should, since 0x00000000 !=
0x11112222, and 0x00000000 may be a valid address in this memory space
on some hardware / software combo.
However, if you used the actual pointer you would write code like this:
pFoo = getFoo();
if (pFoo && success)
{
/* actually do something with pFoo, since you went and got it... */
return true; /* or return success; */
}
else return false;
Now my understanding is that the if() would work in both cases of pFoo
being NULL or pFoo being all-zeros, is that correct? If so, then using a
boolean variable to store the value of a pointer would seem like a Bad
Idea.
Am I the only one not understanding this?
p.s. I'm not familiar with the term SESE, and neither is my acronym
dictionary at http://www.ucc.ie/cgi-bin/uncgi/acronym
What does it mean, and does anyone have a better acronym dictionary?
p.p.s. Please, please, please don't reply that NULL does not have to be
all-zeros...
--
Mabden
Mabden wrote: p.s. I'm not familiar with the term SESE, and neither is my acronym
dictionary at
http://www.ucc.ie/cgi-bin/uncgi/acronym
What does it mean, and does anyone have a better acronym dictionary?
Single entry, single exit, thus a Boolean to capture the success.
Gotta run
-Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
On Tue, 25 Oct 2005 01:38:23 +0000, Mabden wrote: [...] I still have a question as to whether an automatic pointer (in a
function, initialized by the compiler) is set to all-bits-zero or to the
address of NULL (void *(0)).
Neither - automatic variables are not initialised by the compiler. But
when a static global pointer variable is initialised, the compiler sets it
to NULL, not all-bits-zero (unless that also happens to be the
representation of NULL).
Better than referring to NULL as an "address" (it doesn't actually refer
to any valid memory location) is to term it a "representation".
[...] NULL is a pointer to a zero in memory at 0x11112222. My function has a
pointer that gets initialized automagically. I don't know whether it
gets init'ed to NULL (0x11112222) or all-zeros (0x00000000). What does
The Standard say?
To repeat: NULL (0x11112222).
Minor quibble with your phrasing: "a pointer to a zero in memory at" would
be better written "represented by the bit-pattern of the number"
Now, if the automatic pointer is actually init'ed to NULL, then there is
no problem that I can see.
Good, that makes (at least) two of us.
[...]
-- http://members.dodo.com.au/~netocrat
There's an entire chapter of the FAQ dedicated to this stuff people! ;)
Netocrat wrote: On Tue, 25 Oct 2005 01:38:23 +0000, Mabden wrote: [...] I still have a question as to whether an automatic pointer (in a
function, initialized by the compiler) is set to all-bits-zero or to
the address of NULL (void *(0)).
Neither - automatic variables are not initialised by the compiler. But
when a static global pointer variable is initialised, the compiler sets
it to NULL,
The initial value of an uninitialised static duration pointer is a null
pointer.
not all-bits-zero (unless that also happens to be the
representation of NULL).
NULL does not have a representation, it's a macro which expands to an
implementation defined null pointer constant. It may even expand to
something like __null.
Better than referring to NULL as an "address" (it doesn't actually refer
to any valid memory location) is to term it a "representation".
IMO, it's better to talk about null pointers and null pointer
constants.
NULL and 0 (et al) are syntactic symbolism.
But, when talking about null pointers, it's worth remembering that
there
may be more than one representation, although they will compare equal.
--
Peter
On Mon, 24 Oct 2005 22:16:20 -0700, Peter Nilsson wrote: Netocrat wrote:
Better than referring to NULL as an "address" (it doesn't actually
refer to any valid memory location) is to term it a "representation".
IMO, it's better to talk about null pointers and null pointer constants.
NULL and 0 (et al) are syntactic symbolism.
Yes, that's even better.
But, when talking about null pointers, it's worth remembering that there
may be more than one representation, although they will compare equal.
Point taken.
-- http://members.dodo.com.au/~netocrat
Michael Mair <Mi**********@invalid.invalid> wrote: Mabden wrote: p.s. I'm not familiar with the term SESE, and neither is my acronym
dictionary at
http://www.ucc.ie/cgi-bin/uncgi/acronym
What does it mean, and does anyone have a better acronym dictionary?
As for the latter: <http://www.acronymfinder.com/>. It knows SESE.
Single entry, single exit,
This is correct, but...
thus a Boolean to capture the success.
....this doesn't follow. The single exit can easily be an int, or a
pointer. Or even a struct, though that is, of course, cheating. WHat
Mabden described is even more strict than a normal SESE policy.
Richard
"Netocrat" <ne******@dodo.com.au> wrote in message
news:pa****************************@dodo.com.au... On Mon, 24 Oct 2005 22:16:20 -0700, Peter Nilsson wrote: Netocrat wrote: Better than referring to NULL as an "address" (it doesn't actually
refer to any valid memory location) is to term it a
"representation".
IMO, it's better to talk about null pointers and null pointer
constants. NULL and 0 (et al) are syntactic symbolism.
Yes, that's even better.
But, when talking about null pointers, it's worth remembering that
there may be more than one representation, although they will compare
equal.
Point taken.
OMFG! I can't believe you guys. In post post script I specifically asked
not to go there.
"p.p.s. Please, please, please don't reply that NULL does not have to be
all-zeros..."
I am NOT talking about NULL, where NULL resides, or any other topic
about NULL or null or _null or anything like that. Did you look at the
code - no references to null.
One question is what are automatic variables in a function (not static)
initialized to according to the Standard?
Nothing there about global variables. Nothing about static variables.
I'm asking the hard questions. Sorry, kiddies.
--
Mabden
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:43***************@news.xs4all.nl... Michael Mair <Mi**********@invalid.invalid> wrote:
Mabden wrote: p.s. I'm not familiar with the term SESE, and neither is my
acronym dictionary at
http://www.ucc.ie/cgi-bin/uncgi/acronym
What does it mean, and does anyone have a better acronym
dictionary?
As for the latter: <http://www.acronymfinder.com/>. It knows SESE.
Single entry, single exit,
Noted.
This is correct, but...
thus a Boolean to capture the success.
...this doesn't follow. The single exit can easily be an int, or a
pointer. Or even a struct, though that is, of course, cheating. WHat
Mabden described is even more strict than a normal SESE policy.
I studied Meyers and such when we coded badly. You HAD to make some
rules! SESE was a first step to stem the tide. Later, languages that
didn't use goto's were invented and functions were created. At that
point it became obvious that it was OK to leave a function from many
points. The problem was jumping in to the middle. SESE was about gotos.
And the code that was posted to show my why we would use booleans to
store pointers was about as old of an idea. I guess that's why it looked
both familiar, and wrong.
Jumping into and out of "functions" or "subroutines". Nah - they were
just lines of code. People went mad! Mad, I tell you! I was pure chaos.
We did things to code you can't imagine - overlaying code with data
because a bit -ONE BIT - was flipped! This memory means this, unless
this bit is on then it is an entirely different record. But check this
other bit to see of it is data or a new subroutine. If it is a new
subroutine, check byte 7-14 for the offset of the start of the
subroutine. Oh, and make sure you put back the original data when you
are done. Can you say "cleanup on aisle 3!"?
Ahhhh... the good old days. We burned with the FIRE in those days.
Compiles took HOURS, my friend - you THOUGHT about what you wrote!
Chaos! Core dumps! Ties! Madness, I tell you!
I cannot speak any more... the madness comes, it comes!!!
--
Mabden
On Tue, 25 Oct 2005 08:58:05 +0000, Mabden wrote: "Netocrat" <ne******@dodo.com.au> wrote in message
news:pa****************************@dodo.com.au... On Mon, 24 Oct 2005 22:16:20 -0700, Peter Nilsson wrote: > Netocrat wrote: >> Better than referring to NULL as an "address" (it doesn't actually
>> refer to any valid memory location) is to term it a
>> "representation".
>
> IMO, it's better to talk about null pointers and null pointer
> constants. NULL and 0 (et al) are syntactic symbolism.
Yes, that's even better.
> But, when talking about null pointers, it's worth remembering that
> there may be more than one representation, although they will compare
> equal.
Point taken.
OMFG! I can't believe you guys. In post post script I specifically asked
not to go there.
"p.p.s. Please, please, please don't reply that NULL does not have to be
all-zeros..."
There are other readers of the newsgroup than yourself. Your use of
terminology was poor and deserved correction. Peter was right to improve
my correction.
In any case where do you see the statement in your p.p.s made? (it
isn't).
[...] One question is what are automatic variables in a function (not static)
initialized to according to the Standard?
Which I answered:
"...automatic variables are not initialised by the compiler."
That could be worded better: according to the Standard, the initial value
of an automatic variable is indeterminate.
[...] I'm asking the hard questions. Sorry, kiddies.
You're asking the FAQs. Read the relevant section first if you intend to
post again.
-- http://members.dodo.com.au/~netocrat
"Mabden" <mabden@sbc_global.net> writes:
[...] One question is what are automatic variables in a function (not static)
initialized to according to the Standard?
They aren't implicitly initialized to anything.
Have you considered getting a copy of the standard? Or at least a
draft (Google "n1124.pdf")?
--
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.
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org... "Mabden" <mabden@sbc_global.net> writes:
[...] One question is what are automatic variables in a function (not
static) initialized to according to the Standard?
They aren't implicitly initialized to anything.
I'm going to take that as including pointers. Please tell me if pointers
are a specific case.
I thought they are zeroed. Is it globals that are zeroed? I always
initialize anything I use, so I never really think about it.
OK, but you are making my point. The pointer is uninitialized. It
contains random bits. It may contain all-zeros for all we know. There is
no way to know. Hence random. Assign it to a _Bool and you don't know
what it will be.
Have you considered getting a copy of the standard? Or at least a
draft (Google "n1124.pdf")?
Nope. My code works great, thanks. I just "do it right" and I don't have
trouble with issues that are Standard minutia. In my view, when your
code falls into the realm of something Madben is talking about on c.l.c,
then you are a barbarian. ;-0
--
Mabden
Richard Bos wrote: Michael Mair <Mi**********@invalid.invalid> wrote:
Mabden wrote:
p.s. I'm not familiar with the term SESE, and neither is my acronym
dictionary at
http://www.ucc.ie/cgi-bin/uncgi/acronym
What does it mean, and does anyone have a better acronym dictionary?
As for the latter: <http://www.acronymfinder.com/>. It knows SESE.
Single entry, single exit,
This is correct, but...
thus a Boolean to capture the success.
...this doesn't follow. The single exit can easily be an int, or a
pointer. Or even a struct, though that is, of course, cheating. WHat
Mabden described is even more strict than a normal SESE policy.
Sorry, I did not quote enough context as I was in a hurry :-/
I meant this in the context of the, alas, unquoted example.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Mabden wrote: K>>> I was about to disagree. Fortunately, I looked it up first; you
K>>> can assign a pointer value directly to a _Bool. Interesting.
M>> What does that mean? Assign the pointer to a _Bool or the value
M>> pointed at to a _Bool? The former seems nonsensical,
The rest was snipped, but I think you get my question. I am asking why
people would be recording the TRUE and FALSE values somewhere and using
them somehow...
You're right, they probably wouldn't be. The assignment
arguably *doesn't* make much sense. The Standard gives it a
meaning, and it's the correct meaning under the circumstances,
but if you don't like it, don't use it.
The standard you linked to just talks about checking whether a pointer
is NULL or not.
Correct. That's just about the only clear-cut, unambiguous
distinction there is.
Again, why would you assign a pointer address to a _Bool variable,
and if you did wouldn't that result change depending on the hardware /
software platform?
No, the result would not change.
You seem to be saying (but don't actually say) that the _Bool
variable will be TRUE for any valid pointer, well no you don't say
valid.
Right. Key distinction.
You seem to be saying that if the pointer is set to NULL then my
variable, say Bpval, will be false.
Right.
If my pointer is initialized, then Bpval will be true.
Right again.
You also say that these values will be consistant across any Standard
C implementation, and it doesn't matter where NULL is (all zeroes,
some special hardware address, a random point in memory, etc.)
Right, right, right.
You don't address the case of a pointer that has not been initialized
yet,
That's the tricky case.
At the level we're talking about here, there are really three
kinds of pointer values:
0. Null (and hence invalid) pointers.
1a. Non-null, initialized, valid pointers.
1b. Non-null invalid pointers.
All null pointers are invalid, but not all non-null pointers are
valid. If a pointer is null, it is guaranteed to be invalid, but
if a pointer is non-null, you can't always be sure that it's
valid. The conditionals
if(p != NULL)
and the "shorthand"
if(p)
test merely for non-null pointers; they do *not* necessarily test
for valid pointers.
Here is a code fragment illustrating the three cases:
int i = 0;
int *ip0 = NULL;
int *ip1a = &i;
int *ip1b = (int *)0xdeadbeef;
printf("ip0 is %sNULL\n", ip0 != NULL ? "non-" : "");
printf("ip1a is %sNULL\n", ip1a != NULL ? "non-" : "");
printf("ip1b is %sNULL\n", ip1b != NULL ? "non-" : "");
Both ip1a and ip1b are non-NULL. If you inspect the value of
*ip1a or try to set it to something else:
*ip1b = 42;
it will work. If you try to do anything with *ip0 or *ip1b it
will almost certainly fail.
and I suppose it might depend on whether it is a global or an
automatic variable. I'm assuming an automatic variable that is
a pointer is init'ed to all-zeros by the compiler, like all the
other automatic variables - what does the Standard say about that?
Well, for one thing, it's the other way around. "Global"
(really, static-duration) variables are automatically initialized
to 0, which is to say, as if the programmer had written something
like "= 0". So global pointer variables are guaranteed to start
out as null pointers. It's the automatic variables which, if the
programmer doesn't explicitly initialize them, contain garbage.
Has anyone pointed you at the comp.lang.c FAQ list yet?
It covers a lot of this.
It's useful to adopt a programming style in which "case 1b" never
occurs. If you always initialize pointers to NULL or to the
address of some valid storage (perhaps by calling malloc), and if
you always set pointers to NULL when they become invalid (such as
when you call free), then, by convention, you *can* use
if(p != NULL)
to test for valid pointers. But the Standard C language doesn't
guarantee (by itself) that this will work; you need to augment
the Standard (so to speak) with your own programming standard if
you're going to get away with this.
BTW people, if you are going to tell someone to read the FAQ,
Ah. Someone did point it out.
please put a link in your post, every time. Please don't assume
the OP has the link handy on their desktop.
It really isn't that hard to find. For example, you can enter
"C FAQ" or "comp.lang.c FAQ" into google, press the "I'm Feeling
Lucky" button, et voilą, there you are.
--
Steve Summit sc*@eskimo.com
Steve Summit said: It really isn't that hard to find. For example, you can enter
"C FAQ" or "comp.lang.c FAQ" into google, press the "I'm Feeling
Lucky" button, et voilą, there you are.
Steve - <http://www.eskimo.com/~scs/C-FAQ/top.html> is mildly out of date
compared to the ASCII version <ftp://ftp.eskimo.com/u/s/scs/C-faq/faq.gz> -
do you have any plans to copy the changes into the HTML version?
I am by no means the most dynamic of site updaters myself, so this is not a
nag, merely an enquiry!
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Mabden wrote: "Keith Thompson" wrote in message
news:ln************@nuthaus.mib.org... "Mabden" <mabden@sbc_global.net> writes: One question is what are automatic variables in a function
(not static) initialized to according to the Standard?
They aren't implicitly initialized to anything.
I'm going to take that as including pointers.
Correct.
Please tell me if pointers are a specific case.
No, they are not a special case; they're not implicitly
initialized to anything, either.
I thought they are zeroed.
You thought wrong.
Is it globals that are zeroed?
Yes.
OK, but you are making my point. The pointer is uninitialized.
It contains random bits. It may contain all-zeros for all we know.
There is no way to know. Hence random. Assign it to a _Bool and
you don't know what it will be.
The way to think about pointer-assigned-to-bool, I think, is that
for any expression e, of any type, the assignment
bool b;
b = e;
gets you, in b, the same answer you would have gotten if you had
said
if(e) b = true; else b = false;
Now, it's true, if you compute this condition e, assign it to b,
and then look at b later -- that is, whenever you do something like
bool b = e;
/* ...then some other stuff happens... */
if(b)
the underlying condition might have changed out from under you
in the meantime. But that's true whether or not e involves a
pointer. The pointer might no longer be non-null, the file might
not still not exist, the pod bay doors might not still be open.
That's why "caching" a boolean (or any!) value in this way is
always at least somewhat risky, if not a downright bad idea.
But then again, of course, sometimes there's a good reason to do
it, and you usually can, if you're suitably careful.
If anyone is at all surprised by my transformation of
b = e;
into
if(e) b = true; else b = false;
, don't be. There's nothing magical here.
It's also equivalent to
b = (e ? true : false);
It's also equivalent to
b = (e != 0);
And, coming full circle, slapping "!= 0" next to an expression
is, in effect, what the compiler always does whenever you write
if(e)
That's why
if(ptr)
works, and why it's 100% functionally equivalent to
if(ptr != NULL)
, and why it's perfectly portable and reliable and safe to use,
no matter what the underlying representation of a null pointer is.
As the FAQ list points out, the correct interpretation of
if(ptr)
or
if(ptr != 0)
does not involve converting the pointer into an integer; it
involves converting the constant integer 0 into a null pointer
constant, and comparing against that.
--
Steve Summit sc*@eskimo.com This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: DrTebi |
last post by:
Hello,
I have the following problem:
I used to "encode" my email address within links, in order to avoid (most)
email spiders. So I had a link like this:
<a...
|
by: Christian Schmidbauer |
last post by:
Hello!
I prepare my XML document like this way:
-------------------------------------------------------
PrintWriter writer;
Document domDocument;
Element domElement;
// Root tag
|
by: Diandian Zhang |
last post by:
Does anyone have an idea, how to do it? Thanks in advance!
|
by: H. S. |
last post by:
Hi,
I am trying to compile these set of C++ files and trying out class
inheritence and function pointers. Can anybody shed some light why my
compiler is not compiling them and where I am going...
|
by: andrew007 |
last post by:
I do xml / xslt transformation using asp.net but I found
any value (w/xml format) in xml node html-encoded to < and > format if
it's > or < tag.
Since I have sub xml data in a parent xml node...
|
by: Jon Noring |
last post by:
Out of curiosity, may a CDATA section appear within an attribute
value with datatype CDATA? And if so, how about other attribute
value datatypes which accept the XML markup characters?
To me,...
|
by: Filipe Sousa |
last post by:
Hi!
Could someone explain to me why this operation is not what I was expecting?
int main()
{
int x = 2;
std::cout << x << " " << x++ << std::endl;
return 0;
}
|
by: Arne |
last post by:
A lot of Firefox users I know, says they have problems with validation
where the ampersand sign has to be written as & to be valid. I don't
have Firefox my self and don't wont to install it only...
|
by: Steven.Xu |
last post by:
hi everybody,
i am useing some classes which in System.Xml to deal with xml document. what
can i do if the document include "<" or ">"?
Thanks.
|
by: ismailc |
last post by:
Hi, I need help please.
Update system to to new version & moved on to .Net2
But now my code that worked in my .Net1 xslt does not work.
.Net1 fine:
<xsl:stylesheet...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
