Re: if (pointer) ?

Tim Rentsch <txr@xxxxxxxxxxxxxxxxxxx> writes:
Keith Thompson <kst-u@xxxxxxx> writes:
Tim Rentsch <txr@xxxxxxxxxxxxxxxxxxx> writes:
[...]
I'm somewhat torn as to how to respond here. Clearly the proposed
text presents a good effort, or even very good. However, the text
proposed differs in a fundamental way from the Standard text (i.e.,
the one sentence) that it's intended to replace.

Yes. I think the existing text doesn't capture the intent.

Two possibilities: one, the existing text does capture the
committee's intent, it just doesn't express it clearly enough;
two, what the existing text expresses (clearly or not) does not
reflect the committee's intent.

Given your statement, which ever of those two possibilities holds,
for what you want to do it seems advisable to: first, write a
short statement (in very clear language) of what was intended to
be expressed (and possibly also what was expressed, again emphasizing
clear language); second, write a statement of what you think
should be expressed - nothing formal, just brief but clear and direct.
If there's a consensus of agreement on those, then producing the
right language should be much easier; conversely, if there isn't
agreement on those, then getting the language right is much harder
(even if possible).

Hmm. The wording I presented was intended to be clear enough to
express what I thought was the intent. If the actual intent differs
from what I wrote, the committee members who hang out here (certainly
not all of them do) can jump in and point out any discrepancies.

[...]

That was deliberate. My understanding is that both (int*)0 and
(int*)0xdeadbeef are intended to be address constants. The former of
course evaluates to a null pointer; the latter evaluates to some
implementation-specific address which might be useful in non-portable
code. I stated this understanding upthread; Larry Jones, who should
know, didn't contradict me, though he didn't quote that particular
paragraph in his followup.

If a non-zero integer constant expression cast to a pointer type
*isn't* intended to be an address constant, then it's easy enough to
fix the wording (but I know of a couple of compilers that would also
have to be fixed).

(I hadn't seen the upthread posting.) What I think might be true
(intended?) is that some non-zero integer values cast to pointers
would be okay, and others would not. Which ones were and which
ones were not would depend, at a minimum, on implementation-defined
behavior. I don't know if the intention was to allow /all/ integer
values cast to pointer types, or only those integer values that
correspond to objects of static storage duration. This ambiguity
is one reason I think it would help to try to get agreement on
what the starting point was.

In my opinion, either all non-zero integer values cast to a pointer
type should be address constants, or none should be. It's about
whether a given expression falls into a certain well-defined category,
not about whether it's "okay". Such expressions can only be used in
non-portable code -- which is one of the things C was designed for.

If an integer value corresponded to an object of static storage
duration (e.g., &obj happens to be (unsigned char*)0x12345678), you
wouldn't want to use the integer value anyway; you'd just refer to the
object. You can't know when you're writing the code what a given
object's address is going to be.

So, for example, this declaration at file scope:
unsigned char *foo = (unsigned char*)0x12345678;
would be legal, but whether you can use either foo or *foo depends on
the implementation.

[...]

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • Re: Pass by ref vs. value
    ... >> pointer to any pointer type you want, ... >> example you can allocate just one byte of memory but then cast the ... That's one reason only expert programmers who are ... >> language for rank beginners is a great mystery to me. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: C or C++ do you prefer to program?
    ... > strchrthat take a pointer to a const char, ... I'm just referring to a general way of performing conversions. ... every language, it's just a question of how it's written. ... > well, but if you asked me to cast, say, among function pointers, I ...
    (comp.unix.programmer)
  • Re: Common misconceptions about C (C95)
    ... You could say that about /any/ conversion which is not actually ... changed to a different conversions by the presence of a cast. ... In any conversion between pointer types (on assignment, initialization, ... diagnostics from the language, so that these useless do-nothing casts don't ...
    (comp.lang.c)
  • Re: Why no generic function pointers?
    ... required type of the pointer could simply be deduced from the call. ... then I think you are asking for quite a different language. ... from one function type to another without a cast. ...
    (comp.lang.c)
  • Re: if (pointer) ?
    ... I think the existing text doesn't capture the intent. ... short statement (in very clear language) of what was intended to ... If a non-zero integer constant expression cast to a pointer type ...
    (comp.std.c)