multi dimensional arrays as one dimension array

[vippstar]

The subject might be misleading.
Regardless, is this code valid:

#include <stdio.h>

void f(double *p, size_t size) { while(size--) printf("%f\n", *p++); }
int main(void) {
double array[2][1] = { { 3.14 }, { 42.6 } };
f((double *)array, sizeof array / sizeof **array);
return 0;
}

Assuming casting double [2][1] to double * is implementation defined
or undefined behavior, replace the cast with (void *).

Since arrays are not allowed to have padding bytes in between of
elements, it seems valid to me.

[Tim Rentsch]

James Kuyper <ja*********@verizon.netwrites:

Tim Rentsch wrote:

James Kuyper <ja*********@verizon.netwrites:

Tim Rentsch wrote:

...

>Which view is more reasonable:

A. Pointer conversion yields a pointer to the same object as
the original (assuming no alignment problems); or
This is clearly impossible in cases where the new pointer type points at
an object of a different size than the original. What I think was the
intent of the committee is that whenever a pointer conversion is
actually permitted, it results in a pointer to an object with the same
starting location in memory. I consider it a defect of the standard that
there is no wording anywhere which says so in the general case, only in
a couple of special cases.

B. Pointer conversion follows a strict constructionist view -
the only thing you can do with a converted pointer is
convert it back to the original type and compare it against
the unconverted original (assuming non-char types, etc)?

Of course, no one really believes (B); if they did, then they
should insist that a code sequence like
I believe that in a great many cases, (B) is the only thing the standard
actually says, and that in most of those cases this was in fact the
committee's intent. The following code fragment is not one of those cases:

I notice you didn't answer the question about which view is more
reasonable.

What I said does answer that question, but not in the fashion you
wanted.

Answering a different question is not the same as answering the
original question. Perhaps you missed the point of what I was
asking.

Whether A or B is more reasonable depends upon context; the
answer is different in different contexts, and is sometimes "neither
one". My answer reflects that fact.

That "fact" is not a fact but an opinion. I understand that
what you wrote reflects your opinion.

Your comment in another post about using a legal system analogy is
illuminating. In law, it's perfectly acceptable to argue several
inconsistent theories at once; arguing one theory doesn't preclude
arguing another, inconsistent, theory in the very same breath. All
that matters is whether the arguments convince a jury (or judge).

It matters if the other side catches the lawyer at such sophistry, and
if the lawyer has integrity, it should matter to the lawyer as well.

I take it you haven't had much exposure to legal ethics. Not
only is it not unethical to offer such an argument, if there's
reason to believe it helps win the case then it's unethical NOT
to offer such an argument. Whether or not the other side can
take advantage of an inconsistent argument is beside the point as
far as ethics is concerned; getting caught might mean the
presenter was incompentent, but there's nothing unethical about
it.

I believe that I have a single consistent interpretation that covers all
of the relevant cases; this interpretation include recognition of
something I consider a defect in the standard, which complicates any
description of that interpretation. It means that in some cases I have
to say that "a literal interpretation of the standard says this" but "I
believe that the committee's intent was this other thing"; that's not
inconsistency, or at least it's not my inconsistency.

The issue is not whether your notion of what the standard "means"
is consistent, but whether the logic by which you arrive at that
interpretation makes sense. You seem to follow different rules
of reasoning in different circumstances.

I find this frustrating, and I wish they would fix it, but I've been
complaining about it on comp.std.c for about a decade. I have yet to
convince anyone on the committee that it's sufficiently clearly wrong
and important enough for them to champion the idea for me; and I lack
the spare time to champion it myself. One thing that is quite clear is
that most of the committee members I've talked with about this issue
feel that the standard clearly states to be true precisely what I've
said was their intent, and that it therefore doesn't need to be modified
to express that intent more clearly. That doesn't prove that a Defect
Report filed on this issue would be decided in that fashion, but it does
make it more likely.

The last conclusion seems backwards. Your rules for how people
should understand what the standard says clearly differ from
those of people on the committee, since you think it should be
changed and they think it's clear enough as is; that fact makes
it less likely that your interpretation matches the committee's
interpretation, not more likely.

[Tim Rentsch]

James Kuyper <ja*********@verizon.netwrites:

Tim Rentsch wrote:

James Kuyper <ja*********@verizon.netwrites:

Tim Rentsch wrote:
...

...

As such, neither mathematics, nor literary criticism, nor science
provides the appropriate analogy for how this document should be read.
The right analogy is the legal system. Some obnoxious regulars regularly
refer to some of the other regulars as "Bible thumpers", because we
routinely cite sections of the standard. Well, lawyers are also noted
for their frequent use of citations, and that is a much more appropriate
analogy.

The intent of the lawmakers is always a relevant issue in a legal case,
but there are strict (though frequently debated) limits on how far a
judge should go in using the "intent" of the law to influence his
interpretation of what the law actually says.

I notice you didn't include a disclaimer that you are not a
lawyer. :)

My foreign-born in-laws constantly come to me for advice on the American
legal system, about which I know a great deal more than they do. In
particular, I know enough to include such a disclaimer with every answer
I give them.

Unlike true lawyers, there's no legal requirement that language lawyers
have credentials. Therefore I'm just as much of a language lawyer as
anyone, and far better qualified to be one than most (modesty is clearly
not one of my virtues :-). No disclaimer is needed.

I apologize for taking your joking comment seriously; but I couldn't
come up with a good joking response.

If we take the legal system as our model for deciding questions
about the standard, then the only real test for comparing two
opposing interpretations would be to offers arguments before some
court, and let the court decide. I don't find this model very
useful, since there are no such courts.

The C committee is the relevant court, and you bring cases before that
court by filing Defect Reports. Just as with real courts, the C
committee sometimes makes bad or incorrect decisions, but they are
nonetheless the highest relevant authority. In principle, ISO has some
authority over them, but I doubt that ISO's authority would ever be used
to decide a technical issue over the meaning of the standard. ISO is
mainly concerned with procedural issues about how the standard is created.

This argument - more of a strawman position, really - just isn't
convincing. First, for most implementors and for almost all
developers, trying to decide what the standard means by submitting
DR's simply isn't practical. Second, if you really believed that
standard issues should be resolved through filing Defect Reports
then when questions on the standard come up you would file one;
looking through the published DR's I didn't find your name in
a single one.

I think a more accurate description of your stance in these
discussions is political - it seems like you feel free to use
just about any kind of argument that you think might sway the
audience (or "jury"). If that's what you want to do, that's okay
with me - I can choose to engage (or not engage) within that
arena. And if you want to do something different, I'd love to
hear what kinds of more specific reasoning rules you'd be willing
to agree to.

[Tim Rentsch]

James Kuyper <ja*********@verizon.netwrites:

Tim Rentsch wrote:

James Kuyper <ja*********@verizon.netwrites:

...

6.3.2.2p2 is the relevant statement: "For any qualifier q, a pointer to
a non-q-qualified type may be converted to a pointer to the q-qualified
version of the type; the values stored in the original and converted
pointers shall compare equal". In this context 'q' refers to the
qualifier "const".

I'm assuming you meant to write 6.3.2.3p2 (for 6.3.2.2p2).

You're correct. Sorry for the typo.

Per 6.5.9p6, the fact that these pointers shall compare equal implies
that they point at the same object.

Your logic is faulty. Two pointers can compare equal and yet still
not be pointing at the same object. The stated conclusion is just not
a valid deduction.

Keep in mind that 6.5.9p6 isn't of the form "if A, then B", which is of
course not reversible. It is of the form "if AND ONLY IF A, then B",
from which it is perfectly valid to conclude "if B, then A".

Yes it is an IFF, but that doesn't make your earlier logic correct.

Sure; two null pointers could compare equal, but 'z' can't be null.

Two pointers past the end of the same array could compare equal, but
again 'z' can't be such a pointer.

Yes, z can't, but cpz can. Since the standard doesn't say how
conversion works (except that the pointers compare equal), we can't
conclude that cpz points to the same object, or indeed that it points to
any object.

The only way permitted by the standard for cpz to compare equal to z
without pointing at the same object is if it points one past the end of
the end of an array object that happens to immediately precede 'z' in
memory. However, the reason for that exception is to allow commonplace
implementations where such a pointer is simultaneously a pointer
one-past-the end of one array AND a pointer to the first element of the
second. I will grant that the wording used falls a little short of
actually guaranteeing that. I am sure that the committee's intent was
that wherever the standard guarantees that two non-null pointers to
objects must compare equal, it should be taken as meaning that they
point at the same object.

Here's the problem. You're sure of the committee's intent one way
in one case, and another way in another case. You do have your
logic, but it's not objective enough or consistent enough to
draw any useful conclusions from it.

Given that we know that cpz points at z[0], I don't see any basis for
claiming that the behavior of that code is undefined. However, that
would no longer be the case if z were declared as, for example, an array
of doubles.

Does this mean you think

printf( "*(unsigned*)z == %u\n", *(unsigned*)z );

has defined behavior, or undefined behavior?

The standard doesn't say where (unsigned*)z points; it follows that
dereferencing it could have undefined behavior. I consider this a defect
in the standard, and unlikely to have been the intent of the committee.
In practice, unless alignment is an issue, I wouldn't expect anything to
actually go wrong.

How come we're allowed to use the committee's intentions in the first
case but not the second case? Or is it based on how _sure_ you are of
the committee's intentions?

You see the problem - there's no way to draw any useful conclusions if
the rules for what inferences are valid change from case to case.
Ultimately all you're saying is that your opinion is X in one case and
Y in another.