null function pointer?

[Tim Rentsch]

The property of being complete or incomplete can be different at
different points in a program text. I don't see anything very
mysterious about that.

"Completeness" is not a type's optional property; it is part of its
specification (an attribute).

6.2.5#1:
# [...] Types are partitioned into object types (types that describe
# objects), function types (types that describe functions),
# and incomplete types (types that describe objects but lack
# information needed to determine their sizes).

[...]
Please don't take this the wrong way, but continuing to respond to the
obtuseness in these messages has grown tiresome.

To be fair, although some of Stan's other interpretations seem to be
stretches, he does seem to have identified some inconsistency in the
wording of the standard above.

I agree there are passages that may allow more than one interpretation,
at least locally, and perhaps should be reviewed with an eye toward
making the language used in the Standard more clear or less ambiguous.
Having said that, here is the flip side.

1. The different interpretations don't result in any difference in what
C constructs are allowed or what their semantics are.

2. Ergo, whether the different interpretations are reasonable or they
aren't, they are not "right" or "wrong", any more than the lambda
calculus, recursive function theory, or Turing machines are the "right"
interpretation for what is computable; the different interpretations
are simply different ways of thinking about the same logical
consequences. It is "a distinction without being a difference".

3. Because of (2), it seems reasonable to follow the interpretation
that most people use, and that fits better with all the language used
in the Standard. All the developers I've asked (less than half a
dozen, but several) follow the interpretation that there is just one
type, initially incomplete (or undefined) but filled in later; also
the language used in the Standard seems to fit that interpretation
(IMO) better than other interpretations, as I've previously explained.

4. By contrast, it seems that Stan is the only one who follows the
interpretation he puts forward. Perhaps there are others who do also,
but I'm not aware of any.

5. Since it makes no difference to the C language, and since I feel
like I've explained my views adequately, I tried to disengage from the
conversation as politely as possible. Perhaps my phrasing was a little
blunt, but I made an effort to remark only about the content of the
messages and not about who wrote them. If someone has something else
to offer then maybe I'd get interested again; but, usually I try to
avoid "argument for the sake of arguing", and that's where it seems
like things were in the message I last responded to.

 

[Mabden]

The property of being complete or incomplete can be different at
different points in a program text. I don't see anything very
mysterious about that.

"Completeness" is not a type's optional property; it is part of its
specification (an attribute).

6.2.5#1:
# [...] Types are partitioned into object types (types that describe
# objects), function types (types that describe functions),
# and incomplete types (types that describe objects but lack
# information needed to determine their sizes).

[...]

I agree there are passages that may allow more than one interpretation,
at least locally, and perhaps should be reviewed with an eye toward
making the language used in the Standard more clear or less ambiguous.
Having said that, here is the flip side.

1. The different interpretations don't result in any difference in what
C constructs are allowed or what their semantics are.

2. Ergo, whether the different interpretations are reasonable or they
aren't, they are not "right" or "wrong", any more than the lambda
calculus, recursive function theory, or Turing machines are the "right"
interpretation for what is computable; the different interpretations
are simply different ways of thinking about the same logical
consequences. It is "a distinction without being a difference".

3. Because of (2), it seems reasonable to follow the interpretation
that most people use, and that fits better with all the language used
in the Standard. All the developers I've asked (less than half a
dozen, but several) follow the interpretation that there is just one
type, initially incomplete (or undefined) but filled in later; also
the language used in the Standard seems to fit that interpretation
(IMO) better than other interpretations, as I've previously explained.

If someone has something else
to offer ...

If you look for it in quietude, it goes and crouches in clamor;
If you look for it in clamor, then it stands in quietude.
If you want to place it in the realm of nothingness, yet it is a living
thing.


Well, you asked....

 

[Tim Rentsch]

If you look for it in quietude, it goes and crouches in clamor;
If you look for it in clamor, then it stands in quietude.
If you want to place it in the realm of nothingness, yet it is a living
thing.


Well, you asked....

Sir:

You are guilty of willful misunderstanding. Please
refrain from doing so again in the future.

 

[Chris Torek]

In Sea, is {0} a valid initializer for any (complete) object type?

Presumably "no".

If so, the first rule is arguably violated; if not, I for one
wouldn't use it.

Note that:

struct S { int x; char *p; } var = { 0 };

*would* initialize var.p to nil, so perhaps Sea should allow empty
brackets as the "universal initializer":

complete_object_type var = {};

(Out of curiosity, what is the referent for the pronoun "it" at
the end of the quote above? The language, or {0}?)

 

[Michael Wojcik]

Presumably "no".


... perhaps Sea should allow empty
brackets as the "universal initializer":

complete_object_type var = {};

That seems reasonable.

(Out of curiosity, what is the referent for the pronoun "it" at
the end of the quote above? The language, or {0}?)

The language; I was feeling cranky, and I like having a universal
initializer.

--
Michael Wojcik (e-mail address removed)

Memory, I realize, can be an unreliable thing; often it is heavily coloured
by the circumstances in which one remembers, and no doubt this applies to
certain of the recollections I have gathered here. -- Kazuo Ishiguro