473,320 Members | 2,029 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

compare a large number of variables

Hi,

I wonder if there is a nice bit twiddling hack to compare a large
number of variables?

If you first store them in an array, you can do:

for (i = 0; i < n; i++) {
if (array[i] != value) {
/* array[i] differs from value, do something*/
}
}

but I dont have the variables in an array, and would like to figure out
a nice oneliner.

best regards.
E.

Nov 15 '05
122 5161
Keith Thompson <ks***@mib.org> wrote:
Tim Rentsch <tx*@alumnus.caltech.edu> writes:
To get the other reading, hyphenate: "(null pointer) constant"
should be written "null-pointer constant".

I'm not saying Keith's statement is wrong, only that it doesn't
agree with the usage rule that I was taught.

</OTish>


Ok, I see your point. My parsing of the phrase "null pointer
constant" was influenced by knowing what the term actually means.

But "easy programming manuals", whether they're programming manuals
that are easy or manuals about easy programming, are manuals. They
aren't programming.

A null pointer constant, whether it's a pointer constant that's null
or a constant for a null pointer, is a constant; it's not a pointer.


What's more, TTBOMK there are no other pointer constants; a "non-null
(pointer constant)" doesn't even exist, so the parse "null (pointer
constant)" is spurious and the parse "(null pointer) constant" is, to
me, the obvious one.

Richard
Nov 15 '05 #101
Richard Bos wrote:
Keith Thompson <ks***@mib.org> wrote:

....
Ok, I see your point. My parsing of the phrase "null pointer
constant" was influenced by knowing what the term actually means.

But "easy programming manuals", whether they're programming manuals
that are easy or manuals about easy programming, are manuals. They
aren't programming.

A null pointer constant, whether it's a pointer constant that's null
or a constant for a null pointer, is a constant; it's not a pointer.


What's more, TTBOMK there are no other pointer constants; a "non-null
(pointer constant)" doesn't even exist, so the parse "null (pointer
constant)" is spurious and the parse "(null pointer) constant" is, to
me, the obvious one.


Since the standard assigns no special meaning to the term "pointer
constant", we're supposed to use ordinary rules of english usage to
interpret it. In the constext of the C standard, it has a meaning that
seems clear, obvious, and unambiguous to me (YMMV): a constant
expression with pointer type. In other words, it's essentially
synonymous with what the standard calls an "address constant". If it
weren't for the fact that the standard does provide a definition of
"null pointer constant", the obvious (to me) interpretation would be "a
constant expression with a pointer type and a null value"; which is NOT
how the standard defines it.

Nov 15 '05 #102
Tim Rentsch wrote:

Dietmar Schindler <dS***@arcor.de> writes:
Tim Rentsch wrote:

Dietmar Schindler <dS***@arcor.de> writes: [snip] > 3.17.2
> 1 indeterminate value
> either an unspecified value or a trap representation
>
> Since even a trap representation is a value (however indeterminate), I
> can't see how any given representation can not be a value.

Defined terms like this one are meant to be read as a single
indivisible unit. For example, 3.7.1 p1 defines "character"
as "single-byte character" or "<C> bit representation that
fits in a byte". In 3.7.2 p1, "multibyte character" is
defined as "sequence of one or more bytes representing a
member of the extended character set of either the source or
the execution environment." A "multibyte character" needn't
be a "character" in the sense of 3.7.1 p1. Nor in the sense
of 3.7: multibyte characters represent abstract characters,
but they are not actual characters - they are sequences of
bytes. Also, note that a multibyte character may be only
one byte long, so it need not be "multibyte".
Your example seemed convincing to me at first, but unfortunately it
turned out not to be. You say "multibyte characters represent abstract
characters". I see that as compelling evidence that

3.7
1 character
<abstract> member of a set of elements used for the organization,
control, or representation of data

very well is the definition that applies to the sense in which it is
used in the term "multibyte character". So, a "multibyte character" is a
character (in the sense of 3.7).


Let's explore that. Characters are things like a, b, c, .... A
multibyte character is a sequence of bytes, ie a sequence of
memory locations. The set of characters is of some fixed size;
there are only so many of them. The set of (sequences of) memory
locations is of potentially unbounded size; certainly there can
be more memory locations than there are characters. If the set
of characters is smaller than the set of memory locations, how
can the set of memory locations be a subset of the set of
characters? If the set of memory locations is not a subset of
the set of characters, how can a memory location be a character?
A sequence of memory locations can represent characters, but they
are not themselves characters.


When you wrote "A multibyte character is a sequence of bytes", you
omitted an important qualification. 3.7.2 defines "multibyte character"
as "sequence of one or more bytes representing a member of the extended
character set ...". Sequences of bytes not representing a member of the
character set are not multibyte characters. Therefore, I can't follow
your reasoning at this point.
Similarly, the bit patterns in an eight-bit byte can represent
the numbers from zero to 255. We don't mean that a memory
location IS a number; a memory location -- or lots of different
memory locations -- can REPRESENT a number by having a certain
bit pattern stored in it (or them). There are only 256 numbers
between 0 and 255, but there are a lot more than 256 memory
locations -- there aren't enough numbers to go around so that
every memory location is a number. Or do you mean to say two
distinct memory locations can be the same, because they are
both (for example) the number 5?.

I think you're using "is" in the sense of "can stand in for".
And in that sense, I think I would agree with you -- a sequence
of memory locations (and the bit patterns stored therein) can
stand in for a character. But in technical writing the word "is"
is normally used in a different sense: if an X is a Y, then
the set of X's is a subset of the set of Y's. That sense of "is"
doesn't fit with what your statement about multibyte characters
implies.
Actually, I think it fits quite well; if I expand the statement "a
multibyte character is a character", I get "the set of sequences of one
or more bytes representing a member of the extended character set is a
subset of the set of members of a set of elements used for the
organization, control, or representation of data". I admit this could
probably be expressed less complicated, but I consider it to be correct.
And so: Saying X is an "indeterminate value" doesn't mean
that X is a value.


This is the very point which is contrary to my understanding of language
and logic - I'm afraid I just can't believe it.


Yes, I suspect the thread has lasted as long as it has because
your understanding of language and logic differs from that of
some other readers (mine in particular, but also some others).
...
(a) 3.17 is the only place where the single term "value" is defined, and
(b) I can see no reason to assume that there are indeed uses of the term
"value" that are inconsistent with what the definition implies.


Here's an example. We store the bit pattern 1000000, with a
value of 0 (on a signed magnitude implementation), into an
eight-bit byte. Subsequent reads of the object alternately
return 00000000, 10000000, 00000000, ..., all of which still have
the value 0. Is this behavior allowed by the statement that "an
object retains its last-stored value"?


I guess it's allowed when the contents of the byte are interpreted as
having a signed type and it's disallowed otherwise. But, I'm sorry, I
don't see the relevance of this example.
Second example:

int n;
unsigned char *p = (void*) &n;
p[0] = 0, p[1] = 1, p[2] = 2, p[3] = 3;

What is the last-stored value (in the sense of 3.17) of the
object n? Suppose the value (in the sense of 3.17) of n is
0x00010203; how could this value have been stored, since
no expression in the running program yields that value?
The answer to your first question here is implementation-defined or
undefined, of course. I hope you don't think I dismiss the second one
too thoughtlessly (I really thought quite some time over it), but the
answer is provided by the code snippet above, and again, I don't see why
this example should force anyone to believe that 3.17 could not apply to
the meaning of value in "last-stored value".
The statements you give support my assertion that the term
"value" is used with different senses in different places in
the Standard. What do you think "value" means in the
statements you quote, since it can't mean the same thing as the
definition in 3.17 p1?


In my opinion, in these statements [snipped to one representative]

"An object exists, has a constant address,25) and retains its
last-stored value throughout its lifetime."

the meaning of "value" is not at all different from its definition in
3.17. When I insert the definition into the statements, I get
[snipped to one representative]

"An object exists, has a constant address,25) and retains its
last-stored precise meaning of the contents of the object when
interpreted as having its specific type throughout its lifetime."

This may sound a little clumsy, but it is not illogical, is it?


Part of my problem with your reformulation is that I don't know
what the revised wording is meant to say. What is it that's
being stored? Is it a meaning, or a bit pattern? Let's look at
a slightly different wording:

"An object exists, has a constant address,25) and retains the
precise meaning of its last-stored contents of the object when
interpreted as having its specific type throughout its lifetime."

Does your statement mean the same thing as the rewording, or does
it mean something different? The rewording makes it clear that
what is being stored is "contents" rather than "meaning". A
"value" under 3.17 is a "meaning", so a 3.17-value is not what's
being stored (if the rewording is accurate). So which is it? Is
the statement about retaining the last-stored value inconsistent
with the 3.17 notion of value, or do you mean something different
by your statement than my proposed rewording? If the latter, then
what rewording would you propose?


It appears to me that although your rewording changes what is being
stored from "meaning" to "contents", what is retained ("meaning")
remains the same, and so the observable behaviour of a program would
remain the same, making the two versions of the statement functionally
equivalent.

And remember, you answered my question
(How can I store something in an object without using a type?)


that way: Can't in C. Even functions like memcpy() act on "arrays
of character type and other objects treated as arrays of
character type" (7.21.1 p1).
So, we can't store anything without "meaning", i. e. type.
The statement about retaining the last-stored value is, in my opinion,
as well as all other statements in the standard, not inconsistent with
the 3.17 notion of value.
I wouldn't say I find your revised definitions illogical,
but they do seem (at least to me) nonsensical.

... I've tried to divine what
it is you've been trying to say, and some of that is expressed
above (how I think you mean "is", for example). So let's see if
I can articulate what I think is the Standard is trying to say.
Disclaimer: very off-the-cuff remarks follow.

The word "value" is used in several senses in the Standard.
The definition given in 3.17 uses "value" in the sense of
how we are to interpret the contents of an object, when
interpreted in a particular context (namely, as what type).

Many places in the Standard use "value" not in the sense of 3.17,
but the sense of "raw bit pattern". Thus, when we say that an
object retains its last-stored "value", this wording is meant
to say that an object retains the last bit pattern stored into
that object. Similarly, we say a write access modifies an
object even if the raw bit pattern being stored matches the
bit pattern already in the object.

There is some confusion between the two senses, and that
confusion has prompted some esoteric discussion in the comp.*.c
newsgroups. For example, suppose a particular address is stored
in a pointer variable, and then the memory at that address is
deallocated (by calling free(), for example). Is the bit pattern
that was stored in the pointer allowed to change? I remember
there being discussion at some point on this question, although I
don't remember the outcome. However, part of what prompted the
discussion in the first place -- and what made it difficult -- is
the confusion over which sense of "value" is meant in statements
like "an object retains its last-stored value". If "value" means
"raw bit pattern" you reach one conclusion, and if "value" means
value-ala'-3.17 you (can) reach another. Some of the debate
centered around this confusion, although I don't remember if it
was ever explicitly identified.

Note that I'm not saying that one sense is the true sense and the
other sense is wrong; there is some ambiguity in the Standard
itself, and that ambiguity deserves (IMO) a DR (which hopefully
would result in revised and improved wording, but let's not get
into that right now). But -- and here is the important thing --
many places in the Standard where "value" is used are best read
as though "value" meant "raw bit pattern". And that sense of
value is definitely different than "value" as defined in 3.17.

Does that all make sense?


I would be exaggerating here if I claimed that all made sense to me, but
it certainly did to some extent, and I understand your position better
now.

Unfortunately (or fortunatly, as it may also be perceived) I'll not be
able to continue this interesting (at least for me, maybe not so for
others) discussion for the next two weeks, because I'll be on vacation.
So long!
Nov 15 '05 #103
Dietmar Schindler <sc**@arw0120.mra.man.de> writes:
Tim Rentsch wrote:

[snip]

Note that my position is that undefined behavior is possible
even when two's complement representation is used. Two's
complement doesn't have a representation for negative zero,
so it isn't covered by the paragraph cited above. Even so,
bitwise operators on signed types that are represented using
two's complement may still result in undefined behavior.


Yes, however your wording "seems like bitwise operators on negative
operands can result in undefined behavior at any time" seems somewhat
exaggerated to me. With two's complement representation, I find exactly
one possibility for undefined behavior, and that's in

6.2.6.2 Integer types
2 ...
Which of these applies is implementation-defined, as is whether the
value with sign bit 1 and all value bits zero ... is a trap
representation or a normal value.

The exclusion of other possibilities of undefined behavior of bitwise
operators when two's complement representation is used is suggested, as I
understand it, by footnotes 44 and 45, which say "no arithmetic operation
on valid values can generate a trap representation other than as part of
an exceptional condition such as an overflow."


Yes, but here's the rub. If the bit pattern produced by a
bitwise operator corresponds to a trap representation for
the type in question, then it does not correspond to a value
for that type. This means the result is "not in the range
of representable values for its type", which makes it an
exceptional condition. So the comment in the footnotes
isn't as limiting as it might appear to be.

You're right that quoted remark "[it] seems like bitwise
operators on negative operands can result in undefined
behavior at any time" isn't literally exactly accurate. But
it's only a slight exaggeration. If the operands are of
type 'int', for example, I believe the integers 0, INT_MIN
and INT_MAX are required to be actual values. However, I
haven't found any language anywhere in the Standard that
would disallow every other int bit pattern from being a trap
representation.

Because the Standard places almost no restrictions on which
representations can be trap representations, I think it is
true that bitwise operators on negative operands can result
in undefined behavior at ALMOST any time. They won't on
most implementations of course. But on the famous
DeathStation 9000 - watch out!
Nov 15 '05 #104
ku****@wizard.net writes:
Richard Bos wrote:
Keith Thompson <ks***@mib.org> wrote:

...
Ok, I see your point. My parsing of the phrase "null pointer
constant" was influenced by knowing what the term actually means.

But "easy programming manuals", whether they're programming manuals
that are easy or manuals about easy programming, are manuals. They
aren't programming.

A null pointer constant, whether it's a pointer constant that's null
or a constant for a null pointer, is a constant; it's not a pointer.


What's more, TTBOMK there are no other pointer constants; a "non-null
(pointer constant)" doesn't even exist, so the parse "null (pointer
constant)" is spurious and the parse "(null pointer) constant" is, to
me, the obvious one.


Since the standard assigns no special meaning to the term "pointer
constant", we're supposed to use ordinary rules of english usage to
interpret it. In the constext of the C standard, it has a meaning that
seems clear, obvious, and unambiguous to me (YMMV): a constant
expression with pointer type. In other words, it's essentially
synonymous with what the standard calls an "address constant". If it
weren't for the fact that the standard does provide a definition of
"null pointer constant", the obvious (to me) interpretation would be "a
constant expression with a pointer type and a null value"; which is NOT
how the standard defines it.


I'll chime in here, since it was my comment that started
this subthread between Keith Thompson and myself.

It's indeed true (which I didn't realize in my earlier
postings) that 6.6 talks about "address constants" in a
couple of paragraphs, especially paragraph 9 which gives
the definition for the term.

Reading through those paragraphs, I have to admit that it
seems like the authors thought of the phrase "null pointer
constant" as "(null pointer) constant" rather than "null
(pointer constant)". So Keith's (and Richard's) view is
more in line with how the people who wrote the phrase in the
first place seem to think of it.

Personally, I still think "null (pointer constant)" makes
sense and is more in line with the rules of regular English
usage. But I acknowledge that, if one were making an
argument, the "(null pointer) constant" view is more likely
to win the debate.
Nov 15 '05 #105
Tim Rentsch wrote:
Reading through those paragraphs, I have to admit that it
seems like the authors thought of the phrase "null pointer
constant" as "(null pointer) constant" rather than "null
(pointer constant)". So Keith's (and Richard's) view is
more in line with how the people who wrote the phrase in the
first place seem to think of it.


No, it's a "null pointer constant", a technical term unto
itself. In contexts where a n.p.c. is allowed, one has to
refer to the syntactic definition to check if a n.p.c. is
in fact used. The logical tightrope is due to the great
*in*advisability of declaring anywhere that "0" (without
the quotation marks) *is* a n.p.c. It *can* be a n.p.c,
in certain contexts, but it isn't *always* a n.p.c.

Technical terms in the standard are not meant to be parsed
into English components and analyzed on that basis.
Nov 15 '05 #106
"Douglas A. Gwyn" <DA****@null.net> writes:
Tim Rentsch wrote:
Reading through those paragraphs, I have to admit that it
seems like the authors thought of the phrase "null pointer
constant" as "(null pointer) constant" rather than "null
(pointer constant)". So Keith's (and Richard's) view is
more in line with how the people who wrote the phrase in the
first place seem to think of it.
No, it's a "null pointer constant", a technical term unto
itself.


Ok.
In contexts where a n.p.c. is allowed, one has to
refer to the syntactic definition to check if a n.p.c. is
in fact used. The logical tightrope is due to the great
*in*advisability of declaring anywhere that "0" (without
the quotation marks) *is* a n.p.c. It *can* be a n.p.c,
in certain contexts, but it isn't *always* a n.p.c.
But that's not what the standard says. C99 6.3.2.3p3 says:

An integer constant expression with the value 0, or such an
expression cast to type void *, is called a _null pointer
constant_. If a null pointer constant is converted to a pointer
type, the resulting pointer, called a _null pointer_, is
guaranteed to compare unequal to a pointer to any object or
function.

It says that 0 is a null pointer constant, and describes what happens
*if* it's converted to a pointer type.

How are we to infer that in
int n = 0;
or even
0;
the 0 is not a null pointer constant, when the definition of the term
clearly states that it is? (It's an "integer constant expression with
the value 0").
Technical terms in the standard are not meant to be parsed
into English components and analyzed on that basis.


Agreed. Ideally the technical terms should be chosen so they make
sense as English phrases (and I have no complaints about "null pointer
constant" in that regard), but that's a secondary issue.

Are we to infer from the presence of the word "pointer" in the phrase
"null pointer constant" that a 0 appearing in a non-pointer context is
*not* a null pointer constant? Should we parse the term into English
components or shouldn't we?

Please note that I'm not saying that there's any problem with the 0 in
"int n = 0;" being a null pointer constant. Since it's not converted
to a pointer type, this is harmless and ignorable. 0 is many things:
an integer constant, an octal constant, a constant, a constant
expression, and so forth -- and it can be used in contexts where such
things are not specifically required.

--
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.
Nov 15 '05 #107
"Douglas A. Gwyn" <DA****@null.net> writes:
Tim Rentsch wrote:
Reading through those paragraphs, I have to admit that it
seems like the authors thought of the phrase "null pointer
constant" as "(null pointer) constant" rather than "null
(pointer constant)". So Keith's (and Richard's) view is
more in line with how the people who wrote the phrase in the
first place seem to think of it.
No, it's a "null pointer constant", a technical term unto
itself.


The two statements aren't inconsistent. I understand that
technical terms as used in the Standard are meant to be
taken as atomic units. My comment however is orthogonal
to that.

In contexts where a n.p.c. is allowed, one has to
refer to the syntactic definition to check if a n.p.c. is
in fact used. The logical tightrope is due to the great
*in*advisability of declaring anywhere that "0" (without
the quotation marks) *is* a n.p.c. It *can* be a n.p.c,
in certain contexts, but it isn't *always* a n.p.c.
What I think you mean is that expressions like '0' aren't
always used as null pointer constants. Or, to say that
another way, they may be null pointer constants, but that
they are null pointer constants has no logical consequences.

Technical terms in the standard are not meant to be parsed
into English components and analyzed on that basis.


Yes, I said almost exactly that recently to support a
statement that the term "indeterminate value" doesn't
necessarily imply that something is a "value".
Nov 15 '05 #108
Keith Thompson wrote:
How are we to infer that in
int n = 0;
the 0 is not a null pointer constant, ...


In that context it is irrelevant whether or not it "is" a n.p.c.
The only time it matters is when there is a *requirement* (maybe
one of several alternatives allowed in some context), in which
case one has to check whether the definition is met.

I think in an earlier version/draft of the standard we used
different wording, but the intent has always been the same.

We wouldn't have this issue at all if C had a reserved
keyword, "nil" or "NULL" or whatever, that had to be used
whenever one wished to denote a n.p.c. Designers of new
languages should take that approach.
Nov 15 '05 #109
"Douglas A. Gwyn" <DA****@null.net> writes:
Keith Thompson wrote:
How are we to infer that in
int n = 0;
the 0 is not a null pointer constant, ...
In that context it is irrelevant whether or not it "is" a n.p.c.
The only time it matters is when there is a *requirement* (maybe
one of several alternatives allowed in some context), in which
case one has to check whether the definition is met.


I agree, but that doesn't answer my question.

Doug, a week or so ago it seemed to matter a great deal to you whether
0 is a null pointer constant in that particular context. Here's what
you wrote then:

] No, it's a "null pointer constant", a technical term unto
] itself. In contexts where a n.p.c. is allowed, one has to
] refer to the syntactic definition to check if a n.p.c. is
] in fact used. The logical tightrope is due to the great
] *in*advisability of declaring anywhere that "0" (without
] the quotation marks) *is* a n.p.c. It *can* be a n.p.c,
] in certain contexts, but it isn't *always* a n.p.c.
]
] Technical terms in the standard are not meant to be parsed
] into English components and analyzed on that basis.

I'm not claiming that the NPC-ness of 0 in a non-pointer context is of
any great significance. It's just an interesting little detail of the
language that most people probably aren't aware of, like the fact that
0 is an octal constant -- and I don't see anybody arguing that 0 is an
octal constant only if it appears in a context that requires an octal
constant. (That's partly because there are no such contexts, of
course.)

The standard clearly says that 0 is a null pointer constant. There is
no indication that it's a null pointer constant only in certain
contexts. You have argued forcefully that 0 should *not* be
considered a null pointer constant in certain contexts, in apparent
contradiction both to the standard and to your own statement that
"Technical terms in the standard are not meant to be parsed into
English components and analyzed on that basis".

I agree that it doesn't matter much that 0 in "int n = 0;" is a null
pointer constant -- but since you claim that it isn't, I'd like to
hear your justification for that claim.
I think in an earlier version/draft of the standard we used
different wording, but the intent has always been the same.
And what exactly is that intent? We can only go by what the standard
actually says, and perhaps by what members of the Committee tell us
about the intent. If the wording seems to conflict with the intent,
and if the actual wording doesn't create any problems, I think we have
to go by the actual wording.

If a future version of the standard stated that a null pointer
constant can only appear in a pointer context (a term that would have
to be defined), that would be fine with me, perhaps even an
improvement. But that's not what the standard says.
We wouldn't have this issue at all if C had a reserved
keyword, "nil" or "NULL" or whatever, that had to be used
whenever one wished to denote a n.p.c. Designers of new
languages should take that approach.


I agree completely. Now will you please answer my question?

The question itself is not important, but if there is a real reason to
think that the 0 in "int n = 0;" is *not* a null pointer constant,
then it means I have a serious misunderstanding of the standard, and
that's important (at least to me).

--
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.
Nov 15 '05 #110
On 2005-09-20 19:31, Keith Thompson wrote:
:
If a future version of the standard stated that a null pointer
constant can only appear in a pointer context


....then this would disallow 0 in non-pointer contexts. Bad idea. ;)

-- Niklas Matthies
Nov 15 '05 #111
Niklas Matthies <us***********@nmhq.net> writes:
On 2005-09-20 19:31, Keith Thompson wrote:
If a future version of the standard stated that a null pointer
constant can only appear in a pointer context


...then this would disallow 0 in non-pointer contexts. Bad idea. ;)


No, just a mediocre idea expressed badly. What I meant was that the
definition of "null pointer constant" would be left as it is, *except*
that something that meets the current definition is considered to
be a null pointer constant only if it appears in a pointer context.
So "int n = 0;" would still be legal, but the 0 wouldn't be a null
pointer constant. (The concept of "pointer context" would have to
be defined.)

If worded carefully, such a change shouldn't affect any implementation
or program, just the way we talk about them.

I'm not advocating such a change, just saying that I wouldn't object
to it. The fact that 0 in the above is a null pointer constant (or,
if Doug is right and I'm missing something, the fact that it isn't)
causes no harm other than a bit of confusion.

--
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.
Nov 15 '05 #112
Keith Thompson wrote:
... It's just an interesting little detail of the
language that most people probably aren't aware of, like the fact that
0 is an octal constant ...


Also (at least at one point) preprocessing number syntax
supported more constructs than were truly intended, but
since it was benign (the unwanted stuff would be caught
at a later stage of translation) we opted for the
simpler description.

My concern was that this thread seemed to be starting to
attribute more to the notion of n.p.c. than was ever
intended. While an unadorned "0" might be *called* a
n.p.c. (as the spec says) in a non-pointer context, it
is inappropriate to call it a n.p.c. in such a context,
because it is simply not a relevant attribute (in that
context). If you pedantically insist on doing the
contrary, you add to confusion about the concept.
Nov 15 '05 #113
Keith Thompson wrote:
If worded carefully, such a change shouldn't affect any implementation
or program, just the way we talk about them.


We considered how to express the concept and as a compromise
settled on the one you see in the spec. As I noted in a
separate posting, it's not the only place where we found
that a perfectly precise specification would be far more
complex than an approximate specification that covers
everything that matters but also benignly includes a few
other things that we would have preferred not to bundle
together. Most such instances arose from having to
conform to the historical design and evolution of the C
language, and could be avoided in an ab initio PL design.
Nov 15 '05 #114
"Douglas A. Gwyn" <DA****@null.net> writes:
Keith Thompson wrote:
... It's just an interesting little detail of the
language that most people probably aren't aware of, like the fact that
0 is an octal constant ...


Also (at least at one point) preprocessing number syntax
supported more constructs than were truly intended, but
since it was benign (the unwanted stuff would be caught
at a later stage of translation) we opted for the
simpler description.

My concern was that this thread seemed to be starting to
attribute more to the notion of n.p.c. than was ever
intended. While an unadorned "0" might be *called* a
n.p.c. (as the spec says) in a non-pointer context, it
is inappropriate to call it a n.p.c. in such a context,
because it is simply not a relevant attribute (in that
context). If you pedantically insist on doing the
contrary, you add to confusion about the concept.


I was merely attributing to the notion of n.p.c. exactly what the
standard attributes to it. I've acknowedged numerous times that the
question of whether an unadorned 0 is a null pointer constant isn't
very important. I raised the issue (this time) simply because *you*
insisted that it isn't, whereas the standard clearly says it is.

I believe my position is perfectly clear. 0 is a null pointer
constant. If it's converted to a pointer type, this fact is relevant.
If it's not converted to a pointer type, it's not being *used* as a
null pointer constant, but it still meets the definition, just as 0 is
a constant expression even when it's used in a context that doesn't
require one.

I'm not trying to create confusion; I'm trying to reduce the confusion
that's already there.

So your response to my question:
I agree completely. Now will you please answer my question?


is "No"?

--
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.
Nov 15 '05 #115
Keith Thompson wrote:
So your response to my question:
I agree completely. Now will you please answer my question?

is "No"?


I try not to respond to cheap debating ploys such as making
the other guy answer a question that he might not think is
well posed or relevant. If something I have said isn't
clear enough, you can ask questions about it and if they
seem to be well-intentioned I'll probably respond.

The basic issue with a bare statement like "0 ... is a null
pointer constant" is that the use of "is" implies identity,
but actually 0 is several things, including an octal constant
as I think was mentioned elsewhere in this thread. The
n.p.c.ness is irrelevant and thus epistemologically
inappropriate to be considering in contexts where pointers
aren't involved. I tried to explain why we didn't say "0 ...
is a null pointer context in the following contexts...",
which would fit your model of definition. Basically it is
too hard to get it precisely right, and the looser approach
still has the right technical properties given the way that
the requirement for n.p.c.ness in some contexts is phrased
elsewhere in the standard.
Nov 15 '05 #116
"Douglas A. Gwyn" <DA****@null.net> writes:
Keith Thompson wrote:
So your response to my question:
> > I agree completely. Now will you please answer my question? is "No"?


I try not to respond to cheap debating ploys such as making
the other guy answer a question that he might not think is
well posed or relevant. If something I have said isn't
clear enough, you can ask questions about it and if they
seem to be well-intentioned I'll probably respond.


It was not a cheap debating ploy. I honestly don't know why you think
it was.
The basic issue with a bare statement like "0 ... is a null
pointer constant" is that the use of "is" implies identity,
but actually 0 is several things, including an octal constant
as I think was mentioned elsewhere in this thread.
No, it does not imply identity. If 0 is a null pointer constant, that
does not in any way imply that it's not *also* an octal constant, an
integer constant, a constant, a constant expression, etc. I believe
I've made that extremely clear.
The
n.p.c.ness is irrelevant and thus epistemologically
inappropriate to be considering in contexts where pointers
aren't involved.
Why? I acknowledge that it's not a very important point -- but *you*
are the one who seems to think it's terribly important that 0 in a
non-pointer context should *not* be considered a null pointer
constant. I am trying to understand your point.
I tried to explain why we didn't say "0 ...
is a null pointer context in the following contexts...",
which would fit your model of definition. Basically it is
too hard to get it precisely right, and the looser approach
still has the right technical properties given the way that
the requirement for n.p.c.ness in some contexts is phrased
elsewhere in the standard.


This has nothing to do with my "model of definition" (our earlier
dispute about whether definitions need to be exhaustive). I actually
don't have a problem with this aspect of the current definition of
"null pointer constant".

Once again:

Given the definition in C99 6.3.2.3p3 (which I find sufficiently
clear), and given something like:
int n = 0;
the 0 is a null pointer constant. The context doesn't *require* a
null pointer constant; nor does it require an octal constant, an
integer constant, a constant, or a constant expression. Nevertheless,
it is simultaneously a null pointer constant; nor does it require an
octal constant, an integer constant, a constant, and a constant
expression.

Is this correct? I'm not asking whether it's important or relevant,
I'm asking whether it's correct.

I do not consider this to be a flaw in the definition of "null pointer
constant". I can imagine a definition that would exclude this case,
but it would have to be more complex, and I think the current
definition is a good tradeoff.

All I've been trying to do here is reconcile what the standard says
(0 is a null pointer constant) with what you have written in this
thread:

] The logical tightrope is due to the great *in*advisability of
] declaring anywhere that "0" (without the quotation marks) *is* a
] n.p.c. It *can* be a n.p.c, in certain contexts, but it isn't
] *always* a n.p.c.

The only consistent interpretation I can think of is that 0 is always
a null pointer constant, but that it's very important for us not to
admit it in certain contexts. Is that what you mean?

My quarrel is not with the standard, it's with *your* statements.

--
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.
Nov 15 '05 #117
Keith Thompson <ks***@mib.org> writes:
[...]
Once again:

Given the definition in C99 6.3.2.3p3 (which I find sufficiently
clear), and given something like:
int n = 0;
the 0 is a null pointer constant. The context doesn't *require* a
null pointer constant; nor does it require an octal constant, an
integer constant, a constant, or a constant expression. Nevertheless,
it is simultaneously a null pointer constant; nor does it require an
octal constant, an integer constant, a constant, and a constant
expression.


Whoops, editing error. What I meant to write was:

Given the definition in C99 6.3.2.3p3 (which I find sufficiently
clear), and given something like:
int n = 0;
the 0 is a null pointer constant. The context doesn't *require* a
null pointer constant; nor does it require an octal constant, an
integer constant, a constant, or a constant expression. Nevertheless,
it is simultaneously a null pointer constant, an octal constant, an
integer constant, a constant, and a constant expression.

--
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.
Nov 15 '05 #118
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
Keith Thompson <ks***@mib.org> writes:
[...]
Once again:

Given the definition in C99 6.3.2.3p3 (which I find sufficiently
clear), and given something like:
int n = 0;
the 0 is a null pointer constant. The context doesn't *require* a
null pointer constant; nor does it require an octal constant, an
integer constant, a constant, or a constant expression. Nevertheless,
it is simultaneously a null pointer constant; nor does it require an
octal constant, an integer constant, a constant, and a constant
expression.


Whoops, editing error. What I meant to write was:

Given the definition in C99 6.3.2.3p3 (which I find sufficiently
clear), and given something like:
int n = 0;
the 0 is a null pointer constant. The context doesn't *require* a
null pointer constant; nor does it require an octal constant, an
integer constant, a constant, or a constant expression. Nevertheless,
it is simultaneously a null pointer constant, an octal constant, an
integer constant, a constant, and a constant expression.


I must voice my disagreement :

0 is only a null pointer constant as a last resort. Context does matter!
Here is a simple infamous example to illustrate this sorry fact :

printf("%p", 0);

As we all know, this code in incorrect, and it will fail on architectures where
sizeof(void*) > sizeof(int)

The same is sadly true of

printf("%p", NULL);

if NULL is defined as 0 as is required for C++ and accepted for C.

--
Chqrlie.
Nov 15 '05 #119
"Charlie Gordon" <ne**@chqrlie.org> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
Keith Thompson <ks***@mib.org> writes:
[...]
> Once again:
>
> Given the definition in C99 6.3.2.3p3 (which I find sufficiently
> clear), and given something like:
> int n = 0;
> the 0 is a null pointer constant. The context doesn't *require* a
> null pointer constant; nor does it require an octal constant, an
> integer constant, a constant, or a constant expression. Nevertheless,
> it is simultaneously a null pointer constant; nor does it require an
> octal constant, an integer constant, a constant, and a constant
> expression.


Whoops, editing error. What I meant to write was:

Given the definition in C99 6.3.2.3p3 (which I find sufficiently
clear), and given something like:
int n = 0;
the 0 is a null pointer constant. The context doesn't *require* a
null pointer constant; nor does it require an octal constant, an
integer constant, a constant, or a constant expression. Nevertheless,
it is simultaneously a null pointer constant, an octal constant, an
integer constant, a constant, and a constant expression.


I must voice my disagreement :

0 is only a null pointer constant as a last resort. Context does matter!
Here is a simple infamous example to illustrate this sorry fact :

printf("%p", 0);

As we all know, this code in incorrect, and it will fail on
architectures where
sizeof(void*) > sizeof(int)

The same is sadly true of

printf("%p", NULL);

if NULL is defined as 0 as is required for C++ and accepted for C.


Of course. It will also fail on architectures where a null pointer
(specifically a null pointer of type void*) has a representation other
than all-bits-zero. But it doesn't fail because 0 isn't a null
pointer constant; it fails because it's not converted to a pointer
type.

Again, here's C99 6.3.2.3p3:

An integer constant expression with the value 0, or such an
expression cast to type void *, is called a _null pointer
constant_. If a null pointer constant is converted to a pointer
type, the resulting pointer, called a _null pointer_, is
guaranteed to compare unequal to a pointer to any object or
function.

According to this, the 0 in printf("%p", 0) is a null pointer constant
(which is a source code construct), but because it's not converted to
a pointer type, it doesn't yield a null pointer at run time.

The fact that this 0 is a null pointer constant happens to be a null
pointer constant turns out not to be useful, just as it's not useful
to know that it's an octal constant. That doesn't make it untrue.

I see nothing in the definition of "null pointer constant" that
implies that the definition depends on the context in which it
appears. What are you seeing that I'm not?

There are many null pointer constants that aren't *used* as null
pointer constants -- and that's ok.

--
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.
Nov 15 '05 #120
Charlie Gordon wrote:
printf("%p", 0);

As we all know, this code in incorrect, and it will fail on architectures where
sizeof(void*) > sizeof(int)


Not quite. If the argument passing scheme doesn't care about the size,
for example by using registers for both types, there's no difference. On
NetBSD, this is said to work:

http://mail-index.netbsd.org/tech-us...4/13/0000.html
http://mail-index.netbsd.org/tech-us...4/13/0001.html
http://mail-index.netbsd.org/tech-us...4/13/0002.html
http://mail-index.netbsd.org/tech-us...4/13/0003.html

Nevertheless, the code is not portable and should be avoided.

Roland
Nov 15 '05 #121
Roland Illig <ro**********@gmx.de> writes:
Charlie Gordon wrote:
printf("%p", 0);
As we all know, this code in incorrect, and it will fail on
architectures where
sizeof(void*) > sizeof(int)
Not quite. If the argument passing scheme doesn't care about the size,
for example by using registers for both types, there's no
difference. On NetBSD, this is said to work:

http://mail-index.netbsd.org/tech-us...4/13/0000.html
http://mail-index.netbsd.org/tech-us...4/13/0001.html
http://mail-index.netbsd.org/tech-us...4/13/0002.html
http://mail-index.netbsd.org/tech-us...4/13/0003.html


Even assuming both types are passed in the *same* register, the code
can fail if a null pointer isn't represented as all-bits-zero. There
may be other ways it can fail that I can't think of off the top of my
head.
Nevertheless, the code is not portable and should be avoided.


Yup. In fact, it invokes undefined behavior, with all that implies.

--
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.
Nov 15 '05 #122
>> Charlie Gordon wrote:
printf("%p", 0);
As we all know, this code in incorrect, and it will fail on
architectures where
sizeof(void*) > sizeof(int)
Roland Illig <ro**********@gmx.de> writes:
Not quite. If the argument passing scheme doesn't care about the size,
for example by using registers for both types ...

In article <ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.org> wrote:Even assuming both types are passed in the *same* register, the code
can fail if a null pointer isn't represented as all-bits-zero. There
may be other ways it can fail that I can't think of off the top of my
head.


The usual one is that you run out of argument registers, so that
remaining arguments are passed by some other mechanism, where the
size does matter. For instance, on MIPS, you get four "integer-like"
arguments via registers, the rest via temporary storage the compiler
allocates in an appropriate stack frame; on SPARC you get six; on
PowerPC the number depends on whose ABI you use, I believe.

Thus:

printf("%p", 0);

"just happens" to work, but:

printf("i: %d, s: %s, c: %c, p: %p", i, s, c, 0);

"just happens" to behave bizarrely on a 64-bit MIPS. (The four
arguments a0 through a3 include the format and i, s, and c; the
fifth argument for %p -- given incorrectly here as an unadorned
integer constant zero -- writes only 32 of the 64 bits that will
be read.)

The same code "just happens" to work on the SPARC until two more
parameters are inserted.
Nevertheless, the code is not portable and should be avoided.


Yup. In fact, it invokes undefined behavior, with all that implies.


Indeed.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 15 '05 #123

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Mike | last post by:
My users have to select an value from a fixed selection of values. The obvious choice of control for such a requirement is to use a <select> (i.e. a combo box). My problem is that sometimes,...
3
by: Will McGugan | last post by:
Hi, Is there a simple way of replacing a large number of substrings in a string? I was hoping that str.replace could take a dictionary and use it to replace the occurrences of the keys with the...
5
by: David | last post by:
Hi all: I am processing a 3D bitmaps(essentially ~1024 2D bitmaps with a size of 1MB each). If I want read large amount of radom data from this series, how could I buffer the file to get...
3
by: vanvee | last post by:
Hi I have an application for my company's HR department where we store resumes for candidates we receive. I have an application that uses VB.Net and ADO.Net and data bindings (through code) to...
6
by: Alex | last post by:
Hi... I have a stored procedure that takes in a large number of parameters (around 30) and returns (as output parameters) another 10 or so. At the moment, each parameter is declared, defined...
2
by: =?Utf-8?B?UHJpeWE=?= | last post by:
Hi, I'm faced with a classic problem of how to update a large number of records from a web page. I;m trying to build an interface that will display recordset in the order of 3000 rows and allow...
8
by: theCancerus | last post by:
Hi All, I am not sure if this is the right place to ask this question but i am very sure you may have faced this problem, i have already found some post related to this but not the answer i am...
0
by: zephyrus360 | last post by:
This is about a technique to find the mod of a very large integer with a normal small integer. I recently encountered this problem when I needed to compute the modulus of a very large number with...
12
by: fermineutron | last post by:
I am trying to write a function which will convert a large ascii number, say 100 ascii digits, to its binary representation. It seems that evey algorithm I am trying to think of is backwards. ...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.