detabbing again

[Frank]

Yes, it's one of the safest risks you can take.  It's also one of the
easiest to avoid.  A printf call with a "%p" format and no cast should
always be suspicious.  It's much simpler to add the cast than to
convince yourself that it's unnecessary.

With code shown in this thread, can someone provide an example?

 

[Frank]

Sure.  Given:
    char *endp;
rather than:
    printf("endp is %p\n", endp);
write:
    printf("endp is %p\n", (void*)endp);

The first version is almost certainly safe; it would take a
deliberately perverse implementation to break it.  The second
version is safe, period (assuming, in both cases, that endp has a
valid value).

Alles klar.

 

[Frank]

On the Deathstation pointers are 500 characters long. So you obviously knew
this, and the second version just squeaks through.

So Malcolm, have you determined the source for a satifactory,
conforming, detabbing facility? I'm close enough to consider myself
finished as far as what I can accomplish in this thread. I thought
the logic surrounding argv1[1] and *endp was very gooey. I didn't run
io_x's last post, but I don't think either of us is going to get much
peer review this far down in the thread.

 

[Tim Rentsch]

"A pointer to void shall have the same representation and alignment
requirements as a pointer to a character type.39)" (6.2.5p27). The 39
at the end of that sentence is in superscript, and refers to footnote
39: "The same representation and alignment requirements are meant to
imply interchangeability as arguments to functions, return values from
functions, and members of unions."

Now, despite what is "meant", "same representation and alignment" does
not actually imply interchangeability, since it is possible to define
an ABI that distinguishes char* and void* without any difference in
either the representation or alignment; it could pass them in
different registers, for instance.

An irrelevant argument. It's essentially always possible to
define an ABI that distintuishes any two possibilities that
can be described. The only relevant question is, what
possibilities are allowed by the Standard? James's opinion
seems to be that the Standard allows such distinctions
in this case. I believe that is a minority opinion. In
any case, there certainly are other well-recognized
contributors to c.l.c who have expressed a belief that
the Standard does not allow such distinctions (and so
that the code above would have to work).

 

[Tim Rentsch]

[snip]

char *endp;
printf("endp is %p\n", endp);
printf("endp is %p\n", (void*)endp);

The first [printf line] is almost certainly safe; it would take a
deliberately perverse implementation to break it. [snip]

To say this more practically: there has never been, nor
will there ever be, an ISO-conforming C implementation in
which there is the slightest difference in run-time behavior
between these two cases.

 

[James Kuyper]

[snip]

char *endp;
printf("endp is %p\n", endp);
printf("endp is %p\n", (void*)endp);

The first [printf line] is almost certainly safe; it would take a
deliberately perverse implementation to break it. [snip]

To say this more practically: there has never been, nor
will there ever be, an ISO-conforming C implementation in
which there is the slightest difference in run-time behavior
between these two cases.

Keep in mind that "practically" means that the any a absolute terms such
as "never" or "ever" should be understood in a non-absolute sense. In
reality, as opposed to "practicality", it's entirely possible that such
an implementation may some day be created, even if only for the purpose
of proving that it can be done.

 

[James Kuyper]

An irrelevant argument. It's essentially always possible to
define an ABI that distintuishes any two possibilities that
can be described. The only relevant question is, what
possibilities are allowed by the Standard? James's opinion
seems to be that the Standard allows such distinctions
in this case.

If you think that it does not, please cite the relevant parts of the
standard which it would violate, and show how they apply. As far as I
can see, the only relevant part of the standard requires "same
representation and alignment", and that requirement would be met by an
implementation that used such an ABI.

... I believe that is a minority opinion. In
any case, there certainly are other well-recognized
contributors to c.l.c who have expressed a belief that
the Standard does not allow such distinctions (and so
that the code above would have to work).

Truth isn't a majority-vote issue. It doesn't matter how many people
disagree with me; what matters is whether or not I'm right. Feel free to
criticize the accuracy of my premises or the validity of my arguments,
but labeling my opinion a 'minority' opinion is irrelevant.

 

[Chris M. Thomasson]

[snip]

char *endp;
printf("endp is %p\n", endp);
printf("endp is %p\n", (void*)endp);

The first [printf line] is almost certainly safe; it would take a
deliberately perverse implementation to break it. [snip]

To say this more practically: there has never been, nor
will there ever be, an ISO-conforming C implementation in
which there is the slightest difference in run-time behavior
between these two cases.

Keep in mind that "practically" means that the any a absolute terms such
as "never" or "ever" should be understood in a non-absolute sense. In
reality, as opposed to "practicality", it's entirely possible that such an
implementation may some day be created, even if only for the purpose of
proving that it can be done.

IMVHO, it might be fairly useful for somebody to deliberately create a 100%
fully conforming __hard-core__ perverse implementation. It might be fun to
program for!

;^)

 

[James Kuyper]

Chris M. Thomasson wrote:
....

IMVHO, it might be fairly useful for somebody to deliberately create a
100% fully conforming __hard-core__ perverse implementation. It might be
fun to program for!

I've thought about creating an absolutely minimal implementation that
does conform 100%. Because of the #error directive (and only for that
reason) it must implement translation phases 1-4, which makes the
project sufficiently complicated to be interesting, without involving
anywhere near as much time as an implementation that would actually be
useful. However, it would NOT be "fun to program for", because it would
never translate and execute correctly any program other than the one
program it is required to do that for, and that one program is
functionally equivalent to "int main(void) {}".

 

[Tim Rentsch]

An irrelevant argument. It's essentially always possible to
define an ABI that distintuishes any two possibilities that
can be described. The only relevant question is, what
possibilities are allowed by the Standard? James's opinion
seems to be that the Standard allows such distinctions
in this case.

If you think that it does not, please cite the relevant parts of the
standard which it would violate, and show how they apply. [snip]

The arguments have been made here before. I'm not
going to restart the argument.

Truth isn't a majority-vote issue. It doesn't matter how many people
disagree with me; what matters is whether or not I'm right. Feel free
to criticize the accuracy of my premises or the validity of my
arguments, but labeling my opinion a 'minority' opinion is irrelevant.

There is no objective truth about what the Standard means.
You have your opinion about what the text means. Other
people have their opinions about what the text means.
The English language, even formal English, is inherently
difficult to make precise and unambiguous. Certainly
it is a fact that other people have expressed disagreement
with your views. Even if you think your view represents
the "truth", I don't think it's unreasonable to ask
that you acknowledge the non-consensus.

 

[Tim Rentsch]

[snip]

char *endp;
printf("endp is %p\n", endp);
printf("endp is %p\n", (void*)endp);

The first [printf line] is almost certainly safe; it would take a
deliberately perverse implementation to break it. [snip]

To say this more practically: there has never been, nor
will there ever be, an ISO-conforming C implementation in
which there is the slightest difference in run-time behavior
between these two cases.

Keep in mind that "practically" means that the any a absolute terms
such as "never" or "ever" should be understood in a non-absolute
sense. In reality, as opposed to "practicality", it's entirely
possible that such an implementation may some day be created, even if
only for the purpose of proving that it can be done.

It's entirely possible that the Earth will spontaneously
tunnel 93 million miles into the center of the Sun, but that
doesn't mean it's ever worth worrying about.

 

[Seebs]

There is no objective truth about what the Standard means.

I think there is some, but it may not resolve all questions.

There are certainly cases where there is reasonable dispute over the meaning
of a given hunk of text. On the other hand, if you were to release a C
compiler where INT_MAX was 366, I don't think there would be any plausible
argument that there was no objective truth as to whether or not you had
that part right.

-s

 

[Keith Thompson]

[snip]

char *endp;
printf("endp is %p\n", endp);
printf("endp is %p\n", (void*)endp);

The first [printf line] is almost certainly safe; it would take a
deliberately perverse implementation to break it. [snip]

To say this more practically: there has never been, nor
will there ever be, an ISO-conforming C implementation in
which there is the slightest difference in run-time behavior
between these two cases.

Keep in mind that "practically" means that the any a absolute terms
such as "never" or "ever" should be understood in a non-absolute
sense. In reality, as opposed to "practicality", it's entirely
possible that such an implementation may some day be created, even if
only for the purpose of proving that it can be done.

It's entirely possible that the Earth will spontaneously
tunnel 93 million miles into the center of the Sun, but that
doesn't mean it's ever worth worrying about.

It's far more likely that an implementation would treat char* and
void* pointers differently in some way; for example an optimizing
compiler might assume that a char* value won't be passed where a void*
value is expected, and perform some optimization based on that
assumption. (No, I can't think of a plausible optimization that this
would enable.)

The standard says that "The same representation and alignment
requirements are meant to imply interchangeability as arguments to
functions, return values from functions, and members of unions.", but
it says so only in a footnote. If we're going to take the standard
seriously, we must take seriously the statement in paragraph 6 of the
foreward:

Annexes D and F form a normative part of this standard; annexes
A, B, C, E, G, H, I, J, the bibliography, and the index are
for information only. In accordance with Part 3 of the ISO/IEC
Directives, this foreword, the introduction, notes, footnotes,
and examples are also for information only.

If the authors had meant to require char* and void* to be fully
interchangeable, they could easily have said so in normative text.

 

[Tim Rentsch]

I think there is some, but it may not resolve all questions.

There are certainly cases where there is reasonable dispute over the meaning
of a given hunk of text. On the other hand, if you were to release a C
compiler where INT_MAX was 366, I don't think there would be any plausible
argument that there was no objective truth as to whether or not you had
that part right.

I think I see the point you're making, but it is not
quite a direct response to the point I was making.

It's true that there is an objective test for whether
INT_MAX fails to be at least 32767.

However, there isn't any objective test (in the sense of
being scientifically measurable) that this result means that
implementation is not conforming. Almost all people would
agree that this result means it isn't conforming, but that
doesn't make the conclusion an objective test; it just
makes it an extremely strong consensus.

There is no objective truth about what the Standard means
because we don't have any way of measuring "meaning". We
can measure what people say it means, but that provides
objective truth only about what people are saying, not
about what the actual meaning (or "meaning") is.

Does that explain what I was trying to say any better?

 

[Tim Rentsch]

Tim Rentsch wrote:
[snip]

char *endp;
printf("endp is %p\n", endp);
printf("endp is %p\n", (void*)endp);

The first [printf line] is almost certainly safe; it would take a
deliberately perverse implementation to break it. [snip]

To say this more practically: there has never been, nor
will there ever be, an ISO-conforming C implementation in
which there is the slightest difference in run-time behavior
between these two cases.

Keep in mind that "practically" means that the any a absolute terms
such as "never" or "ever" should be understood in a non-absolute
sense. In reality, as opposed to "practicality", it's entirely
possible that such an implementation may some day be created, even if
only for the purpose of proving that it can be done.

It's entirely possible that the Earth will spontaneously
tunnel 93 million miles into the center of the Sun, but that
doesn't mean it's ever worth worrying about.

It's far more likely that an implementation would treat char* and
void* pointers differently in some way; [snip additional explanation]

I'd be happy to stipulate that it's quintillions of times more
likely than the Earth tunnelling to the center of the Sun.
It's still not likely enough to make it worth worrying about.
IMO, of course; other people have different criteria for
what they worry about.

 

[Seebs]

There is no objective truth about what the Standard means
because we don't have any way of measuring "meaning". We
can measure what people say it means, but that provides
objective truth only about what people are saying, not
about what the actual meaning (or "meaning") is.

Does that explain what I was trying to say any better?

Yeah. I disagree.

I think there is an objective truth, and I suspect we even know what it
is.

Language isn't ALWAYS precise enough for us to claim objective truth about
it, but sometimes it really is precise enough that we can say with
real confidence that something is true or false.

-s

 

[Tim Rentsch]

Yeah. I disagree.

I think there is an objective truth, and I suspect we even know what it
is.

Language isn't ALWAYS precise enough for us to claim objective truth about
it, but sometimes it really is precise enough that we can say with
real confidence that something is true or false.

I guess we mean different things by the word "objective".

 

[Keith Thompson]

I guess we mean different things by the word "objective".

If you reduce the meaning of the word "objective" to the point
that *nothing* can ever be objective, perhaps it's no longer a
useful word.

A C implementation with INT_MAX==366 does not conform to the standard.
That's objective enough for me.

 

[Tim Rentsch]

I guess we mean different things by the word "objective".

If you reduce the meaning of the word "objective" to the point
that *nothing* can ever be objective, [snip consequent].

I haven't done that.

A C implementation with INT_MAX==366 does not conform to the standard.
That's objective enough for me.

This sense of 'objective' is more like "indisputable". I think
almost all people would agree with that conclusion. But it's
still just opinion on what the meaning is, even if it happens
that all the opinions agree.

 

[Flash Gordon]

There is no objective truth about what the Standard means
because we don't have any way of measuring "meaning". We
can measure what people say it means, but that provides
objective truth only about what people are saying, not
about what the actual meaning (or "meaning") is.

Does that explain what I was trying to say any better?
Yeah. I disagree.

I think there is an objective truth, and I suspect we even know what it
is.

Language isn't ALWAYS precise enough for us to claim objective truth about
it, but sometimes it really is precise enough that we can say with
real confidence that something is true or false.
I guess we mean different things by the word "objective".

If you reduce the meaning of the word "objective" to the point
that *nothing* can ever be objective, [snip consequent].

I haven't done that.

You have, because to evaluate any statement, including in science, you
have to know what it means, and you are saying that if you need to know
what it means you cannot test it objectively.

This sense of 'objective' is more like "indisputable". I think
almost all people would agree with that conclusion. But it's
still just opinion on what the meaning is, even if it happens
that all the opinions agree.

Well, you seem to be in a minority on this point. I would say that it
can be determined objectively tht such an implementation does not
conform to the C standard.