[META] Talking about talking about C.

[Tim Rentsch]

Excuse me, but I won't note that. The mere fact that the description
of the 'z' modifier doesn't mention that the argument will have been
promoted doesn't count as an assumption that it is not promoted
(regardless of the descriptions of other modifiers).

It's a fair statement to say that the /description/ implicitly
assumes that a size_t argument is not promoted, because it
doesn't make sense otherwise. Whether that assumption can be
imputed to the Standard as a whole is a separate question.

 

[Ben Bacarisse]

[snip]

An implementor who hated you could in theory use 64 for all the standard
unsigned integer types except unsigned char, and then have the 16-bit
and 32-bit types be extended unsigned integer types.

I think you may be missing a much more devious possibility, namely

#define CHAR_BIT 16
typedef _Bool size_t;

As far as I can tell an implementation could have this combination
of definitions and still be conforming....

size_t sz = sizeof(long);

will leave sz == 1 if size_t is a synonym for _Bool, and that's surely
not permitted.

Have you forgotten 6.3p2?

Conversion of an operand value to a compatible type
causes no change to the value or the representation.
^^^^^^^^^^^^^^^^^^^^^^

No, not exactly. I'd forgotten that assignment does no promotion -- it
just coverts.

Is an implementation conforming if you can't pass a size_t to a function
without a prototype? I think calling

extern void *my_alloc();
long *lp = my_malloc(sizeof *lp);

does what I was trying to do -- the argument is promoted and then
assigned so it is an int that is assigned to the (non-prototype)
size_t parameter (not shown).

I think your analysis about what value would be passed is
correct. That wouldn't necessarily cause the implementation
to be non-conforming, except that the question has been
rendered moot by dSpam's observation about the inconsistency
of _Bool having a width greater than 1. I give.

I am surprised! When you pointed out 6.3p2 (above) I assumed you had
6.3.1.2p1 in mind at the same time so I did not bring it up. I assumed
you took the more general remark (6.3 is about all conversions) as
taking precedence. Oh well...

[1] Which says:

When any scalar value is converted to _Bool, the result is 0 if the
value compares equal to 0; otherwise, the result is 1.

 

[Tim Rentsch]

[snip]

An implementor who hated you could in theory use 64 for all the standard
unsigned integer types except unsigned char, and then have the 16-bit
and 32-bit types be extended unsigned integer types.

I think you may be missing a much more devious possibility, namely

#define CHAR_BIT 16
typedef _Bool size_t;

As far as I can tell an implementation could have this combination
of definitions and still be conforming....

size_t sz = sizeof(long);

will leave sz == 1 if size_t is a synonym for _Bool, and that's surely
not permitted.

Have you forgotten 6.3p2?

Conversion of an operand value to a compatible type
causes no change to the value or the representation.
^^^^^^^^^^^^^^^^^^^^^^

No, not exactly. I'd forgotten that assignment does no promotion -- it
just coverts.

Is an implementation conforming if you can't pass a size_t to a function
without a prototype? I think calling

extern void *my_alloc();
long *lp = my_malloc(sizeof *lp);

does what I was trying to do -- the argument is promoted and then
assigned so it is an int that is assigned to the (non-prototype)
size_t parameter (not shown).

I think your analysis about what value would be passed is
correct. That wouldn't necessarily cause the implementation
to be non-conforming, except that the question has been
rendered moot by dSpam's observation about the inconsistency
of _Bool having a width greater than 1. I give.

I am surprised! When you pointed out 6.3p2 (above) I assumed you had
6.3.1.2p1 in mind at the same time so I did not bring it up.

Very kind of you to think me so considered.

I assumed
you took the more general remark (6.3 is about all conversions) as
taking precedence. Oh well...

[1] Which says:

When any scalar value is converted to _Bool, the result is 0 if the
value compares equal to 0; otherwise, the result is 1.

I don't know any reason why 6.3p2 should be taken as having
precedence over 6.3.1.2p1. I suppose one could make a general
argument that something higher up the organizational tree of the
document has precedence over something lower down, but I don't
think the Standard actually says that, and I haven't undertaken
any research to gather evidence for such a proposition. Of
course, if 6.3p2 _is_ meant to take precedence over 6.3.1.2p1,
then we're back where we started as far as the possibility of
wider _Bool's go. I wouldn't want to argue such a thing without
doing a fair amount of research reading the Standard, and that's
more time than I think I should allocate right now. So I'm
content to leave it unsettled for the time being.

As to the question of size_t, there is at least indirect evidence
(under the discussion of fprintf() format items) that size_t may
not be a synonym for _Bool, so I guess I should concede on that
specific point, at least as far as comp.lang.c discussion goes.

 

[David Thompson]

On Wed, 27 Oct 2010 22:55:33 +0100, Ben Bacarisse

Is an implementation conforming if you can't pass a size_t to a function
without a prototype? I think calling

extern void *my_alloc();
long *lp = my_malloc(sizeof *lp);

does what I was trying to do -- the argument is promoted and then
assigned so it is an int that is assigned to the (non-prototype)
size_t parameter (not shown).

If I have correctly untangled your negatives, yes it is (must be)
allowed to pass size_t -- to a 'user' function (one written in C).

6.5.2.2p6 formerly 6.3.2.2 defines the cases where a call, using
either prototype or K&R1 declaration, works with a definition, ditto.

You absolutely can define K&R1 taking size_t and call K&R1 passing
size_t and it works, and I'm pretty sure that's what you mean your
example to be. IF size_t is narrower than int or u-int, yes K&R1 call
promotes it and K&R1 definition demotes it back. But I don't think
I've ever seen a platform where it makes sense for size_t to be
narrower than u/int. The case that has occurred frequently in the
past, and again now with 64-bit machines, is size_t wider than int.
Then K&R1 call passes it as-is and K&R1 definition takes it as-is.

You can define with SOME prototype and call K&R1 with size_t -- but
that prototype type is implementation dependent. If you define K&R1
with size_t, it's implementation dependent whether you can make any
prototype call that matches and if so what.

But it isn't clear the same rules apply to standard library functions,
which needn't be implemented in C -- and some at least usually aren't.
On most(?) implementations library functions do use the same calling
sequence(s) as user functions, but it isn't explicitly required.
Although a call through a (compatible) pointer must handle either.
(Plus an apparent library call may actually be a macro invocation,
but you can #undef or (parenthesize) to get an actual call.)

 

[Ben Bacarisse]

On Wed, 27 Oct 2010 22:55:33 +0100, Ben Bacarisse


If I have correctly untangled your negatives, yes it is (must be)
allowed to pass size_t -- to a 'user' function (one written in C).

6.5.2.2p6 formerly 6.3.2.2 defines the cases where a call, using
either prototype or K&R1 declaration, works with a definition, ditto.

You absolutely can define K&R1 taking size_t and call K&R1 passing
size_t and it works, and I'm pretty sure that's what you mean your
example to be. IF size_t is narrower than int or u-int, yes K&R1 call
promotes it and K&R1 definition demotes it back. But I don't think
I've ever seen a platform where it makes sense for size_t to be
narrower than u/int. The case that has occurred frequently in the
past, and again now with 64-bit machines, is size_t wider than int.
Then K&R1 call passes it as-is and K&R1 definition takes it as-is.

Quite, but the example was constructed to show the consequences of an
insanely perverse decision: having a wide _Bool and size_t a typedef for
it! Because the size_t (in fact a _Bool) gets promoted and then
assigned to another size_t (again a _Bool of course) the result will be
0 or 1 rendering the call pointless. The "trick" in the example is that
the "demotion" dramatically affects the value.

All this assuming that 6.3 p2 "rules" over 6.3.1.2 p1 when they
conflict or my initial example ('size_t s = sizeof(long);') would have
been enough.

<snip>

 

[Jon]

have the beginnings of a parseable language

Your referent is incorrect.

 

[Guest]

It's a fair statement to say that the /description/ implicitly
assumes that a size_t argument is not promoted, because it
doesn't make sense otherwise...

I don't see why it doesn't make sense otherwise, if a size_t argument
can be promoted (in some implementation where size_t's integer
conversion rank is less
than or equal to the rank of int), but doesn't have to (in every
implementation).

 

[Tim Rentsch]

It's a fair statement to say that the /description/ implicitly
assumes that a size_t argument is not promoted, because it
doesn't make sense otherwise...

I don't see why it doesn't make sense otherwise, [snip]

Maybe you should go back and read the relevant passage together
with the surrounding context again. It is the description that
wouldn't make sense; what interpretations might or might not
make sense is another matter.

 

[Guest]

I don't see why it doesn't make sense otherwise, [snip]

Maybe you should go back and read the relevant passage together
with the surrounding context again.  It is the description that
wouldn't make sense;  what interpretations might or might not
make sense is another matter.

Your suggestion is not conducive, since it conveys no further
information.
Obviously, it doesn't make sense to discuss whether the description
makes sense when it makes sense to me (what I tried to explain in the
part you snipped) and it doesn't make sense to you (what you didn't
try to explain, albeit it admittedly is difficult to explain why
something doesn't make sense).

 

[Tim Rentsch]

... The mere fact that the description
of the 'z' modifier doesn't mention that the argument will have been
promoted doesn't count as an assumption that it is not promoted
(regardless of the descriptions of other modifiers).

It's a fair statement to say that the /description/ implicitly
assumes that a size_t argument is not promoted, because it
doesn't make sense otherwise...

I don't see why it doesn't make sense otherwise, [snip]

Maybe you should go back and read the relevant passage together
with the surrounding context again. It is the description that
wouldn't make sense; what interpretations might or might not
make sense is another matter.

Your suggestion is not conducive, since it conveys no further
information.

Perhaps it wasn't conveyed to you, but there is additional
information available; I was careful not to just repeat myself.

Obviously, it doesn't make sense to discuss whether the description
makes sense when it makes sense to me (what I tried to explain in the
part you snipped) and it doesn't make sense to you (what you didn't
try to explain, albeit it admittedly is difficult to explain why
something doesn't make sense).

I think you are failing to distinguish between the description
making sense and an interpretation of the description making
sense.

 

[Guest]

... The mere fact that the description
of the 'z' modifier doesn't mention that the argument will have been
promoted doesn't count as an assumption that it is not promoted
(regardless of the descriptions of other modifiers).
It's a fair statement to say that the /description/ implicitly
assumes that a size_t argument is not promoted, because it
doesn't make sense otherwise...
I don't see why it doesn't make sense otherwise, [snip]
Maybe you should go back and read the relevant passage together
with the surrounding context again.  It is the description that
wouldn't make sense;  what interpretations might or might not
make sense is another matter.

Your suggestion is not conducive, since it conveys no further
information.

Perhaps it wasn't conveyed to you, but there is additional
information available;  I was careful not to just repeat myself.

Still, you are repeating yourself below. I can assure you that I read
your remarks attentively, so repetition really is not beneficial.
When there were additional information available, you should be able
to cite it as well as to draw logical conclusions from it and, not to
be forgotten, state your derivation.

I think you are failing to distinguish between the description
making sense and an interpretation of the description making
sense.

I think you are failing to explain why you think that.

 

[Tim Rentsch]

... The mere fact that the description
of the 'z' modifier doesn't mention that the argument will have been
promoted doesn't count as an assumption that it is not promoted
(regardless of the descriptions of other modifiers).

It's a fair statement to say that the /description/ implicitly
assumes that a size_t argument is not promoted, because it
doesn't make sense otherwise...

I don't see why it doesn't make sense otherwise, [snip]

Maybe you should go back and read the relevant passage together
with the surrounding context again. It is the description that
wouldn't make sense; what interpretations might or might not
make sense is another matter.

Your suggestion is not conducive, since it conveys no further
information.

Perhaps it wasn't conveyed to you, but there is additional
information available; I was careful not to just repeat myself.

Still, you are repeating yourself below.

If you think I was just repeating myself you haven't understood
what I said.

I can assure you that I read
your remarks attentively, so repetition really is not beneficial.
When there were additional information available, you should be able
to cite it as well as to draw logical conclusions from it and, not to
be forgotten, state your derivation.

Information is not the same as argument. I'm not making an
argument, just presenting information.

I think you are failing to explain why you think that.

I was (and am) making no effort to explain why I believe
that statement is true. Do you mean to say, by analogy,
that you are making no effort to distinguish between the
description making sense and an interpretation of the
description making sense?

 

[Guest]

... The mere fact that the description
of the 'z' modifier doesn't mention that the argument will have been
promoted doesn't count as an assumption that it is not promoted
(regardless of the descriptions of other modifiers).
It's a fair statement to say that the /description/ implicitly
assumes that a size_t argument is not promoted, because it
doesn't make sense otherwise...
I don't see why it doesn't make sense otherwise, [snip]
Maybe you should go back and read the relevant passage together
with the surrounding context again.  It is the description that
wouldn't make sense;  what interpretations might or might not
make sense is another matter.
Your suggestion is not conducive, since it conveys no further
information.
Perhaps it wasn't conveyed to you, but there is additional
information available;  I was careful not to just repeat myself.

Still, you are repeating yourself below.

If you think I was just repeating myself you haven't understood
what I said.

I did not write "just" (and yes, I know you wrote it).
One can identify a repetition in your phrases "It is the description
that wouldn't make sense; what interpretations might or might not
make sense is another matter" and "I think you are failing to
distinguish between the description making sense and an interpretation
of the description making sense" even without understanding what you
said or wanted to say.

Information is not the same as argument.  I'm not making an
argument, just presenting information.

If you are regarding "the debate technique of failing to rigorously
address an argument in an attempt to bypass the argument altogether"

I was (and am) making no effort to explain why I believe
that statement is true.

Thank you for clarifying that. See, I am making no effort to
understand people who are making no effort to explain their beliefs.

 Do you mean to say, by analogy,
that you are making no effort to distinguish between the
description making sense and an interpretation of the
description making sense?

I prefer logic to analogy. Since "interpret" means "make sense of",
you have in my opinion entered an uncalled-for meta-level of
reflection.
Your original statement was that the description of the 'z' modifier
doesn't make sense unless it implicitly assumes that a size_t argument
is not promoted. It would have subserved the discussion if you had
concentrated on explaining why you believe that statement is true
instead of divagating.

 

[Tim Rentsch]

... The mere fact that the description
of the 'z' modifier doesn't mention that the argument will have been
promoted doesn't count as an assumption that it is not promoted
(regardless of the descriptions of other modifiers).

It's a fair statement to say that the /description/ implicitly
assumes that a size_t argument is not promoted, because it
doesn't make sense otherwise...

I don't see why it doesn't make sense otherwise, [snip]

Maybe you should go back and read the relevant passage together
with the surrounding context again. It is the description that
wouldn't make sense; what interpretations might or might not
make sense is another matter.

Your suggestion is not conducive, since it conveys no further
information.

Perhaps it wasn't conveyed to you, but there is additional
information available; I was careful not to just repeat myself.

Still, you are repeating yourself below.

If you think I was just repeating myself you haven't understood
what I said.

I did not write "just" (and yes, I know you wrote it).
One can identify a repetition in your phrases "It is the description
that wouldn't make sense; what interpretations might or might not
make sense is another matter" and "I think you are failing to
distinguish between the description making sense and an interpretation
of the description making sense" even without understanding what you
said or wanted to say.

The key thing is I wasn't repeating any main point. I used
many of the same words, sure, but in each case the main
point was new.

If you are regarding "the debate technique of failing to rigorously
address an argument in an attempt to bypass the argument altogether"
<http://en.wikipedia.org/wiki/Handwaving> as "presenting information",
then I concede that you are presenting information.

You're the one who is interested in arguing; I'm not,
either by handwaving or by any other method.

Thank you for clarifying that. See, I am making no effort to
understand people who are making no effort to explain their beliefs.

Oh. So you're responding to my comments even though you
have made no effort to understand them?

I prefer logic to analogy. Since "interpret" means "make sense of",
you have in my opinion entered an uncalled-for meta-level of
reflection.

Is that a fancy way of saying you just aren't going to answer the
question?

Your original statement was that the description of the 'z' modifier
doesn't make sense unless it implicitly assumes that a size_t argument
is not promoted.

What I actually said is in fact slightly different than
that, but let's ignore that for now.

It would have subserved the discussion if you had
concentrated on explaining why you believe that statement is true
instead of divagating.

You may find this hard to believe, but I am not posting comments
here solely for your benefit. My remarks served the discussion
just fine. You're welcome to your opinion, but only if in return
you grant that others are welcome to their opinions. Okay?