Hello Readers,

Please respond with the _highest_ levels of pedantry you can muster
up.

This e-mail is in regards to how a C translator/compiler should handle
the expression:

*(char *)0

Consider the following program:

int main(void) {
  (void)*(char *)0;
  return 0;
}

The question is: Does the above program imply undefined behaviour?

References here from the C standard draft with filename 'n1256.pdf'.

Looking at the second line of the program:

(A) "Expression and null statements", 6.8.3, Semantics 2:

"The expression in an expression statement is evaluated as a void
expression for its side effects."

The footnote 134 adds, "Such as assignments, and function calls which
have side effects."

This appears to describe the second line of the program pretty nicely.

(B) "void", 6.3.2.2, point 1:

"The (nonexistent) value of a void expression...shall not be used in
any way...  If an expression of any other type is evaluated as a void
expression, its value or designator is discarded.  (A void expression
is evaluated for its side effects.)"

Note that this doesn't read "_only_ evaluated for its side effects."
However, (A) doesn't read "_only_", either, but one can get that
impression due to the explicit mentioning of "side effects" in both
(A) and (B).

(C) "Address and indirection operators", 6.5.3.2, Semantics 4:

"...if [the operand] points to an object, the result is an lvalue
designating the object."

(D) "Address and indirection operators", 6.5.3.2, Semantics 4:

"If the operand has type 'pointer to type', the result has type
'type'.

(E) "Address and indirection operators", 6.5.3.2, Semantics 4:

"...If an invalid value has been assigned to the pointer, the
behavior...is undefined."

The footnote 87 adds, "Among the invalid values for dereferencing a
pointer...are a null pointer..."  This footnote is referenced from
(E).

(C), (D) and (E) are in regards to the unary '*' operator, and where I
perceive a challenge in interpretation.  This operator is followed by
a cast-expression, so such an expression would make up the operand, if
I'm not mistaken.  The particular cast-expression in line two of the
program is '(char *)0'.  _Is_this_an_assigned_value_?
_Is_"assigned"_meant_there_purposefully_or_not_?

(F) "object", 3.13, point 1:

"region of data storage in the execution environment, the contents of
which can represent values"

(G) "value", 3.17, point 1:

"precise meaning of the contents of an object when interpreted as
having a specific type"

By (G), is '(char *)0' a value?  Maybe not by (G), but there are other
parts in the text which read as though expressions can have values,
without needing any objects.  The "integer constant expression with
the value 0" in (H) below is such an example.  Perhaps it _may_be_ a
value iff _used_ for its value?

(H) "Pointers", 6.3.2.3, points 3 and 4:

"An integer constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant.  If
a null pointer constant is converted to a pointer type, the resulting
pointer, called a null pointer, is guaranteed to compare unequal to a
pointer to any object or function."

"Conversion of a null pointer to another pointer type yields a null
pointer of that type.  Any two null pointers shall compare equal."

By (H), it would appear that '(char *)0' is a pointer and a null
pointer.  Also, it cannot point to an object.  Thus, this operand does
not point to an object for (C), and we must forget (C)'s application
to our case.

(I) "Cast operators", 6.5.4, Semantics 4:

"Preceding an expression by a parenthesized type name converts the
value of the expression to the named type. ..."

Another example where an expression _has_ a value.  But the text reads
"value of the expression" to describe the _use_ of that particular
property of the expression.  Similar to "...expression with the value
0" in (H).

The footnote 89 adds, "A cast does not yield an lvalue."

By (I), it would appear that '(char *)0' converts the value of '0' to
a 'char *' type.  But is this value _assigned_to_a_pointer_ in (E)?
We do now know that the type for this operand is 'char *' for (D).
Thus the unary '*' operator should yield a result with type 'char', by
(D).

(J) "The sizeof operator", 6.5.3.4, Semantics 2:

"...The size is determined from the type of the operand. ...the
operand is not evaluated."

In this, we see that a particular property "type" for the operand is
used.  "...the operand is not evaluated" suggests that there is at
least one case in the C language where an expression can yield a
result with a type while avoiding that expression's evaluation.

But compare (J) with (A) and (B), which do describe evaluation, albeit
with "non-existant" values.  (A) and (B) both mention side effects.

(K) "Program execution", 5.1.2.3, point 2:

"Accessing a volatile object, modifying an object, modifying a file,
or calling a function that does any of those operations are all side
effects, which are changes in the state of the execution environment.
Evaluation of an expression may produce side effects."

From (K), '*(char *)0' does not access a volatile object, nor does it
modify an object (remember that there's no assignment!), nor does it
modify a file, nor call a function doing any of those operations.  It
does not appear to have any "side effects" at all.  Iff '(char *)0'
can itself be considered an object (beyond being a pointer, a null
pointer, a cast expression, and having type 'char *'), then we _still_
don't have any side effects.  For example: Would it be a volatile
object?  Are we modifying an object?

If we constrain (A) and (B) to mean "_only_ evaluated for any side
effects", then (K) suggests '*(char *)0' has no side effects.  This
constraint is not explicitly in the text, however.  One can ponder if
it is meant or not.

Now then, let us please consider how '*(char *)0' evaluates if we take
"...If an invalid value has been assigned to the pointer..." from (E)
_literally_.  There is no assignment here.  There is conversion of the
value of the expression '0' to a null pointer.  Then we are applying
the '*' operator to that null pointer.  The result has of this
application yields a result with type 'char'.  According to (J), this
expression can even be an operand to 'sizeof', since it has a type.
There is no object and there is no value.

Is there undefined behaviour?  Perhaps consider it in terms of
variables and constants: In '*(char *)0', everything is constant.  In
'*(char *)x', x is variable.  Could be suppose that "has been
assigned" from (E) is used there _intentionally_, specifically because
with constants, we have full knowledge at translation-time, but with
variables, we need objects and an execution environment?  In other
words, is an implementation _allowed_ to attempt to dereference a null
pointer, knowing 100% full well at translation time that that's what
the expression _looks_ like?  With variables, the execution of the
program might or might not dereference a null pointer, and that can
trapped or not.

Consider the usual idea of '*x' as "object pointed-to by x" versus
splitting the idea into the more esoteric "result having a type,
possibly designating an object, and possibly having a value, depending
on properties of x".

What do you think?  Thank you with sincerity for your time,

- Shao Miller

On 21/07/10 23:51, Shao Miller wrote:

> Please respond with the _highest_ levels of pedantry you can muster
> up.

Do your own homework.

Rgds

Denis McMahon

Shao Miller wrote:
> Hello Readers,
> 
> Please respond with the _highest_ levels of pedantry you can muster
> up.
> 
> This e-mail is in regards to how a C translator/compiler should handle
> the expression:
> 
> *(char *)0

Any way it likes.

> 
> Consider the following program:
> 
> int main(void) {
>   (void)*(char *)0;
>   return 0;
> }
> 
> The question is: Does the above program imply undefined behaviour?

Yes.

> 
> References here from the C standard draft with filename 'n1256.pdf'.
> 
> Looking at the second line of the program:
> 
> (A) "Expression and null statements", 6.8.3, Semantics 2:
> 
> "The expression in an expression statement is evaluated as a void
> expression for its side effects."

(void)*(char *)0;

is an expression. Therefore, it is evaluated.

> 
> The footnote 134 adds, "Such as assignments, and function calls which
> have side effects."
> 
> This appears to describe the second line of the program pretty nicely.
> 
> (B) "void", 6.3.2.2, point 1:
> 
> "The (nonexistent) value of a void expression...shall not be used in
> any way...  If an expression of any other type is evaluated as a void
> expression, its value or designator is discarded.  (A void expression
> is evaluated for its side effects.)"

That's a violation of a "shall" outside a constraint - i.e. undefined 
behaviour.

<snip>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

On Jul 21, 7:11=A0pm, Denis McMahon <denis.m.f.mcma...@googlemail.co.uk>
wrote:
> Do your own homework.

Wow.  I've not been a student since 1995, but never did homework then,
either.  This isn't homework in the typical, student-applicable
sense.  I'm thinking about this subject matter here at home, yes.  If
you are trying to hint at something more and this is not just a wild,
inaccurate guess, please do enlighten.

Richard Heathfield <rjh@see.sig.invalid> writes:
> Shao Miller wrote:
>> Please respond with the _highest_ levels of pedantry you can muster
>> up.
[...]
>> Consider the following program:
>> 
>> int main(void) {
>>   (void)*(char *)0;
>>   return 0;
>> }
>> 
>> The question is: Does the above program imply undefined behaviour?
>
> Yes.

I tend to agree (I haven't done the research yet), but ...

[...]

>> (B) "void", 6.3.2.2, point 1:
>> 
>> "The (nonexistent) value of a void expression...shall not be used in
>> any way...  If an expression of any other type is evaluated as a void
>> expression, its value or designator is discarded.  (A void expression
>> is evaluated for its side effects.)"
>
> That's a violation of a "shall" outside a constraint - i.e. undefined 
> behaviour.

But it doesn't apply here.  The void expression in question is
    (void)*(char *)0

The (nonexistent) value of that expression is not used in any way by the
program.  It occurs as the expression of an expression-statement, so the
result is discarded.  Note that the statement
    (void)42;
has well-defined behavior.

Hmm.  Off the top of my head, I can't think of any way to violate the
"shall" in 6.3.2.2p1 without also violating some constraint.  For
example:

    x = (void)42;

violates the constraint specified in 6.5.16.1p1; void isn't one of
the permitted types for the right operand of a simple assignment.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

On Jul 21, 7:42=A0pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> Any way it likes.
>
Despite the material I've offered?

>
> Yes.
>
Do you have any useful references to go along with that claim?

>
> (void)*(char *)0;
>
> is an expression. Therefore, it is evaluated.
>
If we take the text literally, we note the absence of "only" in "for
its side effects", as mentioned.  Thus I agree that if we take the
text literally, the expression '*(char *)0' is evaluated.  I'm not
sure why you mention '(void)*(char *)0;' being evaluated, however.
That doesn't seem relevant to me, since the question of UB surrounds
'*(char *)0', even beyond its now-agreed-upon evaluation for its
context as part of a void expression.

>
> That's a violation of a "shall" outside a constraint - i.e. undefined
> behaviour.
>
What is the violation?  If there's no value, there's no value to be
used in any way or not to be used in any way.

Forget about the void expression context altogether and consider:

*(char *)0

Does this expression _have_ a value, given the text for the unary '*'
operator?

Can an implementation _even_attempt_to_get_ a value for this
expression, given that left alone, this expression has a result with a
type, but no mention of how its value can be gotten?  A null pointer
does not refer to an object, so how do you get a value here?

Do you _need_ a value for this expression?  Is there some kind of
requirement that during expression evaluation, a value is mandated at
some point?  Back to the variables and constants perspective: We are
not comparing a value by using this expression, we are not attempting
to assign using this expression, the expression is not an argument to
a function, we are not attempting to use the expression as an lvalue,
etc.  What exactly does evaluation entail?

(L) "Program execution", 5.1.2.3, point 3:

"In the abstract machine, all expressions are evaluated as specified
by the semantics. ..."

I do not see where the semantics entail that a value is required for
the expression '*(char *)0' outside of where such a value might be
_used_.  For example:

(M) "Simple assignment", 6.5.16.1, Semantics 2:

"In simple assignment (=3D), the value of the right operand is converted
to the type of the assignment expression and replaces the value stored
in the object designated by the left operand."

Why the use of "the value of the right operand" rather than merely
"the operand"?  Because it _demands_ a value.  Back to the context of
a void expression, we do not _demand_ a value at all.  In fact, any
value would be discarded.  If there's no value, there's no value to
even discard.

By (L), does "evaluated" _really_ necessitate "the act of computing a
value" for '*(char *)0'?  In the semantics (C), (D), (E), if we take
the text literally (like we did when we agreed above), there is no
assignment.  The requirement for type is even satisfied.

Similarly, how about:

*(char *)58

Does that have a value?  Does it not depend just the same upon
context?  Used in a void expression, no value is required.  Evaluate
all you like, you get something with a type, but there's no mention of
a mandatory value, is there?  Essentially, I'm approaching it
constructively: The expression evaluation semantics have built us up a
thing for which a type is defined, but no value.  Add to that, that
there is no requirement for a value.  Is there some confusion between
"expression is evaluated" and "expression is evaluated, thus giving it
a value"?

Thanks anyway.

Keith Thompson wrote:
> Richard Heathfield <rjh@see.sig.invalid> writes:
>> Shao Miller wrote:
>>> Please respond with the _highest_ levels of pedantry you can muster
>>> up.
> [...]
>>> Consider the following program:
>>>
>>> int main(void) {
>>>   (void)*(char *)0;
>>>   return 0;
>>> }
>>>
>>> The question is: Does the above program imply undefined behaviour?
>> Yes.
> 
> I tend to agree (I haven't done the research yet), but ...
> 
> [...]
> 
>>> (B) "void", 6.3.2.2, point 1:
>>>
>>> "The (nonexistent) value of a void expression...shall not be used in
>>> any way...  If an expression of any other type is evaluated as a void
>>> expression, its value or designator is discarded.  (A void expression
>>> is evaluated for its side effects.)"
>> That's a violation of a "shall" outside a constraint - i.e. undefined 
>> behaviour.
> 
> But it doesn't apply here.

Yes, it does.


>  The void expression in question is
>     (void)*(char *)0

The undefined behaviour comes from the expression *(char *)0, which is 
evaluated. The cast to void is neither here nor there.

> The (nonexistent) value of that expression is not used in any way by the
> program.  It occurs as the expression of an expression-statement, so the
> result is discarded.  Note that the statement
>     (void)42;
> has well-defined behavior.

Sure. But that's because 42 doesn't invoke undefined behaviour when 
evaluated.

<snip>


-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

Shao Miller wrote:
> On Jul 21, 7:42 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> Any way it likes.
>>
> Despite the material I've offered?

Open and shut case.

> 
>> Yes.
>>
> Do you have any useful references to go along with that claim?

You provided all the necessary references yourself.

> 
>> (void)*(char *)0;
>>
>> is an expression. Therefore, it is evaluated.
>>
> If we take the text literally, we note the absence of "only" in "for
> its side effects", as mentioned.  Thus I agree that if we take the
> text literally, the expression '*(char *)0' is evaluated.

Right.

> I'm not
> sure why you mention '(void)*(char *)0;' being evaluated, however.

<shrug> It's evaluated for its side effects, which are not overly 
numerous in this case - in fact, the only side effect is UB.


> That doesn't seem relevant to me, since the question of UB surrounds
> '*(char *)0', even beyond its now-agreed-upon evaluation for its
> context as part of a void expression.
> 
>> That's a violation of a "shall" outside a constraint - i.e. undefined
>> behaviour.
>>
> What is the violation?  If there's no value, there's no value to be
> used in any way or not to be used in any way.

It isn't the use that matters. It's the evaluation that matters.

char *p;
*p; /* UB, even though *p is not used */



> 
> Forget about the void expression context altogether and consider:
> 
> *(char *)0
> 
> Does this expression _have_ a value, given the text for the unary '*'
> operator?

Syntactically, yes. Semantically, no. Hence, UB.

> 
> Can an implementation _even_attempt_to_get_ a value for this
> expression, given that left alone, this expression has a result with a
> type, but no mention of how its value can be gotten?  A null pointer
> does not refer to an object, so how do you get a value here?

You are discovering why the behaviour is undefined.


<snip>

> Similarly, how about:
> 
> *(char *)58
> 
> Does that have a value?

It depends on whether (char *)58 points into an object.


> Does it not depend just the same upon
> context?  Used in a void expression, no value is required.  Evaluate
> all you like,

And the moment you try, if the pointer doesn't point into an object, the 
B is U.

<snip>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

Shao Miller wrote:
 
> *(char *)0
 
> (C) "Address and indirection operators", 6.5.3.2, Semantics 4:
> 
> "...if [the operand] points to an object,
> the result is an lvalue designating the object."


What does the standard say that the result is, 
if the operand doesn't point to an object?


> Is there undefined behaviour?

> What do you think? 



-- 
pete

Richard Heathfield <rjh@see.sig.invalid> writes:
> Keith Thompson wrote:
>> Richard Heathfield <rjh@see.sig.invalid> writes:
>>> Shao Miller wrote:
>>>> Please respond with the _highest_ levels of pedantry you can muster
>>>> up.
>> [...]
>>>> Consider the following program:
>>>>
>>>> int main(void) {
>>>>   (void)*(char *)0;
>>>>   return 0;
>>>> }
>>>>
>>>> The question is: Does the above program imply undefined behaviour?
>>> Yes.
>>
>> I tend to agree (I haven't done the research yet), but ...
>>
>> [...]
>>
>>>> (B) "void", 6.3.2.2, point 1:
>>>>
>>>> "The (nonexistent) value of a void expression...shall not be used in
>>>> any way...  If an expression of any other type is evaluated as a void
>>>> expression, its value or designator is discarded.  (A void expression
>>>> is evaluated for its side effects.)"
>>> That's a violation of a "shall" outside a constraint -
>>> i.e. undefined behaviour.
>>
>> But it doesn't apply here.
>
> Yes, it does.

I believe you're mistaken.  (As usual, I'm prepared to be convinced
otherwise.)

>>  The void expression in question is
>>     (void)*(char *)0
>
> The undefined behaviour comes from the expression *(char *)0, which is
> evaluated. The cast to void is neither here nor there.

I agree.  But the "shall" you were referring to above was the one in
6.3.2.2p1, which applies only to void expressions.  I don't argue that
the behavior of (void)*(char *)0 is well defined; I argue that it's
not 6.3.2.2p1 that causes it to be undefined.

Actually, I just noticed that there are two "shall"s in that paragraph.
Here's the whole thing:

    The (nonexistent) value of a void expression (an expression
    that has type void) shall not be used in any way, and implicit
    or explicit conversions (except to void) shall not be applied
    to such an expression. If an expression of any other type is
    evaluated as a void expression, its value or designator is
    discarded. (A void expression is evaluated for its side effects.)

Is either of these "shall"s violated by (void)*(char *)0?

If you didn't mean to imply that either of these particular "shall"s
is violated by this particular expression, please re-read what you
wrote above, particularly the line "Yes, it does."

>> The (nonexistent) value of that expression is not used in any way by the
>> program.  It occurs as the expression of an expression-statement, so the
>> result is discarded.  Note that the statement
>>     (void)42;
>> has well-defined behavior.
>
> Sure. But that's because 42 doesn't invoke undefined behaviour when
> evaluated.

Precisely.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

On Jul 21, 8:44=A0pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> Open and shut case.
>
Obviously it "feels" like it should be undefined behaviour, since
we've all been trying to avoid the act of a "null pointer dereference"
for a long time.  But how many of these deal with _objects_ assigned a
null pointer value, versus an expression which is merely a null
pointer on its own?  I believe that the vast majority are in the
former category, possibly biasing an interpretation of the referenced
text.  Think of it this way:  Your abstract machine plops a null
pointer value into an object 'foo' ("has been assigned to the pointer"
from (E)).  The next operation is "fetch the value of the object 'foo'
points to", perhaps because it's about to be used.  If 'foo' contains
a null pointer value, the behaviour is undefined.  This is what we're
used to.  But given a non-variable operand to '*', (E) does not apply,
since there's no assignment.  We can rely on (C) only.

>
> You provided all the necessary references yourself.
>
I still appreciate your feedback and would still appreciate if you
could directly address which portions of the referenced text support
your valuable discussion.

>
> Right.
>
I'm glad we can share a frame of reference here, then.

>
> <shrug> It's evaluated for its side effects, which are not overly
> numerous in this case - in fact, the only side effect is UB.
>
But _why_ is it UB?  Because of some notion that "we are attempting to
get a value using a null pointer"?  Some of my argument goes, "we are
_not_ required to get a value via the '*' unary operator."  We
certainly must and do yield a result with a type, as per (D).

>
> It isn't the use that matters. It's the evaluation that matters.
>
> char *p;
> *p; /* UB, even though *p is not used */
>
This is a great example.  Why is this UB?  My conclusion would be
because of a path from (C).  In an attempt to determine "if it points
to an object," we require the value of 'p', which is already UB.  Note
the use of 'p' versus the non-use of '*p'.  In '*(char *)0', we
already know darned well that '(char *)0' shall not point to an
object, so (C) does not apply.  Neither does (E), so we're left with
(D), a type.  It might help to use parentheses: *(p)  First we need
the value of 'p', which is UB.

>
> Syntactically, yes. Semantically, no. Hence, UB.
>
It syntactically has a value?  Where does the syntax describe this?
The syntax says it is a "unary-expression".

How about:

struct {
  int x;
} foo, *bar;
bar =3D &foo;
(*bar).x =3D 10;

Did we get any value from '*bar' there?  Surely we got an object, but
a value?  Did we "fetch" the "value" of the object pointed-to by
'bar', simply to toss it away because we are only setting a member?
"Structure and union members", 6.5.2.3 doesn't say anything about
requiring a value for its first operand, does it?  It talks about
type.  (M) is quite clear about requiring a value.

>
> You are discovering why the behaviour is undefined.
>
Not really.

>
> It depends on whether (char *)58 points into an object.
>
Possibly thanks to (C), yes.  There's no "depends" on '0', is there?

>
> And the moment you try, if the pointer doesn't point into an object, the
> B is U.
>
I'd really rather read your reasoning about _why_, based on the
referenced text, than "the B is U."

(N) "undefined behavior", 3.4.3, point 1:

"behavior, upon use of a nonportable or erroneous program construct or
of erroneous data,
for which this International Standard imposes no requirements"

Is there a nonportable program construct somewhere?  Is there an
erroneous one?  Is there erroneous data?  I don't see them.  I see us
having satisfied all requirements; '*(char *)0' has a type, as per (D).

On Jul 21, 9:12=A0pm, pete <pfil...@mindspring.com> wrote:
>
> What does the standard say that the result is,
> if the operand doesn't point to an object?
>
> > Is there undefined behaviour?
> What do you think?
>
I don't know the standard.  I can only say that the referenced text (a
standard draft) has (D).  It says the result has a type ('char'),
since its operand has type "pointer-to-char".  No UB.  See the struct
example in another post.  We get an object, not a value.

Keith Thompson <kst-u@mib.org> writes:
<snip>
> Hmm.  Off the top of my head, I can't think of any way to violate the
> "shall" in 6.3.2.2p1 without also violating some constraint.  For
> example:
>
>     x = (void)42;
>
> violates the constraint specified in 6.5.16.1p1; void isn't one of
> the permitted types for the right operand of a simple assignment.

Hardly important, but I think one such is:

  int array[1] = {(void)42};

I think this violates no constraints so 6.3.2.2 p1 is important to
render it undefined.

Initialising a scalar does not provide a simpler example because 6.7.8
p11 imports all of the constraints attached to assignment.  Thus

  int x = {(void)42};

must be diagnosed.

-- 
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
> <snip>
>> Hmm.  Off the top of my head, I can't think of any way to violate the
>> "shall" in 6.3.2.2p1 without also violating some constraint.  For
>> example:
>>
>>     x = (void)42;
>>
>> violates the constraint specified in 6.5.16.1p1; void isn't one of
>> the permitted types for the right operand of a simple assignment.
>
> Hardly important, but I think one such is:
>
>   int array[1] = {(void)42};
>
> I think this violates no constraints so 6.3.2.2 p1 is important to
> render it undefined.
>
> Initialising a scalar does not provide a simpler example because 6.7.8
> p11 imports all of the constraints attached to assignment.  Thus
>
>   int x = {(void)42};
>
> must be diagnosed.

6.7.8p11:
    The initializer for a scalar shall be a single expression,
    optionally enclosed in braces. The initial value of the object
    is that of the expression (after conversion); the same type
    constraints and conversions as for simple assignment apply,
    taking the type of the scalar to be the unqualified version of
    its declared type.

Ah, but it does violate a constraint.

The syntax for "initializer" is:

    initializer:
        assignment-expression
        { initializer-list }
        { initializer-list , }

where an initializer-list is basically a list of initializers.
So {(void)42} is an initializer (for array), and (void)42 is also an
initializer (for array[0]).  Since array[0] is a scalar, (void)42 is
"The initializer for a scalar", and the constraints referred to in
6.7.8p11 apply.

As I studied 6.7.8, I was relieved to discover this; otherwise a
compiler wouldn't be required to diagnose

    double arr[] = { "hello" };

and that would be bad.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

Shao Miller <sha0.miller@gmail.com> writes:

> Please respond with the _highest_ levels of pedantry you can muster
> up.
>
> This e-mail

You mean newsgroup posting.

> is in regards to how a C translator/compiler should handle
> the expression:
>
> *(char *)0
>
> Consider the following program:
>
> int main(void) {
>   (void)*(char *)0;
>   return 0;
> }
>
> The question is: Does the above program imply undefined behaviour?
> [snip 165 more lines]

Yes.

On Jul 21, 10:55=A0pm, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>
> You mean newsgroup posting.
>
Thanks for the correction, Tim.

>
> Yes.
Is this the "_highest_" level "of pedantry you" could "muster up"?  If
so, then thanks.

How about the following code:

int main(void) {
  struct foo {
    int x;
    char y[2048];
    int z;
  };
  return (*(struct foo*)0).z;
}

Are we attempting to get any sort of "value" when evaluating the
expression '(*(struct foo*)0)'?  We have a type, as (D) suggests.

Have you any thoughts on why the text referenced in (E) reads, "has
been assigned to the pointer", Tim?  Is that a mistake like my "e-
mail" above, do you suppose?  If not, do you see any assignment of a
null pointer value in this code?

Thanks.

Shao Miller <sha0.miller@gmail.com> writes:

> On Jul 21, 10:55 pm, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>>
>> You mean newsgroup posting.
>>
> Thanks for the correction, Tim.
>
>>
>> Yes.
> Is this the "_highest_" level "of pedantry you" could "muster up"?  If
> so, then thanks.

I'd used up all my pedantry capital in the earlier "newsgroup"
statement.


> How about the following code:
>
> int main(void) {
>   struct foo {
>     int x;
>     char y[2048];
>     int z;
>   };
>   return (*(struct foo*)0).z;
> }
>
> Are we attempting to get any sort of "value" when evaluating the
> expression '(*(struct foo*)0)'?  We have a type, as (D) suggests.

No, but doing so is undefined behavior, for the same reason
as the '*(char*)0' example.

> Have you any thoughts on why the text referenced in (E) reads, "has
> been assigned to the pointer", Tim?  [snip]

I think it's old, carelessly imprecise wording that's
never been revised to correct the imprecision, probably
partly because it means just what it seems to mean to
people who don't think about it too carefully.

On Jul 22, 1:37=A0am, Richard Heathfield <r...@see.sig.invalid> wrote:

> The undefined behaviour comes from the expression *(char *)0, which is
> evaluated. The cast to void is neither here nor there.

First * (char *) 0 is evaluated, giving an lvalue (no undefined
behaviour yet). However, when that expression is used as the argument
in a cast, and also if it were just used as the complete expression in
an expression statement and in some other situations, it is converted
to an rvalue and the undefined behaviour happens at that point. There
is a slight difference in the C++ language, where using it in an
expression statement would not cause undefined behaviour.

For an application programmer, all this doesn't make any difference:
If there is _doubt_ about undefined behaviour or not, then don't do
it. For an optimising compiler, there is no difference because no code
should be generated for (void) * (char *) expr except for the side
effects of expr, whatever expr is. For a non-optimising compiler,
since this _is_ undefined behaviour, the compiler _may_ produce a read
access to the location (char *) 0 which will do whatever it does on
that particular machine. So if a non-optimising compiler doesn't know
to remove read accesses when the data is not used, that is fine.

Keith Thompson wrote:
> Richard Heathfield <rjh@see.sig.invalid> writes:

<snip>

> 
>>>  The void expression in question is
>>>     (void)*(char *)0
>> The undefined behaviour comes from the expression *(char *)0, which is
>> evaluated. The cast to void is neither here nor there.
> 
> I agree.

That is all I was intending to claim. If you are picking a nit with the 
way in which I claimed it, I am perfectly happy to cede the point, but 
the claim itself (that the expression exhibits undefined behaviour) is 
correct.

<snip>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

Shao Miller wrote:
> On Jul 21, 8:44 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> Open and shut case.
>>
> Obviously it "feels" like it should be undefined behaviour, since
> we've all been trying to avoid the act of a "null pointer dereference"
> for a long time.

See 6.5.3.2.

"The unary * operator denotes indirection. If the operand points to a 
function, the result is a function designator; if it points to an 
object, the result is an lvalue designating the object. If the operand 
has type ��pointer to type��, the result has type ��type��. If an
invalid value has been assigned to the pointer, the behavior of the 
unary * operator is undefined."

NULL is an invalid value - it is guaranteed not to point to any object 
or function. (See 6.3.2.3.)

Therefore, using * on a null pointer invokes UB.

<snip>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>> <snip>
>>> Hmm.  Off the top of my head, I can't think of any way to violate the
>>> "shall" in 6.3.2.2p1 without also violating some constraint.  For
>>> example:
>>>
>>>     x = (void)42;
>>>
>>> violates the constraint specified in 6.5.16.1p1; void isn't one of
>>> the permitted types for the right operand of a simple assignment.
>>
>> Hardly important, but I think one such is:
>>
>>   int array[1] = {(void)42};
>>
>> I think this violates no constraints so 6.3.2.2 p1 is important to
>> render it undefined.
>>
>> Initialising a scalar does not provide a simpler example because 6.7.8
>> p11 imports all of the constraints attached to assignment.  Thus
>>
>>   int x = {(void)42};
>>
>> must be diagnosed.
>
> 6.7.8p11:
>     The initializer for a scalar shall be a single expression,
>     optionally enclosed in braces. The initial value of the object
>     is that of the expression (after conversion); the same type
>     constraints and conversions as for simple assignment apply,
>     taking the type of the scalar to be the unqualified version of
>     its declared type.
>
> Ah, but it does violate a constraint.
>
> The syntax for "initializer" is:
>
>     initializer:
>         assignment-expression
>         { initializer-list }
>         { initializer-list , }
>
> where an initializer-list is basically a list of initializers.
> So {(void)42} is an initializer (for array), and (void)42 is also an
> initializer (for array[0]).  Since array[0] is a scalar, (void)42 is
> "The initializer for a scalar", and the constraints referred to in
> 6.7.8p11 apply.

Obviously I thought that the paragraph about scalars was not to be taken
as applying recursively.  Reading your point below, that now seems to a
daft way to read it, but let me just say why I took to be so (if only
for a few hours!).  First, just after the paragraph about scalars, p12
reads:

  12 The rest of this subclause deals with initializers for objects that
     have aggregate or union type.

which I took to mean "and the previous clauses don't" for no good reason
other than I seem to have a habit of reading more than is intended into
phrases that are simply informative.  Second, p20 starts:

  20 If the aggregate or union contains elements or members that are
     aggregates or unions, these rules apply recursively to the
     subaggregates or contained unions.

as if to suggest that "these rules" are applied recursively but only
down to the level of sub-aggregates not the scalars within them.  Again,
this is just reading too much into it.  That the rules about aggregates
apply recursively, does not mean that the others about scalars don't.

> As I studied 6.7.8, I was relieved to discover this; otherwise a
> compiler wouldn't be required to diagnose
>
>     double arr[] = { "hello" };
>
> and that would be bad.

Yes, and for that reason alone it seems clear (now) that p11 must apply
to all enclosed scalars as much as to the top-level ones.

-- 
Ben.

On Jul 22, 1:51=A0am, Shao Miller <sha0.mil...@gmail.com> wrote:
> Hello Readers,
>
> Please respond with the _highest_ levels of pedantry you can muster
> up.
>
> This e-mail is in regards to how a C translator/compiler should handle
> the expression:
>
> *(char *)0
>
> Consider the following program:
>
> int main(void) {
> =A0 (void)*(char *)0;
> =A0 return 0;
>
> }
>
> The question is: Does the above program imply undefined behaviour?
>
> References here from the C standard draft with filename 'n1256.pdf'.
>
> Looking at the second line of the program:
>
> (A) "Expression and null statements", 6.8.3, Semantics 2:
>
> "The expression in an expression statement is evaluated as a void
> expression for its side effects."
>
> The footnote 134 adds, "Such as assignments, and function calls which
> have side effects."
>
> This appears to describe the second line of the program pretty nicely.
>
> (B) "void", 6.3.2.2, point 1:
>
> "The (nonexistent) value of a void expression...shall not be used in
> any way... =A0If an expression of any other type is evaluated as a void
> expression, its value or designator is discarded. =A0(A void expression
> is evaluated for its side effects.)"
>
> Note that this doesn't read "_only_ evaluated for its side effects."
> However, (A) doesn't read "_only_", either, but one can get that
> impression due to the explicit mentioning of "side effects" in both
> (A) and (B).
>
> (C) "Address and indirection operators", 6.5.3.2, Semantics 4:
>
> "...if [the operand] points to an object, the result is an lvalue
> designating the object."
>
> (D) "Address and indirection operators", 6.5.3.2, Semantics 4:
>
> "If the operand has type 'pointer to type', the result has type
> 'type'.
>
> (E) "Address and indirection operators", 6.5.3.2, Semantics 4:
>
> "...If an invalid value has been assigned to the pointer, the
> behavior...is undefined."
>
> The footnote 87 adds, "Among the invalid values for dereferencing a
> pointer...are a null pointer..." =A0This footnote is referenced from
> (E).
>
> (C), (D) and (E) are in regards to the unary '*' operator, and where I
> perceive a challenge in interpretation. =A0This operator is followed by
> a cast-expression, so such an expression would make up the operand, if
> I'm not mistaken. =A0The particular cast-expression in line two of the
> program is '(char *)0'. =A0_Is_this_an_assigned_value_?
> _Is_"assigned"_meant_there_purposefully_or_not_?
>
> (F) "object", 3.13, point 1:
>
> "region of data storage in the execution environment, the contents of
> which can represent values"
>
> (G) "value", 3.17, point 1:
>
> "precise meaning of the contents of an object when interpreted as
> having a specific type"
>
> By (G), is '(char *)0' a value? =A0Maybe not by (G), but there are other
> parts in the text which read as though expressions can have values,
> without needing any objects. =A0The "integer constant expression with
> the value 0" in (H) below is such an example. =A0Perhaps it _may_be_ a
> value iff _used_ for its value?
>
> (H) "Pointers", 6.3.2.3, points 3 and 4:
>
> "An integer constant expression with the value 0, or such an
> expression cast to type void *, is called a null pointer constant. =A0If
> a null pointer constant is converted to a pointer type, the resulting
> pointer, called a null pointer, is guaranteed to compare unequal to a
> pointer to any object or function."
>
> "Conversion of a null pointer to another pointer type yields a null
> pointer of that type. =A0Any two null pointers shall compare equal."
>
> By (H), it would appear that '(char *)0' is a pointer and a null
> pointer. =A0Also, it cannot point to an object. =A0Thus, this operand doe=
s
> not point to an object for (C), and we must forget (C)'s application
> to our case.
>
> (I) "Cast operators", 6.5.4, Semantics 4:
>
> "Preceding an expression by a parenthesized type name converts the
> value of the expression to the named type. ..."
>
> Another example where an expression _has_ a value. =A0But the text reads
> "value of the expression" to describe the _use_ of that particular
> property of the expression. =A0Similar to "...expression with the value
> 0" in (H).
>
> The footnote 89 adds, "A cast does not yield an lvalue."
>
> By (I), it would appear that '(char *)0' converts the value of '0' to
> a 'char *' type. =A0But is this value _assigned_to_a_pointer_ in (E)?
> We do now know that the type for this operand is 'char *' for (D).
> Thus the unary '*' operator should yield a result with type 'char', by
> (D).
>
> (J) "The sizeof operator", 6.5.3.4, Semantics 2:
>
> "...The size is determined from the type of the operand. ...the
> operand is not evaluated."
>
> In this, we see that a particular property "type" for the operand is
> used. =A0"...the operand is not evaluated" suggests that there is at
> least one case in the C language where an expression can yield a
> result with a type while avoiding that expression's evaluation.
>
> But compare (J) with (A) and (B), which do describe evaluation, albeit
> with "non-existant" values. =A0(A) and (B) both mention side effects.
>
> (K) "Program execution", 5.1.2.3, point 2:
>
> "Accessing a volatile object, modifying an object, modifying a file,
> or calling a function that does any of those operations are all side
> effects, which are changes in the state of the execution environment.
> Evaluation of an expression may produce side effects."
>
> From (K), '*(char *)0' does not access a volatile object, nor does it
> modify an object (remember that there's no assignment!), nor does it
> modify a file, nor call a function doing any of those operations. =A0It
> does not appear to have any "side effects" at all. =A0Iff '(char *)0'
> can itself be considered an object (beyond being a pointer, a null
> pointer, a cast expression, and having type 'char *'), then we _still_
> don't have any side effects. =A0For example: Would it be a volatile
> object? =A0Are we modifying an object?
>
> If we constrain (A) and (B) to mean "_only_ evaluated for any side
> effects", then (K) suggests '*(char *)0' has no side effects. =A0This
> constraint is not explicitly in the text, however. =A0One can ponder if
> it is meant or not.
>
> Now then, let us please consider how '*(char *)0' evaluates if we take
> "...If an invalid value has been assigned to the pointer..." from (E)
> _literally_. =A0There is no assignment here. =A0There is conversion of th=
e
> value of the expression '0' to a null pointer. =A0Then we are applying
> the '*' operator to that null pointer. =A0The result has of this
> application yields a result with type 'char'. =A0According to (J), this
> expression can even be an operand to 'sizeof', since it has a type.
> There is no object and there is no value.
>
> Is there undefined behaviour? =A0Perhaps consider it in terms of
> variables and constants: In '*(char *)0', everything is constant. =A0In
> '*(char *)x', x is variable. =A0Could be suppose that "has been
> assigned" from (E) is used there _intentionally_, specifically because
> with constants, we have full knowledge at translation-time, but with
> variables, we need objects and an execution environment? =A0In other
> words, is an implementation _allowed_ to attempt to dereference a null
> pointer, knowing 100% full well at translation time that that's what
> the expression _looks_ like? =A0With variables, the execution of the
> program might or might not dereference a null pointer, and that can
> trapped or not.
>
> Consider the usual idea of '*x' as "object pointed-to by x" versus
> splitting the idea into the more esoteric "result having a type,
> possibly designating an object, and possibly having a value, depending
> on properties of x".
>
> What do you think? =A0Thank you with sincerity for your time,
>
> - Shao Miller

In the many quotes you forgot one which is (along with 6.3.2.3.[3-4])
only relevant to your inquiry:

6.3.2.3.[5] An integer may be converted to any pointer type. Except as
previously specified, the
result is implementation-defined, might not be correctly aligned,
might not point to an
entity of the referenced type, and might be a trap representation.

Without excerpt of integer 0 cast to pointer and "Except as previously
specified..." clause, *(char*)0 would qualify as undefined behavior by
6.3.2.3.[5] and 6.5.3.2.[4]. With the addition of null pointer
specification, (char*)0 is guaranteed NOT to point to an object, but
it's never specicied as a constraint or as requiring a specific
action. So it's somewhere between "undefined" and "illegal". Most
implementations seem to choose the "undefined" side, and previous
discussion here, IIRC, ended with a similar suggestion.

Daniel

On Jul 22, 11:53=A0am, "christian.bau"
<christian....@cbau.wanadoo.co.uk> wrote:
> On Jul 22, 1:37=A0am, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> > The undefined behaviour comes from the expression *(char *)0, which is
> > evaluated. The cast to void is neither here nor there.
>
> First * (char *) 0 is evaluated, giving an lvalue (no undefined
> behaviour yet).

It is either undefined (consider 6.3.2.3.[5] with 6.5.3.2.[4]) or
illegal (consider 6.3.2.3.[3] that null pointer "is guaranteed to
compare unequal to a pointer to any object or function"). So '*' in
*(char*)0 either references address which is not defined to be legal,
or dereferences pointer to something that is necessarily not an
object.

Daniel

On Jul 22, 12:40=A0am, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>
> I think it's old, carelessly imprecise wording that's
> never been revised to correct the imprecision, probably
> partly because it means just what it seems to mean to
> people who don't think about it too carefully.

I'm sorry you seem to be implying that I haven't thought about this
carefully.  I'm glad that you think the wording needs to be
addressed.  The latter seems like an opinion worth offering.

On Jul 22, 5:09=A0am, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> See 6.5.3.2.
>
> "The unary * operator denotes indirection. If the operand points to a
> function, the result is a function designator; if it points to an
> object, the result is an lvalue designating the object. If the operand
> has type =91=91pointer to type=92=92, the result has type =91=91type=92=
=92. If an
> invalid value has been assigned to the pointer, the behavior of the
> unary * operator is undefined."
>
This reference causes me to wonder if you actually read the original
newsgroup posting.  For some reason, I get the impression that few
responders actually did.  I realize it was a long one, and there's
only so much time in a day.  I brought the question up because I
believe that either:
1. The standard needs to be addressed due to an ambiguity, should it
be the case that it has not been already, XOR
2. There is no undefined behaviour

>
> NULL is an invalid value - it is guaranteed not to point to any object
> or function. (See 6.3.2.3.)
>
Yet another item referenced in the original post.  Look at your
previous reference then look at this one.  Where is a null pointer
value assigned?  It's not.  Yet the cast expression (the operand)
'(char *)0' _has_ a type, so the result of applying '*' _has_ a type.
That is all that 'sizeof' requires.  That is enough for a void
expression.  It is enough for the '.' postfix operator.  No _value_ is
required in any of those three contexts.  It would not be enough for
an assignment or a comparison.

>
> Therefore, using * on a null pointer invokes UB.
>
Using '*' on a pointer that has been assigned an invalid value is UB.
'(char *)0' is not an lvalue (no cast expression is), hence it cannot
be assigned a value.  It is a pointer.  It is a null pointer.  It is
not a pointer that has been assigned a null pointer value.

I do continue to value your feedback and am hopeful that you or
another responder may pinpoint a definitive reason for UB.  So far,
Tim's suggestion that "the wording is imprecise" strikes me as most
likely, iff there really is undefined behaviour.

Shao Miller <sha0.miller@gmail.com> writes:

> On Jul 22, 12:40 am, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>>
>> I think it's old, carelessly imprecise wording that's
>> never been revised to correct the imprecision, probably
>> partly because it means just what it seems to mean to
>> people who don't think about it too carefully.
>
> I'm sorry you seem to be implying that I haven't thought about this
> carefully.  [snip]

Oh no, I didn't mean that at all.  It's obvious you have
thought about it carefully.  If you hadn't, your question
wouldn't have come up.  You see what I'm saying now?

On Jul 22, 6:30=A0am, Stargazer <stargazer3...@gmail.com> wrote:
>
> In the many quotes you forgot one which is (along with 6.3.2.3.[3-4])
> only relevant to your inquiry:
>
> 6.3.2.3.[5] An integer may be converted to any pointer type. Except as
> previously specified, the
> result is implementation-defined, might not be correctly aligned,
> might not point to an
> entity of the referenced type, and might be a trap representation.
>
> Without excerpt of integer 0 cast to pointer and "Except as previously
> specified..." clause, *(char*)0 would qualify as undefined behavior by
> 6.3.2.3.[5] and 6.5.3.2.[4].
>
char *x =3D (char *)0;
Here we declare a pointer-to-char and initialize it with '0' cast to
pointer-to-char.  There's no UB here, right?  So how is application of
the unary '*' operator to "the result" of the conversion in 6.5.3.2.
[3] (a null pointer, '(char *)0') impacted by these further
references?  Section 6.3.2.3 has "had its say" by the time we have the
result '(char *)0'.  There's no UB.  Then we apply the unary '*'
operator.

>
> With the addition of null pointer
> specification, (char*)0 is guaranteed NOT to point to an object, but
> it's never specicied as a constraint or as requiring a specific
> action.
>
What is "it"?  The expression?  The result?  The value?  What
constraint do you need?  What action do you need?

I propose that it is well-defined:
1. The expression details the operation of a cast.  The result has a
type, pointer-to-char.  An object of that type would have size and
alignment.
2. The result is called "a null pointer"
3. The result can be used as a value in an assignment

>
> So it's somewhere between "undefined" and "illegal". Most
> implementations seem to choose the "undefined" side, and previous
> discussion here, IIRC, ended with a similar suggestion.
>
You appear to be talking about '(char *)0' and '*(char *)0'
simultaneously.

On Jul 22, 6:37=A0am, Stargazer <stargazer3...@gmail.com> wrote:
>
> It is either undefined (consider 6.3.2.3.[5] with 6.5.3.2.[4]) or
> illegal (consider 6.3.2.3.[3] that null pointer "is guaranteed to
> compare unequal to a pointer to any object or function"). So '*' in
> *(char*)0 either references address
>
I believe that you are confused, here.  6.5.3.2 is "Address and
indirection operators".  Is it specified which of '&' and '*' is
"address" and which is "indirection"?  Do they have a one-to-one
correspondence?  It really doesn't matter at all.  _Nowhere_ does the
text for '*' read "reference" nor does it read "address" at all.
Please clarify.

>
> which is not defined to be legal,
> or dereferences pointer to something that is necessarily not an
> object.
>
The entirety of the 'n1256.pdf' draft doesn't include the word
"dereference," but that's what some of us call it, including me.
However, it might have led to "magical thinking" regarding the '*'
unary operator.  It is an operator.  It has operands.  It doesn't need
to "dereference an object" and it doesn't need to "dereference
something that is not necessarily an object".

But I appreciate your feedback, regardless of that.

On Jul 22, 10:05=A0am, Tim Rentsch <t...@alumni.caltech.edu> wrote:
> Shao Miller <sha0.mil...@gmail.com> writes:
> > On Jul 22, 12:40 am, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>
> >> I think it's old, carelessly imprecise wording that's
> >> never been revised to correct the imprecision, probably
> >> partly because it means just what it seems to mean to
> >> people who don't think about it too carefully.
>
> > I'm sorry you seem to be implying that I haven't thought about this
> > carefully. =A0[snip]
>
> Oh no, I didn't mean that at all. =A0It's obvious you have
> thought about it carefully. =A0If you hadn't, your question
> wouldn't have come up. =A0You see what I'm saying now?
>
Thanks, Tim.  I apologize for misunderstanding.  I also agree that if
UB is intended for the case of:

(void)*(char *)0;

then something, somewhere in the text needs to be modified; 6.5.3.2
would be an easy place for it, should it be the case that the wording
is carelessly imprecise.  An alternative might be that the wording is
accurate and intended, allowing for no undefined behaviour in the
original post's question.  Any attempted use of the _value_ of the
result of '*(char *)0' is certainly undisputedly undefined behaviour,
since there is no defined means to obtain such a value (it is defined
that there is no object to obtain a value from).

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
> Obviously I thought that the paragraph about scalars was not to be taken
> as applying recursively.  Reading your point below, that now seems to a
> daft way to read it, but let me just say why I took to be so (if only
> for a few hours!).  First, just after the paragraph about scalars, p12
> reads:
>
>   12 The rest of this subclause deals with initializers for objects that
>      have aggregate or union type.
>
> which I took to mean "and the previous clauses don't" for no good reason
> other than I seem to have a habit of reading more than is intended into
> phrases that are simply informative.  Second, p20 starts:
>
>   20 If the aggregate or union contains elements or members that are
>      aggregates or unions, these rules apply recursively to the
>      subaggregates or contained unions.
>
> as if to suggest that "these rules" are applied recursively but only
> down to the level of sub-aggregates not the scalars within them.  Again,
> this is just reading too much into it.  That the rules about aggregates
> apply recursively, does not mean that the others about scalars don't.

But it would be nice if that section were clearer.  You and I
both took a while to figure out how the wording reflects the (in
retrospect fairly obvious) intent.

>> As I studied 6.7.8, I was relieved to discover this; otherwise a
>> compiler wouldn't be required to diagnose
>>
>>     double arr[] = { "hello" };
>>
>> and that would be bad.
>
> Yes, and for that reason alone it seems clear (now) that p11 must apply
> to all enclosed scalars as much as to the top-level ones.

But I'm not entirely comfortable interpreting ambiguous wording by
picking the interpretation that doesn't lead to bad consequences.

I think the "applies recursively" wording should be earlier in that
section.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Keith Thompson <kst-u@mib.org> writes:
<snip>
>>> As I studied 6.7.8, I was relieved to discover this; otherwise a
>>> compiler wouldn't be required to diagnose
>>>
>>>     double arr[] = { "hello" };
>>>
>>> and that would be bad.
>>
>> Yes, and for that reason alone it seems clear (now) that p11 must apply
>> to all enclosed scalars as much as to the top-level ones.
>
> But I'm not entirely comfortable interpreting ambiguous wording by
> picking the interpretation that doesn't lead to bad consequences.
>
> I think the "applies recursively" wording should be earlier in that
> section.

Agreed.

-- 
Ben.

Shao Miller wrote:
> 
> On Jul 21, 9:12 pm, pete <pfil...@mindspring.com> wrote:
> >
> > What does the standard say that the result is,
> > if the operand doesn't point to an object?
> >
> > > Is there undefined behaviour?

> I don't know the standard.  

You have undefined behavior because 
you have a null pointer as an operand of the indirection operator.

This is the relevant text:

6.5.3.2 Address and indirection operators
Constraints
1 The operand of the unary & operator shall be either
  a function designator,
  the result of a [] or unary * operator,
  or an lvalue that designates an object 
  that is not a bit-field and is not declared
  with the register storage-class specifier.

-- 
pete

pete <pfiland@mindspring.com> writes:

> Shao Miller wrote:
>> 
>> On Jul 21, 9:12 pm, pete <pfil...@mindspring.com> wrote:
>> >
>> > What does the standard say that the result is,
>> > if the operand doesn't point to an object?
>> >
>> > > Is there undefined behaviour?
>
>> I don't know the standard.  
>
> You have undefined behavior because 
> you have a null pointer as an operand of the indirection operator.
>
> This is the relevant text:
>
> 6.5.3.2 Address and indirection operators
> Constraints
> 1 The operand of the unary & operator shall be either
>   a function designator,
>   the result of a [] or unary * operator,
>   or an lvalue that designates an object 
>   that is not a bit-field and is not declared
>   with the register storage-class specifier.

Wrong operator.  Indirection is '*', not '&'.

Tim Rentsch wrote:
> 
> pete <pfiland@mindspring.com> writes:
> 
> > Shao Miller wrote:
> >>
> >> On Jul 21, 9:12 pm, pete <pfil...@mindspring.com> wrote:
> >> >
> >> > What does the standard say that the result is,
> >> > if the operand doesn't point to an object?
> >> >
> >> > > Is there undefined behaviour?
> >
> >> I don't know the standard.
> >
> > You have undefined behavior because
> > you have a null pointer as an operand of the indirection operator.

> Wrong operator.  Indirection is '*', not '&'.

I was discussing '*'. 

The following is the original post:

This e-mail is in regards to how a C translator/compiler should handle
the expression:

*(char *)0

-- 
pete

pete <pfiland@mindspring.com> writes:

> Tim Rentsch wrote:
>> 
>> pete <pfiland@mindspring.com> writes:
>> 
>> > Shao Miller wrote:
>> >>
>> >> On Jul 21, 9:12 pm, pete <pfil...@mindspring.com> wrote:
>> >> >
>> >> > What does the standard say that the result is,
>> >> > if the operand doesn't point to an object?
>> >> >
>> >> > > Is there undefined behaviour?
>> >
>> >> I don't know the standard.
>> >
>> > You have undefined behavior because
>> > you have a null pointer as an operand of the indirection operator.
>
>> Wrong operator.  Indirection is '*', not '&'.
>
> I was discussing '*'. 
>
> The following is the original post:
>
> This e-mail is in regards to how a C translator/compiler should handle
> the expression:
>
> *(char *)0

I know that, but the paragraph you quoted was talking
about the address operator, not the indirection operator.

Here is the quoted paragraph again:

> This is the relevant text:
> 
> 6.5.3.2 Address and indirection operators
> Constraints
> 1 The operand of the unary & operator shall be either
>   a function designator,
>   the result of a [] or unary * operator,
>   or an lvalue that designates an object 
>   that is not a bit-field and is not declared
>   with the register storage-class specifier.

This constraint is not about the indirection operator.

I found the relevant portion of the text of 'n1256.pdf' which renders:

(void)*(char *)0;

to yield undefined behaviour.  It is "Cast operators", 6.5.4,
Semantics 4:

"Preceding an expression by a parenthesized type name converts the
value of the expression to the named type."

It is _here_ that we _require_ a _value_ for the _result_ (of the
expression) that is '*(char *)0'.  Why?  There are two casts here.
The cast to 'char *' is fine.  The cast to void is not, since it
doesn't survive without a value for '*(char *)0'.  This is before we
consider the whole as a void expression.

There is no definition for the value of the result of '*(char *)0'.

Unfortunately, we are still left with a tricky case; that of:

*(void *)0;

To summarize some points:
1. The value of the expression '0' is cast to 'void *'
2. The result of [1] has type 'void *'.
3. The result of [1] is a pointer.
4. The result of [1] is a null pointer.
5. The result of [1] is a null pointer constant.
6. The result of [1] is a scalar.
7. The result of [1] has a value (as per the cast conversion).
8. The value of the result of [1] is not assigned to a pointer.
9. We apply the unary '*' operator.
10. We give this operator in [9] the expression '(void *)0' as its
operand.
11. The result of [1] is thus the resulting (let's say, "effective")
operand in [9].
12. The effective operand in [9] does not point to a function.
13. The effective operand in [9] does not point to an object, as per
[4].
14. The result of [9] cannot be an lvalue by [13].
15. The effective operand in [9] has type 'void *', as per [2].
16. The result of [9] is defined to have type 'void', due to [15].
17. No invalid value has been assigned to the pointer, as per [8].
18. The result of [9] is not required to possess a value.
19. No undefined behaviour, thus far.
20. The entirety of '*(void *)0' is an expression.
21. The expression in [20] is a void expression.
22. The void expression in [20] has a non-existent value, congruent
with [18].
23. The void expression in [20] is evaluated, including for its side
effects.
24. The expression in [20] does not access a volatile object.
25. The expression in [20] does not modify an object.
26. The expression in [20] does not modify a file.
27. The expression in [20] does not call a function.
28. The expression statement '*(void *)0;' yields no undefined
behaviour and is fully defined as a legal expression statement.

Opinions, thoughts, pedantry?

Thank you for all of the feedback so far.  This subject matter is good
to know in case of writing an implementation.

- Shao Miller

pete <pfiland@mindspring.com> writes:

> Shao Miller wrote:
>> 
>> On Jul 21, 9:12 pm, pete <pfil...@mindspring.com> wrote:
>> >
>> > What does the standard say that the result is,
>> > if the operand doesn't point to an object?
>> >
>> > > Is there undefined behaviour?
>
>> I don't know the standard.  
>
> You have undefined behavior because 
> you have a null pointer as an operand of the indirection operator.

Whilst I believe that's true in this case it is not (as I am sure you
know) a sufficient condition.  For example, both

  &*(char *)0

and

  sizeof *(char *)0

are explicitly well-defined despite having * applied to a null pointer
operand.  This may be the germ of Shao Miller's question.  Since a void
expression is evaluated "for its side effects" can the absence of side
effects render the expression in question unevaluated?

For what it's worth, my view is that this wording is there simply to
give permission for an implementation to optimise away such side-effect
free evaluations as the one the OP gave originally.  That does not
change the fact that it is undefined.

<snip>
-- 
Ben.

Shao Miller <sha0.miller@gmail.com> writes:

> I found the relevant portion of the text of 'n1256.pdf' which renders:
>
> (void)*(char *)0;
>
> to yield undefined behaviour.  It is "Cast operators", 6.5.4,
> Semantics 4:  [snip elaboration]

The expression '*(char *)0' is undefined behavior if it
is evaluated.  Any subsequent cast is irrelevant to the
question about whether the behavior is defined.

On Jul 23, 7:23=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> =A0 &*(char *)0
>
> and
>
> =A0 sizeof *(char *)0
>
> are explicitly well-defined despite having * applied to a null pointer
> operand. =A0This may be the germ of Shao Miller's question. =A0Since a vo=
id
> expression is evaluated "for its side effects" can the absence of side
> effects render the expression in question unevaluated?
>
'Twas the original germ, yes.  Then we agreed to take the text
literally and that the expression is evaluated.  I still didn't see
any UB, because:

A value for the result of application of the unary '*' is not a
requirement of the text for the unary '*' operator in 'n1256.pdf'.

Consider:

(*p).f();

Where '(*p)' yields an lvalue (assuming 'p' points to an object), thus
satisfying the requirement for an object by the membership '.'
operator.  But ponder what "value" was involved for '(*p)' in this
case.  The aggregate value of the object pointed to by 'p' in its
entirety?  I should hardly think so.

>
> For what it's worth, my view is that this wording is there simply to
> give permission for an implementation to optimise away such side-effect
> free evaluations as the one the OP gave originally.
>
Agreed.

>
> That does not
> change the fact that it is undefined.
>
As per my post in response to the original post, and due to the cast
when casting to '(void)', I now agree.  Not due to application of the
unary '*' operator to a null pointer which has not been assigned a
null pointer value.  See also the challenge with:

*(void *)0;

On Jul 23, 12:43=A0pm, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>
> The expression '*(char *)0' is undefined behavior if it
> is evaluated. =A0Any subsequent cast is irrelevant to the
> question about whether the behavior is defined.
>
If and only if you do not take the text for the unary '*' operator
literally.  That text describes undefined behaviour when a null
pointer value has been assigned to the pointer.  Here we have a null
pointer, not a nuller pointer value assigned to a pointer.

We agreed that it's possible that that text might be imprecise, and
might need to be addressed, did we not?  But it's also possible that
it's precise, and there is no undefined behaviour until casting to
'(void)'.

Would you agree?

Shao Miller <sha0.miller@gmail.com> writes:

> On Jul 23, 12:43 pm, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>>
>> The expression '*(char *)0' is undefined behavior if it
>> is evaluated.  Any subsequent cast is irrelevant to the
>> question about whether the behavior is defined.
>>
> If and only if you do not take the text for the unary '*' operator
> literally.  That text describes undefined behaviour when a null
> pointer value has been assigned to the pointer.  Here we have a null
> pointer, not a nuller pointer value assigned to a pointer.
>
> We agreed that it's possible that that text might be imprecise, and
> might need to be addressed, did we not?  But it's also possible that
> it's precise, and there is no undefined behaviour until casting to
> '(void)'.
>
> Would you agree?

I don't.  The wording could be better, but there is no
doubt about the meaning.  The Standard is written in
formal English but it is not a math textbook, and it's
at best a waste of time to read it like one.

If you want to get technical, it can NEVER be the case
that the operand of an indirection operator has been
assigned.  In the expression '*p', where p has been
declared to be of some pointer type, the operand 'p'
has already been converted to a value by virtue of
6.3.2.1p2.  There is no difference between '*p' and
'*(char*)0' in this regard -- both operate on values,
not objects.  So it's completely nonsensical to try to
understand "has been assigned" as applying to one class
of operand expression but not another.  They are all
just values.

On 2010-07-23, Shao Miller <sha0.miller@gmail.com> wrote:
> We agreed that it's possible that that text might be imprecise, and
> might need to be addressed, did we not?  But it's also possible that
> it's precise, and there is no undefined behaviour until casting to
> '(void)'.
>
> Would you agree?

No.  It is adequately precise, adequately clear, and the undefined behavior
is unambiguous.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Shao Miller <sha0.miller@gmail.com> writes:

> On Jul 23, 7:23 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>>
>>   &*(char *)0
>>
>> and
>>
>>   sizeof *(char *)0
>>
>> are explicitly well-defined despite having * applied to a null pointer
>> operand.  This may be the germ of Shao Miller's question.  Since a void
>> expression is evaluated "for its side effects" can the absence of side
>> effects render the expression in question unevaluated?
>>
> 'Twas the original germ, yes.  Then we agreed to take the text
> literally and that the expression is evaluated.  I still didn't see
> any UB, because:
>
> A value for the result of application of the unary '*' is not a
> requirement of the text for the unary '*' operator in 'n1256.pdf'.

It says "if it [the operand] points to an object the result is...".  If
the pointer does not point to an object the behaviour is undefined by
omission.  There is a clarifying clause about invalid pointers but it
adds no new meanings, which is fortunate since it uses the clumsy "if an
invalid value has been assigned to the pointer" phrase.  So *E is
defined only when E points to a function or when E points to an object.
To which function or object does (char *)0 point?

I don't understand your text about "a value for the result of [the]
application" not being "a requirement of the text" but I don't think I
need to.  *E is defined when E points to a function or an object and I
think your example fails both tests.

> Consider:
>
> (*p).f();
>
> Where '(*p)' yields an lvalue (assuming 'p' points to an object), thus
> satisfying the requirement for an object by the membership '.'
> operator.  But ponder what "value" was involved for '(*p)' in this
> case.  The aggregate value of the object pointed to by 'p' in its
> entirety?  I should hardly think so.

Why?  I should think exactly that.

<snip>
> As per my post in response to the original post, and due to the cast
> when casting to '(void)', I now agree.  Not due to application of the
> unary '*' operator to a null pointer which has not been assigned a
> null pointer value.

Let me get this clear.  You are saying that (void)*(char *)0 is UB due
to the cast and, presumably, that *(char *)0 is not because there is no
cast?  If so, I won't ask you to re-rash the argument -- I'll find it in
my news feed if I want to go look.

As you can see from the above, I disagree.

>  See also the challenge with:
>
> *(void *)0;

Also undefined for the same reason.

-- 
Ben.

On Jul 23, 1:30=A0pm, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>
> I don't. =A0The wording could be better, but there is no
> doubt about the meaning.
>
After your fine reference to the text below, I'd have to agree.

>
>=A0The Standard is written in
> formal English but it is not a math textbook, and it's
> at best a waste of time to read it like one.
>
I am not aware of anyone who's reading it like a math textbook and I'd
have to agree.  It could be worth-while reading its fine detail and
discussing and resolving perceived ambiguities, for the case where one
might be interested in developing a translator for C.

>
> If you want to get technical,
>
Indeed I did.

>
> it can NEVER be the case
> that the operand of an indirection operator has been
> assigned. =A0In the expression '*p', where p has been
> declared to be of some pointer type, the operand 'p'
> has already been converted to a value by virtue of
> 6.3.2.1p2. =A0There is no difference between '*p' and
> '*(char*)0' in this regard -- both operate on values,
> not objects. =A0So it's completely nonsensical to try to
> understand "has been assigned" as applying to one class
> of operand expression but not another. =A0They are all
> just values.
This is to me an extremely valuable reference to the text of
'n1256.pdf'.  I agree that with this reference in mind, it's
nonsensical to treat "If an invalid value has been assigned to the
pointer" as being intended to mean anything other than "If the operand
has an invalid value"...  If only the text said "operand."  It
doesn't.  It says "pointer."

Is there any doubt that the operand has a value?  We can assign '(char
*)0' or even '(void *)0' to an object.  I don't think there's any
doubt that the operand has a value.

This could potentially be a cause for confusion, since sentences 2 and
3 explicitly use "operand" and "points to" and "has type".  The next
sentence could very well mean, "if the value of the operand _is_ an
invalid value..." (Emphasis mine.)  It could also mean, "if the value
of the operand was an invalid value assigned to the operand..."

Do you understand why I am asking about all of this?  In the execution
environment if we attempt to access an object at an invalid location,
it should be undisputed as undefined behaviour.  But expression
evaluation !=3D execution.  Evaluation of a constant scalar expression
such as '(char *)0' need not be "executed" at all.  That is to say,
the text defines an attempted object access to an invalid location as
undefined behaviour.  It could even be trapped by the best
implementation.  But evaluation of an expression which is an
application of the unary '*' operator does noes necessitate an object
access to any location.  If it did, the text should include something
like:

"The result of evaluation of the unary '*' operator shall be the value
of an object pointed to by the operand, if the operand point to an
object."

But that might not be the case.  Consider these:

(*p).f();
(*q)->x =3D 10;
*r =3D 11;
(*s)();

For 'p', 'q' and 'r', if they point to an object, the result is an
lvalue.  It's not a "value".  There's no need to "fetch" the "value"
during the indirection at all, is there?  Thus we only get undefined
behaviour if they _don't_ point to an object, which is a determination
that might only be possible during execution.

For 's', the indirection is intended to result in a function
designator.  Not an lvalue.  Not a "value".

It is clear that many people have tied evaluation of the unary '*'
operator to "yielding an object, pointed-to by the operand" in their
thinking.  But this is not the case.

Also consider a Turing machine implementation with a tape and a head.
In the 'q' example above, if 'q' were assigned the value '(struct foo
*)0', the head might move to position zero, where "read" and "write"
are invalid.  No read nor write is attempted.  Then the head moves by
the offset of the 'x' member.  At last, we attempt a write when we
assign, assuming that reads and writes are valid at that position.
Why should there be undefined behaviour by moving the head to position
0 any more so than to any other location which is invalid for objects
or for which the validity is not guaranteed?

Does anyone understand why "has been assigned" could be important?

char *p;
*p =3D 'Y';

If the Turing machine's head attempts to move to the location as per
'p', that location might not be a valid location for the head to move
to.  Undefined behaviour.  But how can you have _an_expression_ with a
_constant_scalar_value_ at _translation_time_ (let alone during
execution) possibly represent an invalid location for the head to move
to?

Shao Miller <sha0.miller@gmail.com> writes:
> On Jul 23, 12:43 pm, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>>
>> The expression '*(char *)0' is undefined behavior if it
>> is evaluated.  Any subsequent cast is irrelevant to the
>> question about whether the behavior is defined.
>>
> If and only if you do not take the text for the unary '*' operator
> literally.  That text describes undefined behaviour when a null
> pointer value has been assigned to the pointer.  Here we have a null
> pointer, not a nuller pointer value assigned to a pointer.
>
> We agreed that it's possible that that text might be imprecise, and
> might need to be addressed, did we not?  But it's also possible that
> it's precise, and there is no undefined behaviour until casting to
> '(void)'.
>
> Would you agree?

I certainly agree that the wording in the description of unary "*"
needs to be improved.  On the other hand, I think the intent is
reasonably unambiguous.

6.5.3.2p4:

    The unary * operator denotes indirection. If the operand points
    to a function, the result is a function designator; if it points
    to an object, the result is an lvalue designating the object. If
    the operand has type ‘‘pointer to type’’, the result
    has type ‘‘type’’. If an invalid value has been assigned
    to the pointer, the behavior of the unary * operator is undefined.

The phrase "has been assigned to" makes sense only for a pointer
*object*, but the operand of "*" needn't be an lvalue; it can be any
arbitrary expression of pointer type.

The unqualified word "pointer" very often means "pointer object",
but it can also mean "pointer value"; see, for example, the Standard's
description of the value returned by malloc().  I think the author of
the above paragraph just momentarily failed to make the distinction
properly.

The intent is that applying "*" to an invalid pointer value has
undefined behavior; a null pointer is "invalid" in this context).
I'm sure beyond reasonable doubt that the authors intended this to
apply whether the operand is an lvalue or not.  Apart from having
it apply only to lvalues being nonsensical, if that were the intent
it could have been worded much more clearly.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

On Jul 23, 2:02=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> No. =A0It is adequately precise, adequately clear, and the undefined beha=
vior
> is unambiguous.
>
Thank you for your opinion.  I would have also appreciated some
reasoning, in order to help to convince myself of this.  The opinion
is appreciated regardless of the lack of reasoning.  Poll-wise,
dereferencing a null pointer is undefined behaviour during
evaluation.  Reason-wise, it's still incomplete, for me.

On Jul 23, 2:31=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> It says "if it [the operand] points to an object the result is...". =A0If
> the pointer does not point to an object the behaviour is undefined by
> omission.
>
But it also defines the result in terms of its type, based on the type
of the operand.  In our situation, this is defined.  The omission of
when the pointer does not point to an object only impacts the
definition of the result, _when_ that result is an _lvalue_.  It
doesn't apply to functions, for example.  The "has type" clause covers
all three situations:
1. The operand points to an object
2. The operand points to a function
3. The operand points to neither, but has a pointer type

>
> There is a clarifying clause about invalid pointers but it
> adds no new meanings, which is fortunate since it uses the clumsy "if an
> invalid value has been assigned to the pointer" phrase.
>
Whole-heartedly agreed as clumsy, if and only if it's not explicitly
there for a good reason.

>
>=A0So *E is
> defined only when E points to a function or when E points to an object.
> To which function or object does (char *)0 point?
>
Its type is defined when the operand has a pointer type.  It's
_further_ defined as an lvalue or a function designator, under certain
_additional_ circumstances.

>
> I don't understand your text about "a value for the result of [the]
> application" not being "a requirement of the text" but I don't think I
> need to. =A0*E is defined when E points to a function or an object and I
> think your example fails both tests.
>
Again, what do you mean by '*E'?  Do you mean "the value of '*E'" or
"the type of '*E'" or both or neither or more than both?

>
> Why? =A0I should think exactly that.
>
So when 'p' points to a structure and we apply '*' to it, you suggest
that evaluation entails the requirement for knowing the value of '*p'
altogether?  If so, does that knowledge require fetching the value?

>
> Let me get this clear. =A0You are saying that (void)*(char *)0 is UB due
> to the cast
>
The cast to 'void', yes, since a cast requires a value.

>
> and, presumably, that *(char *)0 is not because there is no
> cast?
>
There is no cast in evaluation of this expression that requires a
value for '*(char *)0'.  One versus two casts, above.  Note that the
result of '*(char *)0' has type 'char', and is thus not a void
expression.  '*(void *)0' has type 'void', is is thus a void
expression.

>
>=A0If so, I won't ask you to re-rash the argument -- I'll find it in
> my news feed if I want to go look.
>
I apologize for re-hashing it anyway, should that inconvenience you.
Perhaps it'll help someone else.

>
> As you can see from the above, I disagree.
>
That's fine, and your attention has been appreciated.  I mean it.

>
> Also undefined for the same reason.
>
Uncertain for me.

On Jul 23, 4:00=A0pm, Keith Thompson <ks...@mib.org> wrote:
>
> I certainly agree that the wording in the description of unary "*"
> needs to be improved.
>
Agreed.  Thank you.

>
> On the other hand, I think the intent is
> reasonably unambiguous.
>
If I had been able to find a discussion concerning this agreed-upon
ambiguity, I would have said "somewhat unambiguous."  This is the
first discussion I am aware of, so I would say "all but entirely
unambiguous." :)

>
> The phrase "has been assigned to" makes sense only for a pointer
> *object*, but the operand of "*" needn't be an lvalue; it can be any
> arbitrary expression of pointer type.
>
Agreed.  Thanks.

>
> The unqualified word "pointer" very often means "pointer object",
> but it can also mean "pointer value"; see, for example, the Standard's
> description of the value returned by malloc().
>
Agreed.  Thanks.

>
> I think the author of
> the above paragraph just momentarily failed to make the distinction
> properly.
>
Possibly.  But the use of "operand" in the other sentences, the use of
"value of" in other parts of the text for other operators, does leave
me uncertain.

>
> The intent is that applying "*" to an invalid pointer value has
> undefined behavior; a null pointer is "invalid" in this context).
> I'm sure beyond reasonable doubt that the authors intended this to
> apply whether the operand is an lvalue or not. =A0Apart from having
> it apply only to lvalues being nonsensical, if that were the intent
> it could have been worded much more clearly.
>
This intent certainly seems likely if we treat the responses to this
discussion as providing evidence for intended meaning to common
interpretation.  Thank you for this type of evidence, for what it's
worth.

On 2010-07-23, Shao Miller <sha0.miller@gmail.com> wrote:
> Thank you for your opinion.  I would have also appreciated some
> reasoning, in order to help to convince myself of this.  The opinion
> is appreciated regardless of the lack of reasoning.  Poll-wise,
> dereferencing a null pointer is undefined behaviour during
> evaluation.  Reason-wise, it's still incomplete, for me.

I really don't think the problem is reasoning, because you've seen tons
of that, and it's had no effect whatsoever.  I don't know what the issue
is; this really is pretty straight forward.  '(char *) 0' is a pointer, and
it does not point to a valid object, therefore, '*(char *) 0' is undefined
behavior to evaluate.  In the abstract machine, expressions are evaluated,
with a few specialized exceptions (such as sizeof).  So whether or not you
cast it, or use the value, the expression *is* evaluated, and evaluating the
expression produces undefined behavior.

I honestly can't see what the confusing part is.  The expression is
evaluated, and evaluating the expression yields undefined behavior, therefore
undefined behavior occurs.  There's nothing tricky or fancy going on.
The only possible problems with the wording are cases in which it's still
clear what is intended, even if the text is poorly-phrased.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On 2010-07-23, Shao Miller <sha0.miller@gmail.com> wrote:
> But it also defines the result in terms of its type, based on the type
> of the operand.  In our situation, this is defined.  The omission of
> when the pointer does not point to an object only impacts the
> definition of the result, _when_ that result is an _lvalue_.

No, it impacts the definition of what happens.  There is no definition
given for what happens.

Okay, look at it this way:

	*(char *) 0

What is the defined result of evaluating this expression?  Show us the
explicit definition of what you get when you evaluate this.

If you can't, it's undefined.  Failure-to-define is sufficient to make
behavior undefined; even if you don't think there's an explicit statement that
it's undefined, unless you can provide the definition, it's still undefined.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On Jul 23, 5:10=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> No, it impacts the definition of what happens. =A0There is no definition
> given for what happens.
>
> Okay, look at it this way:
>
> =A0 =A0 =A0 =A0 *(char *) 0
>
> What is the defined result of evaluating this expression? =A0Show us the
> explicit definition of what you get when you evaluate this.
>
> If you can't, it's undefined. =A0Failure-to-define is sufficient to make
> behavior undefined; even if you don't think there's an explicit statement=
 that
> it's undefined, unless you can provide the definition, it's still undefin=
ed.
>
Thank you for this feedback once again, Seebs.

*(char *)0

is an expression defined to evaluate to a result having type 'char'.
The operand for the unary '*' operator has type pointer-to-char, which
is why.

Now then, if the operand points to an object, the result is
furthermore an lvalue.

If the operand points to a function, the result is furthermore a
function designator.

Seems defined quite nicely to me.  Do you see any error with this
reasoning?  Does the text of 'n1256.pdf' stipulate that the result of
this expression is required to have anything _more_ than a type; that
it must additionally be at least one of an lvalue or a function
designator?

Tim Rentsch wrote:
> 
> pete <pfiland@mindspring.com> writes:
> 
> > Tim Rentsch wrote:

> >> Wrong operator.  Indirection is '*', not '&'.
> >
> > I was discussing '*'.

> I know that, but the paragraph you quoted was talking
> about the address operator, not the indirection operator.

Oops!

-- 
pete

On 2010-07-23, Shao Miller <sha0.miller@gmail.com> wrote:
> *(char *)0

> is an expression defined to evaluate to a result having type 'char'.
> The operand for the unary '*' operator has type pointer-to-char, which
> is why.

And what is that result?

> Now then, if the operand points to an object, the result is
> furthermore an lvalue.

It doesn't point to an object.  But it does point to an object type.

	The unary * operator denotes indirection. If the operand points to
	a function, the result is a function designator; if it points to
	an object, the result is an lvalue designating the object. If the
	operand has type "pointer to type", the result has type "type". If
	an invalid value has been assigned to the pointer, the behavior of
	the unary * operator is undefined.)

There are three ways we can consider this text.  Both yield identical
conclusions.

METHOD #1:

"Has been assigned to" is clumsy wording, but it obviously includes any
possible case in which a pointer *has* an invalid value.  A null pointer
is by definition invalid, because it doesn't point to an object.  The
behavior is undefined.

METHOD #2:

Consider more closely this sentence:
	If the operand points to a function, the result is a function
	designator; if it points to an object, the result is an
	lvalue designating the object.

This offers the sum total of definitions of the behavior of the unary-*
operator.  Since the operand does not point to a function or an object, its
behavior is not defined by this sentence.  The behavior is undefined.

METHOD #3:

Let's imagine that the "type" argument is meaningful, and that since the
operand has a *type* of a pointer-to-object, the result is "an lvalue
designating the object".  Then let's see 6.3.2.1, paragraph 1:

	An lvalue is an expression with an object type or an
	incomplete type other than void; if an lvalue does not
	designate an object when it is evaluated, the behavior is
	undefined.

It does not designate an object, we evaluate it, therefore the behavior is
undefined.

What it comes down to is:  Dereferencing null pointers yields undefined
behavior.  We know this, the standard is adequately clear on it, and running
around ignoring parts of it at random or adding extra significance to
"has been assigned" does not change it.  The indirection operator does not
have any defined behavior when applied to something which is not a pointer
to an object.  The behavior is undefined.  It is up to you whether you prefer
to think of this as being undefined because the lvalue does not generate
an object, or because * is not defined in its behavior when not given a
pointer to an object-or-function; either way, it's undefined.

We could doubtless improve the text with something like "if the pointer
does not point to an object or function, the behavior is undefined", but
that the text could be improved does not mean that there is any ambiguity
here.  In some cases, you can assert confidently that the wording is
poor but that the meaning is clear, and this is one of those cases.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Shao Miller <sha0.miller@gmail.com> writes:

> On Jul 23, 2:31 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>>
>> It says "if it [the operand] points to an object the result is...".  If
>> the pointer does not point to an object the behaviour is undefined by
>> omission.
>>
> But it also defines the result in terms of its type, based on the type
> of the operand.  In our situation, this is defined.  The omission of
> when the pointer does not point to an object only impacts the
> definition of the result, _when_ that result is an _lvalue_.  It
> doesn't apply to functions, for example.  The "has type" clause covers
> all three situations:
> 1. The operand points to an object
> 2. The operand points to a function
> 3. The operand points to neither, but has a pointer type

No.  You are playing games with the language.  Two clauses of one
sentence (separated by ;) talk about the result.  A separate sentence
talks about the type.  These are not three cases but two attributes of
this form of expression.

C defines the type of many expression forms whether the result is
defined or not.  << and >> expressions have the type of the promoted
left operand.  In some cases the result (or behaviour) is undefined.
The fact that the type is known does not make all << and >> expressions
defined.

What, in your opinion, is the result of the expression *(char *)0?  If
you can't find words from that standard to explain what the result is
(not just its type) then it is undefined by omission.

>> There is a clarifying clause about invalid pointers but it
>> adds no new meanings, which is fortunate since it uses the clumsy "if an
>> invalid value has been assigned to the pointer" phrase.
>>
> Whole-heartedly agreed as clumsy, if and only if it's not explicitly
> there for a good reason.

It's clear we disagree about that phrase too.  Presumably you accept as
valid code like this:

  int *ip;
  { int i = 42; ip = &i; }
  *ip = 0;

because no invalid pointer has been assigned to ip -- the pointer has
merely become invalid without any assignment.

>> So *E is
>> defined only when E points to a function or when E points to an object.
>> To which function or object does (char *)0 point?
>>
> Its type is defined when the operand has a pointer type.  It's
> _further_ defined as an lvalue or a function designator, under certain
> _additional_ circumstances.

Yes and, by omission, when neither circumstance applies nothing more can be
inferred about the result (from the standard).  This is the definition of
undefined.  That the expression has type is not in dispute (my original
intervention using sizeof *(char *)0 relies on the expression having a
type) by a type does not mean that the expression has a defined result.

>> I don't understand your text about "a value for the result of [the]
>> application" not being "a requirement of the text" but I don't think I
>> need to.  *E is defined when E points to a function or an object and I
>> think your example fails both tests.
>>
> Again, what do you mean by '*E'?  Do you mean "the value of '*E'" or
> "the type of '*E'" or both or neither or more than both?

I mean the expression form (E was a kind of syntax place-holder) is
undefined.  It often has a type, but its evaluation has no defined
result.

>> Why?  I should think exactly that.
>>
> So when 'p' points to a structure and we apply '*' to it, you suggest
> that evaluation entails the requirement for knowing the value of '*p'
> altogether?  If so, does that knowledge require fetching the value?

The result of *p is the entire object.  I can't answer your first
question because I don't know what "knowing the value of *p altogether"
means (the problem word for me is "knowing").  As for the second, all
reasonable compilers will look to see what is actually used from *p
to avoid fetching any more than is needed.

  *p; /* probably fetch nothing (volatile objects excepted) */
  s = *p; /* probably fetch it all -- at least we know where to put it */
  (*p).m; /* probably behaves like p->m (i.e. only m is fetched) */

<snip>
-- 
Ben.

On Jul 23, 5:49=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> And what is that result?
>
What is "what"?  The result is defined to have a type.  The result
_is_ a result.  It _has_ a type.

>
> It doesn't point to an object. =A0But it does point to an object type.
>
Agreed for '(char *)0'.  Not so for '(void *)0'.  I'm with you here,
though.

>
> There are three ways we can consider this text. =A0Both yield identical
> conclusions.
>
> METHOD #1:
>
> "Has been assigned to" is clumsy wording, but it obviously includes any
> possible case in which a pointer *has* an invalid value.
>
Agreed on clumsy wording, if and only if it's not _intentional_.  That
remains to be proven or at the very least, demonstrated.  What makes
this obvious to you?

>
>=A0A null pointer
> is by definition invalid,
>
Invalid _what_?  A null pointer is a valid value for assignment, is it
not?  If you are specifically referring to the context of the
evaluation of the expression '*(char *)0', your claim just above
_requires_ us to accept your previous claim before that; namely, that
"has been assigned" is clumsy and that it includes the case where the
pointer _has_ an invalid value.  Furthermore, the non-normative
footnote is the only clue we have as to the possibility of a null
pointer being such an invalid value.

>
> because it doesn't point to an object. =A0The
> behavior is undefined.
>
You have invented the requirement for the pointer operand to "point to
an object".  Consider a function pointer.  You have invented
supposedly undefined behaviour.  In this Method #1, you have not
convinced me, I'm sorry to say.  I was hopeful.  It might even be of
no consequence to you whether I've been convinced or not.  That's
fine.

Where I might say "invented" below, I additionally mean, "or have not
cited a reference which supports."

>
> METHOD #2:
>
> Consider more closely this sentence:
> =A0 =A0 =A0 =A0 If the operand points to a function, the result is a func=
tion
> =A0 =A0 =A0 =A0 designator; if it points to an object, the result is an
> =A0 =A0 =A0 =A0 lvalue designating the object.
>
> This offers the sum total of definitions of the behavior of the unary-*
> operator.
Considered.  You have just invented the offering that this sentence is
the sum total of definitions of the behaviour for the operator.  If
that were so, we could discard the statement regarding type.  In fact,
why is that statement in there at all?  If the sentence you reference
just above is the "sum total" you describe, why would there be any
reason to add a further definition for the result's type?  I propose
that the evaluation result can thus have a type and not be one of an
lvalue, a function designator.  I would be much more convinced of the
validity of this Method #2 if the referenced text either explained
that one of these possibilities is required, or some other portion of
the draft explained that sentences like these have such a requirement
implicitly.  This Method #2 does not address the "has been assigned to
the pointer", which would make it even more convincing to me.

>
>=A0Since the operand does not point to a function or an object, its
> behavior is not defined by this sentence. =A0The behavior is undefined.
>
This claim requires acceptance of the disputed claim above whereby the
sentence is the "sum total" of definitions for the result of
evaluation.  Acceptance of that claim means we can discard the
possibility of invalid values being assigned to the pointer.  Thus,
the "has been assigned to" sentence could be discarded.  So why is it
in there at all, along with the definition of the type?

>
> METHOD #3:
>
> Let's imagine that the "type" argument is meaningful, and that since the
> operand has a *type* of a pointer-to-object, the result is "an lvalue
> designating the object".
>
It does _not_ have type pointer-to-object.  The expression '(char *)0'
has type pointer-to-char.  'char' can certainly _be_ the type _for_ an
object.  '(char *)0' certainly _isn't_ a pointer-to-object, as it is a
null pointer, "guaranteed to compare unequal to a pointer to any
object or function" according to 6.3.2.3, point 3.  The result is thus
_not_ "an lvalue designating the object."

>
> Then let's see 6.3.2.1, paragraph 1:
>
> =A0 =A0 =A0 =A0 An lvalue is an expression with an object type or an
> =A0 =A0 =A0 =A0 incomplete type other than void; if an lvalue does not
> =A0 =A0 =A0 =A0 designate an object when it is evaluated, the behavior is
> =A0 =A0 =A0 =A0 undefined.
>
> It does not designate an object, we evaluate it, therefore the behavior i=
s
> undefined.
>
This claim requires acceptance of the disputed claim above that the
result must be an lvalue because the type of the operand is pointer-to-
char.  If the result is not an lvalue, evaluation of the result is not
evaluation of an lvalue and the above reference does not apply.

>
> What it comes down to is: =A0Dereferencing null pointers yields undefined
> behavior. =A0We know this, the standard is adequately clear on it,
>
We _don't_ know this.  Some of us, possibly the majority, _believe_
it.  According to some of your arguments, the standard is adequately
clear on it.  Why then does Method #1 detail "clumsy wording"?  That
would appear to make it inadequately clear.  Do we discard Method #1
or do you instead mean, "so far, everyone I've ever known to interpret
null pointer indirection shares the interpretation I have."

>
> and running
> around ignoring parts of it at random
>
Which parts have been ignored?  Your 6.3.2.1, point 1 has been
considered and responded to.  If I have ignored a cited reference in
another responder's response, then I would be glad of it being brought
to my attention, so I can settle this matter to rest once and for all,
and forget about all of the opinions, inventions, and what appear to
be some plain-and-simple "No, you can't [but I cannot seem to put my
finger on exactly why]" responses that I am interpreting.

I'm not running around.  I'm not dead-set in thinking that there
_is_no_ undefined behaviour.  I found that there _is_ undefined
behaviour for evaluation of the expression '(void)*(cast *)0;'  Nobody
has shown it (UB for '*(char *)0' yet to a satisfactorily reasonable
degree without invoking "I don't believe the intended meaning is
congruent with your interpretation; the wording could be improved"  I
have provided a few arguments regarding _no_need_ for the evaluated
result to imply undefined behaviour; only the remote possibility that
implementations with a desire to conform might need to be aware of or
revisit a couple of scenarios and treat the behaviour as defined
rather than undefined.  I was hopeful that "obvious" meant that there
was a simple sequence of reasoning to follow based on the text of the
draft or of a standard of C.  This hope remains, with the kind
intentions and assistance of responders such as yourself.

>
> or adding extra significance to
> "has been assigned" does not change it.
>
This is backwards.  I am _not_deducting_ significance from "has been
assigned."  You and other kind responders have been deducting.  My
arguments treat the significance literally, do they not?

>
>=A0The indirection operator does not
> have any defined behavior when applied to something which is not a pointe=
r
> to an object.
>
Except that pointers to functions are defined, as well as with the
defined behaviour of having a result with a type.  Thus this claim is
false.  The claim does, however, certainly re-emphasize the
commonality of this argument throughout this thread.

>
> The behavior is undefined. =A0It is up to you whether you prefer
> to think of this as being undefined because the lvalue does not generate
> an object, or because * is not defined in its behavior when not given a
> pointer to an object-or-function; either way, it's undefined.
>
You require one of the previous claims to be true here.  You suggest
that the definition of the result's type makes for an incomplete
definition for the result.  I shall continue to choose "looks as
though it's defined," instead.  This might be of no consequence to
you, but I do appreciate your attempts to provide evidence.

>
> We could doubtless improve the text with something like "if the pointer
> does not point to an object or function, the behavior is undefined", but
> that the text could be improved does not mean that there is any ambiguity
> here.
>
You have brought to light two points of ambiguity:
1. The semantic point including "has been assigned to" may only be
intended to mean "if the value of the pointer is an invalid value."
In which case, there still is no normative definition for what
constitutes an invalid value, though we have a hint from the footnote.
2. The semantic point's sentence regarding the result's type should
not be specified independently from the other two definitions of
_possible_ properties of the result, given certain circumstances.

>
>=A0In some cases, you can assert confidently that the wording is
> poor but that the meaning is clear, and this is one of those cases.
>
At this time, I cannot.  You and some others have.

Thank you so much!

Shao Miller <sha0.miller@gmail.com> writes:

> On Jul 23, 5:49 pm, Seebs <usenet-nos...@seebs.net> wrote:
>>
>> And what is that result?
>>
> What is "what"?  The result is defined to have a type.  The result
> _is_ a result.  It _has_ a type.

Oh, be serious!

6.5 Expressions
 
  1 An expression is a sequence of operators and operands that specifies
    computation of a value, or that designates an object or a function,
    or that generates side effects, or that performs a combination
    thereof.

What about the expression *(char *)0?  Does it generate side-effects?
No.  Does it designate an object or a function?  No.  It must therefore
specify the computation of a value.  We are all certain of the type of
that value (char) by we don't yet know which of the many chars is it.

By the way, I am happy just to agree to disagree about this.  I'll
continue to write C avoiding constructs like *(char *)0 and so will you!

-- 
Ben.

On 2010-07-23, Shao Miller <sha0.miller@gmail.com> wrote:
> On Jul 23, 5:49�pm, Seebs <usenet-nos...@seebs.net> wrote:

>> And what is that result?

> What is "what"?  The result is defined to have a type.  The result
> _is_ a result.  It _has_ a type.

But unless we know what the result is -- not just its type -- it is
NOT DEFINED.

> Agreed for '(char *)0'.  Not so for '(void *)0'.  I'm with you here,
> though.

Yes, so "*(void *) 0" is a constraint violation.

> Agreed on clumsy wording, if and only if it's not _intentional_.  That
> remains to be proven or at the very least, demonstrated.  What makes
> this obvious to you?

Complete consistency across dozens of implementations and the last thirty
years of writing about C, reading about C, programming in C, and looking
at the code to implementations.  I was on the committee.  We have all, always,
agreed absolutely that dereferencing null pointers is clearly and
unambiguously undefined behavior.

>>�A null pointer
>> is by definition invalid,

> Invalid _what_?

An invalid pointer -- as opposed to one which points to an object.

>A null pointer is a valid value for assignment, is it
> not?  If you are specifically referring to the context of the
> evaluation of the expression '*(char *)0', your claim just above
> _requires_ us to accept your previous claim before that; namely, that
> "has been assigned" is clumsy and that it includes the case where the
> pointer _has_ an invalid value.  Furthermore, the non-normative
> footnote is the only clue we have as to the possibility of a null
> pointer being such an invalid value.

No, it doesn't.  It only requires that we understand that the standard
is consistent about referring to a pointer which does not definitely point
to an object as "invalid".  (Invalid includes both null pointers and to
objects whose lifetime is over.)

>> because it doesn't point to an object. �The
>> behavior is undefined.

> You have invented the requirement for the pointer operand to "point to
> an object".

No, I haven't.

I have observed that there is no definition provided for the behavior of
indirection through a pointer which does not point to either an object or
a function.

> It might even be of
> no consequence to you whether I've been convinced or not.  That's
> fine.

At this point, I see nothing in any of your posts to suggest that you are
even sincere; you are acting precisely like a troll.

> Where I might say "invented" below, I additionally mean, "or have not
> cited a reference which supports."

Because obviously, accusing someone of lying (which is what "invented" means
in this context) is the clearest way to communicate that you didn't see or
understand a citation.

> Considered.  You have just invented the offering that this sentence is
> the sum total of definitions of the behaviour for the operator.

No, I haven't.

First off, "invented" means "newly created", and that is precisely equivalent
to accusing me of lying about what the standard says.  I see no real reason
to continue arguing with you at this point.

Secondly, that is the ENTIRE POINT of a standard.  It is the sum total of
the definition.  You have not offered or cited or suggested or hinted at
any explanation of what value should be yielded by dereferencing a null
pointer, *because there is none*.  That means it's undefined.  If it were
defined, we would know not only its type, but its value.

> If that were so, we could discard the statement regarding type.

No, we couldn't, because the value and the type are two different things,
and it is in some cases possible to dispute which type an expression would
have even knowing its value.

> It does _not_ have type pointer-to-object.  The expression '(char *)0'
> has type pointer-to-char.

Yes, and since char is an object type, pointer-to-char is a pointer-to-object
type, as opposed to a pointer to an incomplete type or a pointer to a function
type.

> 'char' can certainly _be_ the type _for_ an
> object.  '(char *)0' certainly _isn't_ a pointer-to-object, as it is a
> null pointer, "guaranteed to compare unequal to a pointer to any
> object or function" according to 6.3.2.3, point 3.  The result is thus
> _not_ "an lvalue designating the object."

And that means that the standard does not define the results of the
indirection.

What is not defined is undefined.  QED.

And because you are either an idiot or an unbelievable jerk, I'm plonking
you.  You can't possibly be this stupid, and there is no way I'm putting
up with your continued totally unsupported accusations that other people are
lying.  The only way that could be unintentional would be if your English
skills were weak enough that it is necessarily trolling for you to be
arguing with people about what they think sentences in English mean.

Either you should stop disputing peoples' interpretations of English, or you
know it well enough that the accusations of dishonesty are clearly
intentional.  Either way, we're done, and I sincerely hope I never have to
see anything you have to say again.  Go away.  You do not have an attitude
conducive to learning about C, or any other language, and with the way you've
treated people, I see no reason to believe you will ever acquire one.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Shao Miller <sha0.miller@gmail.com> writes:
> On Jul 23, 5:49 pm, Seebs <usenet-nos...@seebs.net> wrote:
>>
>> And what is that result?
>>
> What is "what"?  The result is defined to have a type.  The result
> _is_ a result.  It _has_ a type.

And a value.  What is the value of the result?  Nothing in the standard
defines what that value is, therefore the value is undefined.

[...]

>> "Has been assigned to" is clumsy wording, but it obviously includes any
>> possible case in which a pointer *has* an invalid value.
>>
> Agreed on clumsy wording, if and only if it's not _intentional_.  That
> remains to be proven or at the very least, demonstrated.  What makes
> this obvious to you?

How could it be intentional?  If it's intentional, it doesn't make any
sense.

Once again, here's the passage in question, 6.5.3.2p4:

    The unary * operator denotes indirection. If the operand points
    to a function, the result is a function designator; if it points
    to an object, the result is an lvalue designating the object. If
    the operand has type ‘‘pointer to type’’, the result has
    type ‘‘type’’. If an invalid value has been assigned to
    the pointer, the behavior of the unary * operator is undefined.

It is not possible to assign a value, invalid or otherwise, to "the
pointer" unless "the pointer" is a pointer object.  The context does not
imply the existence of any pointer object to which the phrase "the
pointer" could refer.  Even if the operand happens to be an lvalue,
it is no longer an lvalue (and thus no longer designates an object)
before the "*" operator is applied to it.  6.3.2.1p2:

    Except when it is the operand of [list snipped] an lvalue that
    does not have array type is converted to the value stored in
    the designated object (and is no longer an lvalue).

The author implicitly assumed the existence of a pointer object that
does not exist.

[big snip]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> 6.5 Expressions
>  
>   1 An expression is a sequence of operators and operands that specifies
>     computation of a value, or that designates an object or a function,
>     or that generates side effects, or that performs a combination
>     thereof.
>
> What about the expression *(char *)0?  Does it generate side-effects?
> No.  Does it designate an object or a function?  No.  It must therefore
> specify the computation of a value.  We are all certain of the type of
> that value (char) by we don't yet know which of the many chars is it.

(void)0 neither computes a value, nor designates an object or function,
nor generates side effects, or any combination thereof.

This is yet another reason the standard's definition of "expression" is
flawed.  The other is that some expressions, for example 42, contain no
operators or operands.

It's not *fatally* flawed; I don't think it's led anyone to an incorrect
understanding of what "expression" means.  But a more accurate
definition would refer to the syntax.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

On Fri, 23 Jul 2010 19:50:15 -0400, Ben Bacarisse <ben.usenet@bsb.me.uk>  
wrote:
....
> What about the expression *(char *)0?  Does it generate side-effects?
> No.

Can you point to anything in the standard which says that the expression
doesn't generate side-effects?  Since evaluating that expression results
in undefined behavior, I would argue that whether or not there are side
effects is undefined.
-- 
Morris Keesan -- mkeesan@post.harvard.edu

"Morris Keesan" <mkeesan@post.harvard.edu> writes:

> On Fri, 23 Jul 2010 19:50:15 -0400, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
> ...
>> What about the expression *(char *)0?  Does it generate side-effects?
>> No.
>
> Can you point to anything in the standard which says that the expression
> doesn't generate side-effects?  Since evaluating that expression results
> in undefined behavior, I would argue that whether or not there are side
> effects is undefined.

Shao Miller does not believe that.  I was taking him through the
consequences of that belief so that he would have to say what value the
expression has.

-- 
Ben.

On Jul 23, 7:25=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> No. =A0You are playing games with the language. =A0Two clauses of one
> sentence (separated by ;) talk about the result. =A0A separate sentence
> talks about the type. =A0These are not three cases but two attributes of
> this form of expression.
>
I did not intend to play games with the language.  If that has been
the case, then I sincerely apologize for doing so.  Any inability of
my own to have implicitly understood this is nobody's challenge but
mine.  Perhaps I have been confused surrounding "expressions" and
"results".  The simplest way for me to accept your claim would be to
assert that "every expression must have a value."  Since there is no
definition of a value for this scenario, that would quite simply lead
to an incompletely defined result, which I would be happy to call
"undefined behaviour" regarding the evaluation of the expression, or
even during execution.

>
> C defines the type of many expression forms whether the result is
> defined or not.
>
Here again, I was possibly missing the equivalence between "value" and
"result."  Often interchangeable in everyday usage, I perhaps have
incorrectly assumed that the referenced C draft might have very
specific meanings for each and might distinguish them.  In the
original post, we see a definition for "value" which could easily
contribute to such a misunderstanding.

>
>=A0<< and >> expressions have the type of the promoted
> left operand. =A0In some cases the result (or behaviour) is undefined.
> The fact that the type is known does not make all << and >> expressions
> defined.
>
Your argument for tying both "type" and "value" together before
yielding a defined result is a very good one.  By my previous
suggestions, "The type of the result is
that of the promoted left operand" for these two operators would again
yield a result with a type, but possibly no defined value.  The text
for these operators does seem to cover all possibilities however,
signed, unsigned, UB, implementation-defined.  The constraint for
"integer type" helps.  You cannot have an integer type which is
neither signed nor unsigned.  It would be nice if a constraint for the
unary '*' operator were that the pointer must either point to an
object or to a function.  Perhaps some kind reader could introduce
such a constraint into a future standard.  Thanks for this reference,
Ben.

>
> What, in your opinion, is the result of the expression *(char *)0? =A0If
> you can't find words from that standard to explain what the result is
> (not just its type) then it is undefined by omission.
>
Here again I can only say "result with a type".  Accepting that
evaluation of an expression shall yield a result with both type and
value means that I would have to say that '*(char *)0' is an
incompletely defined result, which I would happily call undefined
behaviour.

>
> It's clear we disagree about that phrase too. =A0Presumably you accept as
> valid code like this:
>
> =A0 int *ip;
> =A0 { int i =3D 42; ip =3D &i; }
> =A0 *ip =3D 0;
>
I accept this code as guaranteed to imply UB.  If responsible for some
portion of development of a C implementation advertising conformance
and criticized by a stake-holder regarding diligence in regards to
this kind of code, I would be much more confident to be able to point
at the (albeit, non-normative) footnote which suggests that 'ip' _has_
been assigned a value which is "the address of an object after the end
of its lifetime".  I would be less confident without.

>
> because no invalid pointer has been assigned to ip -- the pointer has
> merely become invalid without any assignment.
>
I disagreed above, meaning I believe we share a qualification for
"undefined behaviour" here.

>
> Yes and, by omission, when neither circumstance applies nothing more can =
be
> inferred about the result (from the standard). =A0This is the definition =
of
> undefined. =A0That the expression has type is not in dispute (my original
> intervention using sizeof *(char *)0 relies on the expression having a
> type) by a type does not mean that the expression has a defined result.
>
This is possible misunderstanding of mine has been detailed twice
above.  You appear to suggest that the semantics must define both a
value and a type to accomplish a defined result.  Anything less is
undefined.

>
> I mean the expression form (E was a kind of syntax place-holder) is
> undefined. =A0It often has a type, but its evaluation has no defined
> result.
>
Ok.

>
> The result of *p is the entire object.
>
This troubles me just a bit, due to section 6.5, point 2.  I would
worry that in:

*x =3D *x + 1;

That we have "read" the "prior value" twice, inappropriately, for each
evaluation of the unary '*' operator.  I have not fully explored this
avenue of thought and do not intend it as an argument by any means.
Please feel free to discard.

>
>=A0I can't answer your first
> question
>
That you have answered any of the questions at all is valuable for
anyone concerned about the subject.

>
> because I don't know what "knowing the value of *p altogether"
> means (the problem word for me is "knowing"). =A0As for the second, all
> reasonable compilers will look to see what is actually used from *p
> to avoid fetching any more than is needed.
>
Agreed.

>
> =A0 *p; /* probably fetch nothing (volatile objects excepted) */
> =A0 s =3D *p; /* probably fetch it all -- at least we know where to put i=
t */
> =A0 (*p).m; /* probably behaves like p->m (i.e. only m is fetched) */
>
Also agreed.  This makes me curious about something like:

int main(void) {
  static int foo =3D 15;
  struct bar {
    char c[(size_t)&foo];
    int baz;
  };
  return (*(struct foo *)0).baz;
}

for the not-yet-accepted (disputed) interpretation that something like
moving a Turing machine's head to position 0 but then moving it by the
offset of 'baz' before reading or writing to a potential object might
be a reasonable thing to do in C.  (The common response has been that
it's UB to try this.)  Some implementations might allow for such
behaviour, but that's obviously not evidence of any sort that it's not
UB.

My sense after your post here is that it would be very easy to let go
of any uncertainty regarding the un/defined behaviour of '*(char *)0'
and friends if we easily accept that a result must have a defined
value and a defined type.  Thanks for that, Ben.

On Jul 23, 7:50=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> Oh, be serious!
>
Please accept my apologies for not meeting your expectations for
serious discussion.  I will try harder. :)

>
> 6.5 Expressions
>
> =A0 1 An expression is a sequence of operators and operands that specifie=
s
> =A0 =A0 computation of a value, or that designates an object or a functio=
n,
> =A0 =A0 or that generates side effects, or that performs a combination
> =A0 =A0 thereof.
>
This fine reference is _extremely_ helpful in accepting that
evaluation of an expression (which we don't do for sizeof, for
example, but _as_defined_ for sizeof) implies both a type and a
value.  Thank you, Ben!

>
> What about the expression *(char *)0? =A0Does it generate side-effects?
> No. =A0Does it designate an object or a function? =A0No. =A0It must there=
fore
> specify the computation of a value. =A0We are all certain of the type of
> that value (char) by we don't yet know which of the many chars is it.
>
Very convincing argument.  Excellent.

>
> By the way, I am happy just to agree to disagree about this.
>
I would be to, but perhaps that's not a requirement.  You have kindly
chipped away here a good bit.

>
> I'll
> continue to write C avoiding constructs like *(char *)0 and so will you!
>
Absolutely.  The only reason something like '*(void *)0;' might be
interesting to me if it did _not_ have undefined behaviour would be
for development of an implementation or for an easy "do-nothing"
preprocessor macro; but something more than just ';'.

On Jul 23, 8:17=A0pm, Seebs <usenet-nos...@seebs.net> wrote:

A thoroughly considered response.

It is clear that my discussion has agitated you.  I did not intend to
imply to any audience that you have been lying to me with your
responses.  To clarify, I do not believe you have lied to anyone in
your responses.  Your experience and the experience of other
responders is what I was hopeful for the benefit of with regards to
this subject matter.

I _sincerely_ apologize, Peter.  I will try to keep all of your
discussion's valuable points in mind as the subject matter becomes
clearer.  Please do not attribute ill intent where an explanation of
another sort will do.  I help people with computer-related subjects
all day, every day, for years.  Sometimes I want to ask, "How much are
they paying you to waste my time?!"  If that's how you feel, I don't
wish to aggravate that feeling.  I won't trouble you any more, with
good fortune.

Perhaps this could lighten the mood?  Agitating you with your
evaluation of my void expression '(void)*(char *)0;' was an unintended
side-effect.

On Jul 23, 8:34=A0pm, Keith Thompson <ks...@mib.org> wrote:
>
> (void)0 neither computes a value, nor designates an object or function,
> nor generates side effects, or any combination thereof.
>
Wait a minute, didn't post #56 have something about 'void's and
values?  Here '0' has type and value.  Casting to 'void' appears to
discard that value.  Does that mean that result of evaluating
'(void)0' has a type but no value?  Is that void expression a
legitimate expression statement?  Thanks, the Other Keith.

So is the result of:

*(void *)0

required to have a value or could it just as well be a void
expression, possibly used in an expression statement?  Is it somewhere
required that unary '*'' should have defined type and value in the
result but that casting to void may not?  "Cast operators" has
semantics that appear to define "converts the value of the expression
to the named type."  So '(void)58' yields UB, right?  Even before
considered as a void expression?

>
> This is yet another reason the standard's definition of "expression" is
> flawed. =A0The other is that some expressions, for example 42, contain no
> operators or operands.
>
Agreed.  And while we might know what to do and what not to do while
programming, development of an implementation might require a stricter
understanding.

>
> It's not *fatally* flawed; I don't think it's led anyone to an incorrect
> understanding of what "expression" means. =A0But a more accurate
> definition would refer to the syntax.
>
Agreed, with the exception of the question above.

On Jul 23, 8:17=A0pm, Keith Thompson <ks...@mib.org> wrote:
>
> And a value. =A0What is the value of the result? =A0Nothing in the standa=
rd
> defines what that value is, therefore the value is undefined.
>
This appears to be the critical piece.  A result shall have a defined
value and a defined type.  Anything less is undefined behaviour.  And
yet, a void expression describes a non-existent value for an
expression, albeit with a type of 'void'.  We can get one of these
from casting to 'void', right?  Even though a cast converts a value to
a named type?

>
> How could it be intentional? =A0If it's intentional, it doesn't make any
> sense.
>
> Once again, here's the passage in question, 6.5.3.2p4:
>
> =A0 =A0 The unary * operator denotes indirection. If the operand points
> =A0 =A0 to a function, the result is a function designator; if it points
> =A0 =A0 to an object, the result is an lvalue designating the object. If
> =A0 =A0 the operand has type =91=91pointer to type=92=92, the result has
> =A0 =A0 type =91=91type=92=92. If an invalid value has been assigned to
> =A0 =A0 the pointer, the behavior of the unary * operator is undefined.
>
> It is not possible to assign a value, invalid or otherwise, to "the
> pointer" unless "the pointer" is a pointer object. =A0The context does no=
t
> imply the existence of any pointer object to which the phrase "the
> pointer" could refer. =A0Even if the operand happens to be an lvalue,
> it is no longer an lvalue (and thus no longer designates an object)
> before the "*" operator is applied to it. =A06.3.2.1p2:
>
There is no constraint that the operand is a pointer object.  The
constraint is that the operand is a pointer.  We know from an earlier
reference of yours that the operand is a value.  Perhaps this "has
been assigned..." goes beyond "the operand" (it doesn't mention the
operand, unlike the other sentences), and means something more like
"if the value was that of a pointer object, and that object had been
assigned..."  It's just plain fishy, at the very least.

> ... ... ...
> The author implicitly assumed the existence of a pointer object that
> does not exist.
>
Could very well be.  Even seems to be a common interpretation amongst
discussants.

Shao Miller <sha0.miller@gmail.com> writes:

> On Jul 23, 7:25 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>>
>> No.  You are playing games with the language.  Two clauses of one
>> sentence (separated by ;) talk about the result.  A separate sentence
>> talks about the type.  These are not three cases but two attributes of
>> this form of expression.
>>
> I did not intend to play games with the language.  If that has been
> the case, then I sincerely apologize for doing so.  Any inability of
> my own to have implicitly understood this is nobody's challenge but
> mine.

OK, I accept that.  You said:

| The omission of when the pointer does not point to an object only
| impacts the definition of the result, _when_ that result is an
| _lvalue_.

To the extent I can give that any meaning at all, it is at odds with the
plain words of the paragraph that is causing you so much trouble.  This
made me suspect that you are looking for trouble -- deliberately trying
to misread the plain words to find a confusion.  I am happy to be wrong
about that.

To be clear, the omission (the failure to specify a result) impacts the
result when the operand is neither a function pointer nor an object
pointer.

<snip>
>  The simplest way for me to accept your claim would be to
> assert that "every expression must have a value."

But that would be wrong, e.g. (void)(1+2).

>  Since there is no
> definition of a value for this scenario, that would quite simply lead
> to an incompletely defined result, which I would be happy to call
> "undefined behaviour" regarding the evaluation of the expression, or
> even during execution.

OK, undefined behaviour it is, then.

>> C defines the type of many expression forms whether the result is
>> defined or not.
>>
> Here again, I was possibly missing the equivalence between "value" and
> "result."  Often interchangeable in everyday usage, I perhaps have
> incorrectly assumed that the referenced C draft might have very
> specific meanings for each and might distinguish them.  In the
> original post, we see a definition for "value" which could easily
> contribute to such a misunderstanding.

I think you've not taken Tim's excellent advice to heart.  If you treat
the standard as a set formal definitions with rigid consequences (like a
piece of mathematics) you will find that almost no programs have any
meaning.  0 is not an expression (it lacks operators); 42 has no value
(there is no object to have a value as per the definition) and so on.
You have to read it with slice of common sense.  The meaning of its
terms is partly to be gleaned from absorbing how they are used.  Look
at how "result" and "value" are used.  "Result" is not defined so you
have to guess.  What is "the result of an expression"?  Most people
conclude that it is some notion of a quantity with an associated type.

>> << and >> expressions have the type of the promoted
>> left operand.  In some cases the result (or behaviour) is undefined.
>> The fact that the type is known does not make all << and >> expressions
>> defined.
>>
> Your argument for tying both "type" and "value" together before
> yielding a defined result is a very good one.  By my previous
> suggestions, "The type of the result is
> that of the promoted left operand" for these two operators would again
> yield a result with a type, but possibly no defined value.  The text
> for these operators does seem to cover all possibilities however,
> signed, unsigned, UB, implementation-defined.

It does not matter.  If it only covered a few cases, those not
explicitly covered would be undefined.  Knowing the type would not make
the result any less defined.

>  The constraint for
> "integer type" helps.  You cannot have an integer type which is
> neither signed nor unsigned.

No, it does not help.  Knowing that -1 << 512 is of type int does not
make it any less undefined.

>  It would be nice if a constraint for the
> unary '*' operator were that the pointer must either point to an
> object or to a function.  Perhaps some kind reader could introduce
> such a constraint into a future standard.

Such a constraint is not possible.  Constraints must be diagnosed by the
implementation when the program is translated and the compiler can't
tell when the operand of * does not point to an object.  Is this OK or
not:

  int f(int *ip) { return *ip; }

?

>> What, in your opinion, is the result of the expression *(char *)0?  If
>> you can't find words from that standard to explain what the result is
>> (not just its type) then it is undefined by omission.
>>
> Here again I can only say "result with a type".  Accepting that
> evaluation of an expression shall yield a result with both type and
> value means that I would have to say that '*(char *)0' is an
> incompletely defined result, which I would happily call undefined
> behaviour.

We are agreed!

<snip>
> This is possible misunderstanding of mine has been detailed twice
> above.  You appear to suggest that the semantics must define both a
> value and a type to accomplish a defined result.  Anything less is
> undefined.

Yes, that is my view.  If a "defined result" could be just a type, why
does the standard not say more about what one can do with these results?
Is *(char *)0 << *(char *)0 just a pure int result?  An expression's
result is either defined or undefined -- just a type is not enough.

<snip>
>> The result of *p is the entire object.
>>
> This troubles me just a bit, due to section 6.5, point 2.  I would
> worry that in:
>
> *x = *x + 1;
>
> That we have "read" the "prior value" twice, inappropriately, for each
> evaluation of the unary '*' operator.  I have not fully explored this
> avenue of thought and do not intend it as an argument by any means.
> Please feel free to discard.

You can read the prior value as often as you like.  The limit is on
modifying the stored value more than once.  And whilst I agree that it's
not entirely clear what constitutes a "read" of the value, most people
would say that is requires an lvalue to value conversion to be a read.

<snip>
>>   *p; /* probably fetch nothing (volatile objects excepted) */
>>   s = *p; /* probably fetch it all -- at least we know where to put it */
>>   (*p).m; /* probably behaves like p->m (i.e. only m is fetched) */
>>
> Also agreed.  This makes me curious about something like:
>
> int main(void) {
>   static int foo = 15;
>   struct bar {
>     char c[(size_t)&foo];
>     int baz;
>   };
>   return (*(struct foo *)0).baz;
> }

That's a constraint violation.  If your compiler does not complain about
it get another one!  The array size must be an integer constant
expression.

> for the not-yet-accepted (disputed) interpretation that something like
> moving a Turing machine's head to position 0 but then moving it by the
> offset of 'baz' before reading or writing to a potential object might
> be a reasonable thing to do in C.  (The common response has been that
> it's UB to try this.)  Some implementations might allow for such
> behaviour, but that's obviously not evidence of any sort that it's not
> UB.

I don't follow this at all.  The example is undefined because of the
constraint violation -- it need not even generate any executable code.

> My sense after your post here is that it would be very easy to let go
> of any uncertainty regarding the un/defined behaviour of '*(char *)0'
> and friends if we easily accept that a result must have a defined
> value and a defined type.

Just do it.  Take the red pill.

-- 
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Shao Miller <sha0.miller@gmail.com> writes:
<snip>
>> int main(void) {
>>   static int foo = 15;
>>   struct bar {
>>     char c[(size_t)&foo];
>>     int baz;
>>   };
>>   return (*(struct foo *)0).baz;
>> }
>
> That's a constraint violation.  If your compiler does not complain about
> it get another one!  The array size must be an integer constant
> expression.

Actually it is not a constraint violation but it certainly violates a
"shall" about integer constant expressions (6.6 p6).  I am surprised
this is not a CV since I can't see any reason it can't be checked at
compile time, but it's not one.

<snip>
-- 
Ben.

On 23 Jul 2010 21:09:04 GMT, Seebs <usenet-nospam@seebs.net>
wrote:

>On 2010-07-23, Shao Miller <sha0.miller@gmail.com> wrote:
>> Thank you for your opinion.  I would have also appreciated some
>> reasoning, in order to help to convince myself of this.  The opinion
>> is appreciated regardless of the lack of reasoning.  Poll-wise,
>> dereferencing a null pointer is undefined behaviour during
>> evaluation.  Reason-wise, it's still incomplete, for me.
>
>I really don't think the problem is reasoning, because you've seen tons
>of that, and it's had no effect whatsoever.  I don't know what the issue
>is; this really is pretty straight forward.  '(char *) 0' is a pointer, and
>it does not point to a valid object, therefore, '*(char *) 0' is undefined
>behavior to evaluate.  In the abstract machine, expressions are evaluated,
>with a few specialized exceptions (such as sizeof).  So whether or not you
>cast it, or use the value, the expression *is* evaluated, and evaluating the
>expression produces undefined behavior.

You may have conceded his point by admitting to the specialized
exceptions.  Evaluating *(char *)0 is undefined; none-the-less it
has a defined type.  The statement

    sizeof(*(char *)0);

does not (or at least should not) invoke undefined behaviour
because the expression is not evaluated.

On Jul 23, 11:36=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> OK, I accept that. =A0You said:
>
> | The omission of when the pointer does not point to an object only
> | impacts the definition of the result, _when_ that result is an
> | _lvalue_.
>
> To the extent I can give that any meaning at all, it is at odds with the
> plain words of the paragraph that is causing you so much trouble. =A0This
> made me suspect that you are looking for trouble -- deliberately trying
> to misread the plain words to find a confusion. =A0I am happy to be wrong
> about that.
>
You _are_ wrong about "looking for trouble".  Please continue to be
happy. :)

>
> To be clear, the omission (the failure to specify a result) impacts the
> result when the operand is neither a function pointer nor an object
> pointer.
>
Ok.  But I'd rather that even this was clearer.
1. There is a sentence which specifies a value for the result.
2. There is a sentence which specifies a type for the result.
3. If the sentence regarding the value does not apply, the sentence
regarding the type is _insufficient_ to define a whole result.

>
> > =A0The simplest way for me to accept your claim would be to
> > assert that "every expression must have a value."
>
> But that would be wrong, e.g. (void)(1+2).
>
Ok.  But I'd rather that even this was clearer:
1. There is a sentence which specifies a value for the result.
2. There is a sentence which specifies a type for the result.
3. If the sentence regarding the value does not apply, the sentence
regarding the type is _sufficient_ to define a whole result.

>
> OK, undefined behaviour it is, then.
>
Agreed conditional upon acceptance of at least one of:
1. "...has been assigned..." really means something more like "is an
invalid value"

OR:

2. Casting to 'void' and application of the unary '*' operator are
treated differently.  Both may fail to define a value for the result
of an evaluation, but the cast is permitted as defined behaviour.

>
> I think you've not taken Tim's excellent advice to heart. =A0If you treat
> the standard as a set formal definitions with rigid consequences (like a
> piece of mathematics) you will find that almost no programs have any
> meaning. =A00 is not an expression (it lacks operators); 42 has no value
> (there is no object to have a value as per the definition) and so on.
Each of these points feels like a blow, including any failure on my
part to treat the referenced draft as anything more than a guide to be
supplemented by popular consensus.

>
> You have to read it with slice of common sense.
>
"Common sense" meaning "popular interpretation" to me.  Very well;
accepted.

>
>=A0The meaning of its
> terms is partly to be gleaned from absorbing how they are used. =A0Look
> at how "result" and "value" are used. =A0"Result" is not defined so you
> have to guess. =A0What is "the result of an expression"? =A0Most people
> conclude that it is some notion of a quantity with an associated type.
>
If writing a translator, I might have a 'struct result' with a pointer
to a type and a pointer to a value.  I might initialize these with
NULL each.  If an "operator" for a 'struct result' demanded one of
these properties but it was not defined, I might diagnose undefined
behaviour.  It simply seemed to me that there were circumstances in
which some code path for "evaluation" might not ever use one of the
properties, which would lead me to question the validity of diagnosing
as UB if one compares as NULL but there was no expectation for it to
be non-NULL...  Such as a void expression, which appears to be more
limited than I thought (casts to void and functions returning void,
for example).

>
> It does not matter. =A0If it only covered a few cases, those not
> explicitly covered would be undefined. =A0Knowing the type would not make
> the result any less defined.
>
Well...

>
> No, it does not help. =A0Knowing that -1 << 512 is of type int does not
> make it any less undefined.
>
> Such a constraint is not possible. =A0Constraints must be diagnosed by th=
e
> implementation when the program is translated and the compiler can't
> tell when the operand of * does not point to an object.
>
A constraint that: "except when the '*' operator is used as the
operand to the 'sizeof' operator, an expression evaluating to a null
pointer constant or to a null pointer constant cast to any pointer
type shall not be the operand," might do, mightn't it?

>
>=A0Is this OK or
> not:
>
> =A0 int f(int *ip) { return *ip; }
>
> ?
>
Yes.  The function call assigns the value of an argument to the 'ip'
parameter.  Passing in invalid value would result in UB.

>
> We are agreed!
>
> Yes, that is my view. =A0If a "defined result" could be just a type, why
> does the standard not say more about what one can do with these results?
> Is *(char *)0 << *(char *)0 just a pure int result? =A0An expression's
> result is either defined or undefined -- just a type is not enough.
>
Well actually, it does explain what you can do with the results.  I
had made earlier references to these.  "Cast operators"' first
constraint says "Unless...the operand shall have scalar type".  Its
first semantic point talks about "the value of the expression."
"Simple assignment" talks about "type" and "value" for the
"operands".  That explicitness (along with void expressions) was part
of why a result was not required to have both, against the consensus
here.  However it was the _consumers_ of the results that I was taking
to give meaning to constraint-valid and semantically valid
expressions.  The consensus appears to be that the results are defined
or not, regardless of the consumers or their properties, except for
'sizeof' (which nobody has disputed).

>
> You can read the prior value as often as you like. =A0The limit is on
> modifying the stored value more than once. =A0And whilst I agree that it'=
s
> not entirely clear what constitutes a "read" of the value, most people
> would say that is requires an lvalue to value conversion to be a read.
>
That saved me some investigation.  Very much appreciated.

>
> Just do it. =A0Take the red pill.
>
The tiny print of the brand name appears to read "DeFacto"; I think
that's an Italian company.

Thanks so much, Ben.  You've been a great help.

Given Seebs's plonk announcement, I consider it worthwhile to echo Shao 
Miller's apology here, in full. [Apart from my sig block, I have added 
no further content past this point. Hence the top-posting.]

Shao Miller wrote:
> On Jul 23, 8:17 pm, Seebs <usenet-nos...@seebs.net> wrote:
> 
> A thoroughly considered response.
> 
> It is clear that my discussion has agitated you.  I did not intend to
> imply to any audience that you have been lying to me with your
> responses.  To clarify, I do not believe you have lied to anyone in
> your responses.  Your experience and the experience of other
> responders is what I was hopeful for the benefit of with regards to
> this subject matter.
> 
> I _sincerely_ apologize, Peter.  I will try to keep all of your
> discussion's valuable points in mind as the subject matter becomes
> clearer.  Please do not attribute ill intent where an explanation of
> another sort will do.  I help people with computer-related subjects
> all day, every day, for years.  Sometimes I want to ask, "How much are
> they paying you to waste my time?!"  If that's how you feel, I don't
> wish to aggravate that feeling.  I won't trouble you any more, with
> good fortune.
> 
> Perhaps this could lighten the mood?  Agitating you with your
> evaluation of my void expression '(void)*(char *)0;' was an unintended
> side-effect.


-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

On 2010-07-24, Richard Harter <cri@tiac.net> wrote:
> You may have conceded his point by admitting to the specialized
> exceptions.  Evaluating *(char *)0 is undefined; none-the-less it
> has a defined type.  The statement

>     sizeof(*(char *)0);

> does not (or at least should not) invoke undefined behaviour
> because the expression is not evaluated.

Right.

But that's because sizeof() is magical in that it uses the type, not the
value.  The expressions under discussion *are* evaluated.  Basically,
sizeof()'s special language is the exception that proves the rule -- and
also explains why you might care about the type of an expression which
cannot be evaluated without producing undefined behavior.  It's perfectly
reasonable to use such an expression *as the operand of sizeof* -- because
that uses the type rather than the result.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On Jul 24, 12:27=A0am, c...@tiac.net (Richard Harter) wrote:
>
> You may have conceded his point by admitting to the specialized
> exceptions. =A0Evaluating *(char *)0 is undefined; none-the-less it
> has a defined type. =A0The statement
>
> =A0 =A0 sizeof(*(char *)0);
>
> does not (or at least should not) invoke undefined behaviour
> because the expression is not evaluated.
>
Thanks for suggesting that, Richard.  That seems reasonable.

It's really unfortunate that on-topic, civil discussion resulted in
upset, here.  Evidently the word "invented" can be perceived by some
folks as un-civil.  I wish that I'd known of that possibility before-
hand.  I honestly meant it in the context of definitions without
references, either made-up on-the-spot or not helping due to a lack of
citation.  Also, there should be the possibility of "mistakenly
interpreting" and "mistakenly remembering" versus "intentionally
misrepresenting."

Communications can be challenged when one doesn't understand another
person's frame of reference.  For Peter, he claims to have a wealth of
knowledge and experience.  For me to boldly state that parts of his
discussion were invented might have come as a most unexpected and most
unlikely circumstance.  I did not anticipate that possibility and now
suffer the loss of any future valuable discussion from him.

I try to interact much of the time through questions-only.  This often
works out extremely effectively.  In this discussion, I was a bit
desperate to understand the situation, especially after many
unsatisfactory (to me) responses, and must admit having neglected this
nice strategy, which has traditionally kept things civil, in my
experience.  This lesson will stick with me.

Now you are quite right by me Richard, when you suggest that if anyone
at all had ever managed to recognize that my frame of reference
included the point that a result need not have both value and type,
then a simple response of "Your result has a defined type but no
defined value.  Defined results must have both.  Here's the
reference..."  This might have shortened the path to a question:

Is the result of evaluating an expression with void type defined to
have all three of: 1. A result, 2. a type, 3. a value, given that all
constraints are met and the evaluation can be performed entirely
according to the semantics without invoking undefined behaviour?

Also, to be fair, there really was some ambiguity in the definitions
used by the discussants, due to ambiguity in the referenced draft.  At
some point along I had assumed that there might be an oversight found
in some implementations and peoples' interpretations.  Instead, I
discovered that these things, in fact, define the reality for C.  The
draft standard is perhaps a possible _target_ for conformance, but
perhaps not the best definition to discuss in regards to adherence,
without some guess-work or asking around.

Having said that, it only confused me further when kind responders
both suggested that the draft is clear/obvious/unambiguous and that is
isn't.  It really would have been better (for my benefit, anyway) to
agree on one or the other as soon as possible.  Perhaps this feedback
will benefit future discussion, with good fortune.

Well I might as well document this bit of trivia, since there've been
a couple of other bits of trivia mentioned.

01. void foo(void) {
02.   return;
03. }
04.
05. int main(void) {
06.   int i = 13;
07.   void *v = &i;
08.   (void)13;
09.   foo();
10.   *v;
11.   return 0;
12. }

Does evaluation of the cast operator on line 08 yield a defined result
with a defined type and a defined value?

Does evaluation of the function call operator on line 09 yield a
defined result with a defined type and a defined value?

Do all defined results require a defined type and a defined value?

Does the evaluation of the indirection operator on line 10 yield a
defined result with a defined type?

Only posted as a trivial reference.  Feel free to respond or ignore,
at your capable discretion. :)

Shao Miller wrote:

<snip>

> It's really unfortunate that on-topic, civil discussion resulted in
> upset, here.  Evidently the word "invented" can be perceived by some
> folks as un-civil.  I wish that I'd known of that possibility before-
> hand.  I honestly meant it in the context of definitions without
> references, either made-up on-the-spot or not helping due to a lack of
> citation.  Also, there should be the possibility of "mistakenly
> interpreting" and "mistakenly remembering" versus "intentionally
> misrepresenting."
> 
> Communications can be challenged when one doesn't understand another
> person's frame of reference.  For Peter, he claims to have a wealth of
> knowledge and experience.

The word "claim" is rather loaded. Peter /does/ have a wealth of 
knowledge and experience. That doesn't mean he is necessarily right, but 
it does mean that the probability of his being right is significantly 
high. When I find myself disagreeing with Peter, it always gives me 
pause for thought.

<snip>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

Shao Miller wrote:
> Well I might as well document this bit of trivia, since there've been
> a couple of other bits of trivia mentioned.
> 
> 01. void foo(void) {
> 02.   return;
> 03. }
> 04.
> 05. int main(void) {
> 06.   int i = 13;
> 07.   void *v = &i;
> 08.   (void)13;
> 09.   foo();
> 10.   *v;
> 11.   return 0;
> 12. }
> 
> Does evaluation of the cast operator on line 08 yield a defined result
> with a defined type and a defined value?

No. Operators yield values, but they are not themselves evaluated. 
Therefore, there is no "evaluation of the cast operator".

> 
> Does evaluation of the function call operator on line 09 yield a
> defined result with a defined type and a defined value?

No, for the same reason.

> 
> Do all defined results require a defined type and a defined value?

What do you mean by "result" in this context? Is a successful write to 
stdout a "result"? Some would say yes.

> 
> Does the evaluation of the indirection operator on line 10 yield a
> defined result with a defined type?

No - see above.

<snip>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

Shao Miller wrote:

> 08.   (void)13;

> Does evaluation of the cast operator on line 08 yield a defined result
> with a defined type and a defined value?

The standard only mentions values for expressions of object type.

The expression in the expression statement 
on line 08 is of type void.

The value of such an expression 
is described by the standard as being "nonexistent".

N869
       6.3.2.2  void
       [#1] The  (nonexistent)  value  of  a  void  expression  (an
       expression that has type void) shall not be used in any way,
       and implicit or explicit conversions (except to void)  shall
       not  be  applied to such an expression.


-- 
pete

Shao Miller <sha0.miller@gmail.com> writes:

> On Jul 23, 1:30 pm, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>>
>> I don't.  The wording could be better, but there is no
>> doubt about the meaning.
>>
> After your fine reference to the text below, I'd have to agree.
>
>>
>> The Standard is written in
>> formal English but it is not a math textbook, and it's
>> at best a waste of time to read it like one.
>>
> I am not aware of anyone who's reading it like a math textbook and I'd
> have to agree.  It could be worth-while reading its fine detail and
> discussing and resolving perceived ambiguities, for the case where one
> might be interested in developing a translator for C.
>
>>
>> If you want to get technical,
>>
> Indeed I did.
>
>>
>> it can NEVER be the case
>> that the operand of an indirection operator has been
>> assigned.  In the expression '*p', where p has been
>> declared to be of some pointer type, the operand 'p'
>> has already been converted to a value by virtue of
>> 6.3.2.1p2.  There is no difference between '*p' and
>> '*(char*)0' in this regard -- both operate on values,
>> not objects.  So it's completely nonsensical to try to
>> understand "has been assigned" as applying to one class
>> of operand expression but not another.  They are all
>> just values.
> This is to me an extremely valuable reference to the text of
> 'n1256.pdf'.  I agree that with this reference in mind, it's
> nonsensical to treat "If an invalid value has been assigned to the
> pointer" as being intended to mean anything other than "If the operand
> has an invalid value"...  If only the text said "operand."  It
> doesn't.  It says "pointer."
>
> Is there any doubt that the operand has a value?  We can assign '(char
> *)0' or even '(void *)0' to an object.  I don't think there's any
> doubt that the operand has a value.
>
> This could potentially be a cause for confusion, since sentences 2 and
> 3 explicitly use "operand" and "points to" and "has type".  The next
> sentence could very well mean, "if the value of the operand _is_ an
> invalid value..." (Emphasis mine.)  It could also mean, "if the value
> of the operand was an invalid value assigned to the operand..."
>
> Do you understand why I am asking about all of this?  In the execution
> environment if we attempt to access an object at an invalid location,
> it should be undisputed as undefined behaviour.  But expression
> evaluation != execution.  Evaluation of a constant scalar expression
> such as '(char *)0' need not be "executed" at all.  That is to say,
> the text defines an attempted object access to an invalid location as
> undefined behaviour.  It could even be trapped by the best
> implementation.  But evaluation of an expression which is an
> application of the unary '*' operator does noes necessitate an object
> access to any location.  If it did, the text should include something
> like:
>
> "The result of evaluation of the unary '*' operator shall be the value
> of an object pointed to by the operand, if the operand point to an
> object."
>
> But that might not be the case.  Consider these:
>
> (*p).f();
> (*q)->x = 10;
> *r = 11;
> (*s)();
>
> For 'p', 'q' and 'r', if they point to an object, the result is an
> lvalue.  It's not a "value".  There's no need to "fetch" the "value"
> during the indirection at all, is there?  Thus we only get undefined
> behaviour if they _don't_ point to an object, which is a determination
> that might only be possible during execution.
>
> For 's', the indirection is intended to result in a function
> designator.  Not an lvalue.  Not a "value".
>
> It is clear that many people have tied evaluation of the unary '*'
> operator to "yielding an object, pointed-to by the operand" in their
> thinking.  But this is not the case.
>
> Also consider a Turing machine implementation with a tape and a head.
> In the 'q' example above, if 'q' were assigned the value '(struct foo
> *)0', the head might move to position zero, where "read" and "write"
> are invalid.  No read nor write is attempted.  Then the head moves by
> the offset of the 'x' member.  At last, we attempt a write when we
> assign, assuming that reads and writes are valid at that position.
> Why should there be undefined behaviour by moving the head to position
> 0 any more so than to any other location which is invalid for objects
> or for which the validity is not guaranteed?
>
> Does anyone understand why "has been assigned" could be important?
>
> char *p;
> *p = 'Y';
>
> If the Turing machine's head attempts to move to the location as per
> 'p', that location might not be a valid location for the head to move
> to.  Undefined behaviour.  But how can you have _an_expression_ with a
> _constant_scalar_value_ at _translation_time_ (let alone during
> execution) possibly represent an invalid location for the head to move
> to?

Your thinking seems very confused.  I suggest you stop
thinking about execution on real machines or Turing
machines, and focus on reading the Standard to understand
what it says about semantics on the abstract machine.  The
questions you've asked can be answered by reading the
Standard carefully, not just isolated sections but all of
sections 1-6, and considering what it's trying to say about
semantics on the abstract machine, which is the only one
that really counts.  I'm not inclined to spend any more
effort responding to someone who seems to want other people
to do the work for something that he appears to be capable
of doing himself, if only he would put in more effort on
that and less on raising captious objections.

Shao Miller <sha0.miller@gmail.com> writes:

> On Jul 23, 11:36 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
<snip>
>> To be clear, the omission (the failure to specify a result) impacts the
>> result when the operand is neither a function pointer nor an object
>> pointer.
>>
> Ok.  But I'd rather that even this was clearer.
> 1. There is a sentence which specifies a value for the result.

Check. 6.5.3.2 p4 "If the operand points to a function, the result is a
function designator; if it points to an object, the result is an lvalue
designating the object."

> 2. There is a sentence which specifies a type for the result.

Check (well there are two, in fact).  6.5.3.2 p2 "The operand of the
unary * operator shall have pointer type."  And 6.5.3.2 p4 "If the
operand has type 'pointer to type', the result has type 'type'."

> 3. If the sentence regarding the value does not apply, the sentence
> regarding the type is _insufficient_ to define a whole result.

Check. 4 p2 "Undefined behavior is otherwise indicated in this
International Standard by the words 'undefined behavior' or by the
omission of any explicit definition of behavior."

Underlying the specific issue you have is a problem that the standard
has never quite managed to resolve.  There are three attributes that
matter about an expression and/or its "result":  (a) the quantity (which
character, which integer, etc.), (b) the type, and (c) whether it is an
lvalue (there is a detail about whether its is also a modifiable lvalue
but lets simplify for the moment).

(b) and (c) can be determined from the syntactic form of the expression
along with some type analysis whereas (a) is a dynamic property of the
expression at run time.  To use "result" for all of these clouds this
distinction and has led you to think that a "result" can be defined when
only the type is known.

I'd prefer the wording to be done like this:

   Form:        *E
   Constraints: The operand, E, must have type 'pointer to T'.
   Type:        An expression of the form *E has type T and is an
                lvalue if T is an object type.
   Result:      If the result of evaluating E is a pointer to a function,
                the result is a function designator denoting the pointed
                to function.  If E the result of evaluating E is a
                pointer to an object, the result denotes that object.

It would then be clear that the type is not really "part of the result"
but a property of the expression form -- something essentially static
and not associated with the evaluation.  I'm not suggesting it -- the
work would be monstrous and there would be endless details to get right
(variably modified array types spring to mind) but this highlights what
the current wording is dealing with.

Of course, the way it is done now is much more intuitive.  For most
expressions, it suggest that the result is a quantity tagged with a type
and lvalue-ness.  But this does not work for sizeof, for example.  It
does not (usually) evaluate it's result so the dynamic view of a
type-tagged result has no meaning.  People know that the type can be
determined without evaluation so they apply common sense to understand
the sizeof operator.  It's a shame that the wording is not perfect, but
it is not nearly as confusing as you seem to think.

<snip another discussion about void expressions.  I don't want to get
into that here>

>> OK, undefined behaviour it is, then.
>>
> Agreed conditional upon acceptance of at least one of:
> 1. "...has been assigned..." really means something more like "is an
> invalid value"

That is what most people take it to mean.  Why?  Because making special
provision for when a pointer is an object that has been assigned to
makes no sense when taken literally.  Given:

  const int *ip = 0;

*ip would not be covered but it would be after:

  int *ip;
  ip = 0;

Both would remain undefined by omission, so what value would the literal
interpretation serve?

> OR:
>
> 2. Casting to 'void' and application of the unary '*' operator are
> treated differently.  Both may fail to define a value for the result
> of an evaluation, but the cast is permitted as defined behaviour.

I don't see how this makes any difference but it does not matter because
I'm choosing (1) not (2)!

>> I think you've not taken Tim's excellent advice to heart.  If you treat
>> the standard as a set formal definitions with rigid consequences (like a
>> piece of mathematics) you will find that almost no programs have any
>> meaning.  0 is not an expression (it lacks operators); 42 has no value
>> (there is no object to have a value as per the definition) and so on.
> Each of these points feels like a blow, including any failure on my
> part to treat the referenced draft as anything more than a guide to be
> supplemented by popular consensus.

Hmmm.  Now I doubt your sincerity again.  Read what you wrote.  You are
suggesting that I (and indirectly Tim) want you to treat the largely
unpaid work of dozens of experts over more than two decades as no more
than a guide to the language.

Further more, neither of us is suggesting that "popular consensus" is
the main tool to be used when there is ambiguity.  That would be absurd.
Do you see how that comes over?

>> You have to read it with slice of common sense.
>>
> "Common sense" meaning "popular interpretation" to me.  Very well;
> accepted.

I think you need to refine your understanding of the term "common
sense".

>> The meaning of its
>> terms is partly to be gleaned from absorbing how they are used.  Look
>> at how "result" and "value" are used.  "Result" is not defined so you
>> have to guess.  What is "the result of an expression"?  Most people
>> conclude that it is some notion of a quantity with an associated type.
>>
> If writing a translator, I might have a 'struct result' with a pointer
> to a type and a pointer to a value.  I might initialize these with
> NULL each.  If an "operator" for a 'struct result' demanded one of
> these properties but it was not defined, I might diagnose undefined
> behaviour.

That's hard to get right though it can be done.  You need to make sure
that sizeof (1/0) works properly and that you distinguish between
"plain" values and lvalues.  Your eval function needs flags to say what
sort of "evaluation" to do.  In the example, 1/0 needs to be "evaluated"
for its type alone.  I put evaluation in quotes because it is not C's
notion of evaluate but one that comes from the interpreter you are
writing.

>  It simply seemed to me that there were circumstances in
> which some code path for "evaluation" might not ever use one of the
> properties, which would lead me to question the validity of diagnosing
> as UB if one compares as NULL but there was no expectation for it to
> be non-NULL...  Such as a void expression, which appears to be more
> limited than I thought (casts to void and functions returning void,
> for example).

I don't follow all of this.  Yes, there are cases where one would not
ever use one of the properties such as in sizeof (1/0), but in
(void)(1/0) you need to evaluate 1/0 for its value property so that you
can throw it away.

<snip>

|  It would be nice if a constraint for the
| unary '*' operator were that the pointer must either point to an
| object or to a function.  Perhaps some kind reader could introduce
| such a constraint into a future standard.

>> Such a constraint is not possible.  Constraints must be diagnosed by the
>> implementation when the program is translated and the compiler can't
>> tell when the operand of * does not point to an object.
>>
> A constraint that: "except when the '*' operator is used as the
> operand to the 'sizeof' operator, an expression evaluating to a null
> pointer constant or to a null pointer constant cast to any pointer
> type shall not be the operand," might do, mightn't it?

Either this can't be a constraint (because you mean to include something
that can't be tested at compile time) or you have now changed the
suggestion to catch only a few cases.  It all depends on what you mean
by "evaluating to a null pointer constant or to a null pointer constant
cast to any pointer type".

>> Is this OK or
>> not:
>>
>>   int f(int *ip) { return *ip; }
>>
>> ?
>>
> Yes.  The function call assigns the value of an argument to the 'ip'
> parameter.  Passing in invalid value would result in UB.

You proposed a constraint (which I have put back since you cut it)
"were that the pointer must either point to an object or to a
function".  My example (yes, we both agree it is UB) shows that you
can't tell *at compile time* if the constraint you originally proposed
is or is not violated.

>> We are agreed!
>>
>> Yes, that is my view.  If a "defined result" could be just a type, why
>> does the standard not say more about what one can do with these results?
>> Is *(char *)0 << *(char *)0 just a pure int result?  An expression's
>> result is either defined or undefined -- just a type is not enough.
>>
> Well actually, it does explain what you can do with the results.  I
> had made earlier references to these.  "Cast operators"' first
> constraint says "Unless...the operand shall have scalar type".  Its
> first semantic point talks about "the value of the expression."
> "Simple assignment" talks about "type" and "value" for the
> "operands".  That explicitness (along with void expressions) was part
> of why a result was not required to have both, against the consensus
> here.

There is no mention of your suggested type-only results.  They would be
a major part of the language.  How do they work?  What can we do with
them?

>  However it was the _consumers_ of the results that I was taking
> to give meaning to constraint-valid and semantically valid
> expressions.  The consensus appears to be that the results are defined
> or not, regardless of the consumers or their properties, except for
> 'sizeof' (which nobody has disputed).

If it is a consensus, it is born out of the wording.  An evaluation of
*E is defined when E points to an object or a function.  (char *)0 does
neither.  To allow the fact the expression form has a type to mean that
it also as some sort of valueless, type-only result is to invent a whole
new language.

<snip>
-- 
Ben.

Shao Miller <sha0.miller@gmail.com> writes:

> Well I might as well document this bit of trivia, since there've been
> a couple of other bits of trivia mentioned.
>
> 01. void foo(void) {
> 02.   return;
> 03. }
> 04.
> 05. int main(void) {
> 06.   int i = 13;
> 07.   void *v = &i;
> 08.   (void)13;
> 09.   foo();
> 10.   *v;
> 11.   return 0;
> 12. }
>
> Does evaluation of the cast operator on line 08 yield a defined result
> with a defined type and a defined value?
>
> Does evaluation of the function call operator on line 09 yield a
> defined result with a defined type and a defined value?
>
> Do all defined results require a defined type and a defined value?
>
> Does the evaluation of the indirection operator on line 10 yield a
> defined result with a defined type?
>
> Only posted as a trivial reference.  Feel free to respond or ignore,
> at your capable discretion. :)

Let me propose something else.  Post an example where you think that
some significant part of the meaning of the program depends on the
answers to your questions.  I.e. find an example that matters.  This
will interest people.

Everyone here (I am guessing) has their favourite examples of where the
literal wording in the standard falls short of giving an answer to some
question or other but most people want to write effective well-defined C
programs and they somehow manage to that despite these details.

-- 
Ben.

On Jul 24, 6:42=A0am, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> The word "claim" is rather loaded. Peter /does/ have a wealth of
> knowledge and experience. That doesn't mean he is necessarily right, but
> it does mean that the probability of his being right is significantly
> high. When I find myself disagreeing with Peter, it always gives me
> pause for thought.
>
Is it possible that "claims" could be injected with additional meaning
by the reader but not by the writer?  If I don't fully know the whole
picture regarding everyone's status, can I reasonably say "has"
instead of "claims to have"?  In other words, I am a newcomer, here.
I don't know any of you.  It might be beneficial to my understanding
of C to get to know some of you. :)  But can I possibly know before-
hand what magic words will set people off, such as "invent" and
"claims"?

Is it reasonable for me to simply take note of these words and avoid
them in the future?  Can I do so without feedback like yours,
Richard?  My answer would be "no."  And so I thank you.

And also you have provided some evidence for the claim; this is
recorded.  Would you have offered that evidence without my use of
"claims"?  Does that last question suggest that I used "claims"
intentionally towards that end?  I didn't.  It was meant as a simple
statement of fact.

"Claims" will be dropped from my vocabulary here now, surely.  Do you
happen to know of a nice list of words to avoid, like these ones?
That would be great. :)

On Jul 24, 6:44=A0am, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> No. Operators yield values, but they are not themselves evaluated.
> Therefore, there is no "evaluation of the cast operator".
>
> No, for the same reason.
>
> What do you mean by "result" in this context? Is a successful write to
> stdout a "result"? Some would say yes.
>
Previous discussion led me to believe that there was a common
understanding of the term "result".  If that's so, that common
understanding is what I intended to ask about, here.

>
> No - see above.
>
By your correction above, it would appear that these questions are
broken.  I shall attempt to ask different ones, instead.  Thank you!

01. void foo(void) {
02.   return;
03. }
04.
05. int main(void) {
06.   int i =3D 13;
07.   void *v =3D &i;
08.   (void)13;
09.   foo();
10.   *v;
11.   return 0;
12. }

When line 08 is evaluated by a conforming implementation, is the
behaviour well-defined to produce a result for the expression
'(void)13'?  Does that definition define both a type for the result as
well as a value for the result?

When line 09 is evaluated by a conforming implementation, is the
behaviour well-defined to produce a result for the expression
'foo()'?  Does that definition define both a type for the result as
well as a value for the result?

Using a conforming implementation, is the evaluation of every
expression within a strictly conforming program well-defined to
produce a result?  In this same circumstance, is that result well-
defined to possess both a type as well as a value?

When line 10 is evaluated by a conforming implementation, is the
behaviour well-defined to produce a result for the expression '*v'?
Does that definition define a type for the result?

On Jul 24, 7:59=A0am, pete <pfil...@mindspring.com> wrote:
>
> The standard only mentions values for expressions of object type.
>
> The expression in the expression statement
> on line 08 is of type void.
>
Agreed.  How can a conforming implementation make that very
determination?

>
> The value of such an expression
> is described by the standard as being "nonexistent".
>
> N869
> =A0 =A0 =A0 =A06.3.2.2 =A0void
> =A0 =A0 =A0 =A0[#1] The =A0(nonexistent) =A0value =A0of =A0a =A0void =A0e=
xpression =A0(an
> =A0 =A0 =A0 =A0expression that has type void) shall not be used in any wa=
y,
> =A0 =A0 =A0 =A0and implicit or explicit conversions (except to void) =A0s=
hall
> =A0 =A0 =A0 =A0not =A0be =A0applied to such an expression.
>
Thanks, pete!

On Jul 24, 10:45=A0am, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>
> Your thinking seems very confused. =A0I suggest you stop
> thinking about execution on real machines or Turing
> machines,
Turing machines were only mentioned as a possible explanation for why
the author of the "has been assigned..." piece of semantic for unary
'*' might have intentionally meant the text to be taken literally.

>
> and focus on reading the Standard to understand
> what it says about semantics on the abstract machine. =A0The
> questions you've asked can be answered by reading the
> Standard carefully, not just isolated sections but all of
> sections 1-6, and considering what it's trying to say about
> semantics on the abstract machine, which is the only one
> that really counts.
>
Have you taken my Turing machine example to mean that I am worried
about anything but the abstract machine?

>
>=A0I'm not inclined to spend any more
> effort responding to someone who seems to want other people
> to do the work for something that he appears to be capable
> of doing himself, if only he would put in more effort on
> that and less on raising captious objections.
>
If one perceives a gross ambiguity in the draft of a standard for C,
what is the best course of action to gain clarity on it after
exhausting the material in that draft?  Do the references cited
through the original post and thereafter by its author suggest that
the draft material was read throughly?  How many references by other
posters appear in the original poster's initial handful of posts?  How
many do not?  How many times should a person read something before
asking for others to help by sharing their interpretations and their
reasoning for those interpretations?

I can appreciate that you have made your judgment about me here and I
thank you for what you did contribute, Tim.

On 2010-07-24, Richard Heathfield <rjh@see.sig.invalid> wrote:
> The word "claim" is rather loaded. Peter /does/ have a wealth of 
> knowledge and experience. That doesn't mean he is necessarily right, but 
> it does mean that the probability of his being right is significantly 
> high. When I find myself disagreeing with Peter, it always gives me 
> pause for thought.

Which, given who's saying it, I find quite flattering.

I guess that word, again, strengthens my point:  If those remarks really
aren't intended as offensive (and "claim" has the same sorts of connotations
of dishonesty that "invented" does), then that implies a level of familiarity
with English inconsistent with arguing with more fluent speakers when they
tell you that a given text is clear in its meaning.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On Jul 24, 11:09=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> Check. 6.5.3.2 p4 "If the operand points to a function, the result is a
> function designator; if it points to an object, the result is an lvalue
> designating the object."
>
Thank you.  It does appear that this point defines a value for the
result under certain circumstances.

>
> > 2. There is a sentence which specifies a type for the result.
>
> Check (well there are two, in fact). =A06.5.3.2 p2 "The operand of the
> unary * operator shall have pointer type." =A0And 6.5.3.2 p4 "If the
> operand has type 'pointer to type', the result has type 'type'."
>
Agreed.

> > 3. If the sentence regarding the value does not apply, the sentence
> > regarding the type is _insufficient_ to define a whole result.
>
> Check. 4 p2 "Undefined behavior is otherwise indicated in this
> International Standard by the words 'undefined behavior' or by the
> omission of any explicit definition of behavior."
>
Agreed, and originally intended as the meaning.

>
> Underlying the specific issue you have is a problem that the standard
> has never quite managed to resolve. =A0There are three attributes that
> matter about an expression and/or its "result"...
> ... ... ...
> I'd prefer the wording to be done like this:
>
> =A0 =A0Form: =A0 =A0 =A0 =A0*E
> =A0 =A0Constraints: The operand, E, must have type 'pointer to T'.
> =A0 =A0Type: =A0 =A0 =A0 =A0An expression of the form *E has type T and i=
s an
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 lvalue if T is an object type.
> =A0 =A0Result: =A0 =A0 =A0If the result of evaluating E is a pointer to a=
 function,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the result is a function designator denot=
ing the pointed
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to function. =A0If E the result of evalua=
ting E is a
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pointer to an object, the result denotes =
that object.
>
> It would then be clear that the type is not really "part of the result"
> but a property of the expression form -- something essentially static
> and not associated with the evaluation...
> ... ... ...
Agreed.  Could your suggestion be met with criticisms for your simple
preference?  Would it be enjoyable if anyone suggested that your
opinion on perceived ambiguity for readers of this material is not
worth offering?  I thank you for it.

>
> Of course, the way it is done now is much more intuitive...
> ... ... ...
>=A0It's a shame that the wording is not perfect, but
> it is not nearly as confusing as you seem to think.
>
What is it exactly that causes you to believe that I find the wording
confusing?

>
> <snip another discussion about void expressions. =A0I don't want to get
> into that here>
>
That's unfortunate for me, but I accept it.

>
> That is what most people take it to mean. =A0Why? =A0Because making speci=
al
> provision for when a pointer is an object that has been assigned to
> makes no sense when taken literally. =A0Given:
>
> =A0 const int *ip =3D 0;
>
I see the truth of it.  This initialization specifies the value
initially stored in the object but there is no assignment expression.
If we take the text to mean "...assigned to the pointer by an
assignment expression...", then "the pointer" could not have been
assigned-to.

>
> *ip would not be covered but it would be after:
>
> =A0 int *ip;
> =A0 ip =3D 0;
>
> Both would remain undefined by omission, so what value would the literal
> interpretation serve?
>
I don't follow you here.  You said '*ip' "would be" covered "after"
and then said both would remain undefined by omission.

>
> > 2. Casting to 'void' and application of the unary '*' operator are
> > treated differently. =A0Both may fail to define a value for the result
> > of an evaluation, but the cast is permitted as defined behaviour.
>
> I don't see how this makes any difference but it does not matter because
> I'm choosing (1) not (2)!
>
I will choose (1) as well, as that's the overwhelming consensus, even
though I perceive the possibility of a different intention by the
author.  I won't bore anyone by repeating it.  Consider me convinced.

>
> Hmmm. =A0Now I doubt your sincerity again. =A0Read what you wrote. =A0You=
 are
> suggesting that I (and indirectly Tim) want you to treat the largely
> unpaid work of dozens of experts over more than two decades as no more
> than a guide to the language.
>
Please excuse me.  Have I said suggested incorrectly?  Have I
suggested that this "unpaid work of dozens of experts over more than
two decades" is not a valuable resource?  If so, what would cause you
to suggest that have implied/meant/stated that?  I believe this
resource to be _the_ most valuable resource for C.  Is it a guide?  In
what way(s) is it more than guide?  Is it a math textbook?  I would
answer that with "no."

>
> Further more, neither of us is suggesting that "popular consensus" is
> the main tool to be used when there is ambiguity. =A0That would be absurd=
..
>
> Do you see how that comes over?
>
Then I have misinterpreted and apologize.  What should be the main
tool in case of ambiguity?

>
> I think you need to refine your understanding of the term "common
> sense".
>
An accepted possibility.  So do you suggest that common sense and
perusal of the draft/standard is all that is required to develop a
conforming implementation?  If so, do you see how that might come over
to someone?  Would you be willing to help to refine an interpretation
of the term "common sense"?
>
> That's hard to get right though it can be done. =A0You need to make sure
> that sizeof (1/0) works properly and that you distinguish between
> "plain" values and lvalues. =A0Your eval function needs flags to say what
> sort of "evaluation" to do. =A0In the example, 1/0 needs to be "evaluated=
"
> for its type alone. =A0I put evaluation in quotes because it is not C's
> notion of evaluate but one that comes from the interpreter you are
> writing.
>
Good tips. :)

>
> I don't follow all of this. =A0Yes, there are cases where one would not
> ever use one of the properties such as in sizeof (1/0), but in
> (void)(1/0) you need to evaluate 1/0 for its value property so that you
> can throw it away.
>
You have explained that you are not interested in discussing 'void' at
this time.  I accept this and won't trouble you, here.

>
> Either this can't be a constraint (because you mean to include something
> that can't be tested at compile time) or you have now changed the
> suggestion to catch only a few cases. =A0It all depends on what you mean
> by "evaluating to a null pointer constant or to a null pointer constant
> cast to any pointer type".
>
Can an expression at translation-time evaluate to a null pointer
constant?  Can an expression at run-time evaluate to a null pointer
constant?  6.3.2.3 p3 includes detail concerning an "integer constant
expression".  Could the value of an object be an integer constant
expression?  If everyone knows or at least is adamant that "you can't
dereference a null pointer," could this constraint hurt the standard
for C?  Could it help to prevent questions like mine from accumulating
more responses than a single response with a citation?

>
> You proposed a constraint (which I have put back since you cut it)
> "were that the pointer must either point to an object or to a
> function". =A0My example (yes, we both agree it is UB) shows that you
> can't tell *at compile time* if the constraint you originally proposed
> is or is not violated.
>
Agreed.  I have abandoned that constraint in favour of the "null
pointer constant" constraint mentioned.

>
> There is no mention of your suggested type-only results. =A0They would be
> a major part of the language. =A0How do they work? =A0What can we do with
> them?
>
Could a void expression be considered a type-only result?  6.3.2.2 p1
describes an expression with no value (an empty set) and type 'void'.
Did we agree that such an expression is evaluated?  They way I
perceive them to work is: If an expression's type is defined to have a
type "T" and a value is not defined for evaluation, and that type "T"
is 'void', the expression is a void expression.  Is this a reasonable
perspective?  Sorry that we wound up with 'void', here.  I apologize
but wished to answer your questions.

>
> If it is a consensus, it is born out of the wording....
>
Agreed.

Thanks, Ben!

On Jul 24, 11:51=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> Let me propose something else. =A0Post an example where you think that
> some significant part of the meaning of the program depends on the
> answers to your questions. =A0I.e. find an example that matters. =A0This
> will interest people.
>
Are you suggesting that the above example doesn't matter?

>
> Everyone here (I am guessing) has their favourite examples of where the
> literal wording in the standard falls short of giving an answer to some
> question or other but most people want to write effective well-defined C
> programs and they somehow manage to that despite these details.
>
One such well-defined program might even be itself a C
implementation.  It would be good to do it right by everyone here.

On Jul 24, 3:29=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> Which, given who's saying it, I find quite flattering.
>
> I guess that word, again, strengthens my point: =A0If those remarks reall=
y
> aren't intended as offensive (and "claim" has the same sorts of connotati=
ons
> of dishonesty that "invented" does), then that implies a level of familia=
rity
> with English inconsistent with arguing with more fluent speakers when the=
y
> tell you that a given text is clear in its meaning.
>
There's no pleasing all of the people, all of the time.  If someone is
misinterpreting my words to carry connotations that weren't intended,
I can only try to address such in the future based on feedback, but
it's really _their_ constraint on interpretation.  If someone chooses
to interpret negative connotations, I don't know exactly where that
comes from.  Perhaps it is congruent with the same perspective that
makes it all right to presume homogeneity amongst English speakers'
use of English in discussion of a subject matter.

There is nothing non-objective about using "claims," but it'll be
dropped nonetheless in the future.

Please have tolerance for other people and they way they might write,
even if you've previously been worn down by abusers.  If Bayes tells
you an abuser is likely at hand, by all means, fine.  That's entirely
reasonable.

Shao Miller <sha0.miller@gmail.com> writes:
> On Jul 24, 7:59 am, pete <pfil...@mindspring.com> wrote:
>> The standard only mentions values for expressions of object type.
>>
>> The expression in the expression statement
>> on line 08 is of type void.
>>
> Agreed.  How can a conforming implementation make that very
> determination?

I don't understand the question.  The expression statement in question
was
    (void)13;
Determining the type of (void)13 is just one of the thousands
of things an implementation is required to do.


-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

Shao Miller wrote:
> On Jul 24, 6:42 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>> The word "claim" is rather loaded. Peter /does/ have a wealth of
>> knowledge and experience. That doesn't mean he is necessarily right, but
>> it does mean that the probability of his being right is significantly
>> high. When I find myself disagreeing with Peter, it always gives me
>> pause for thought.
>>
> Is it possible that "claims" could be injected with additional meaning
> by the reader but not by the writer?

Yes, of course, and there's nothing the writer can do about that. That's 
why we have to be careful how we write, if we do not wish to be 
misunderstood. (That applies to everyone, in all contexts, not just in 
comp.lang.c, and it applies as much to me as it does to you or to anyone 
else.)


> If I don't fully know the whole
> picture regarding everyone's status, can I reasonably say "has"
> instead of "claims to have"?

Status is as status does. People acquire "status" (if that's the right 
word) in comp.lang.c by posting good, sound advice, by entering civilly 
into technical discussions and demonstrating their knowledge of C in 
those discussions. (That doesn't mean they are always right, of course. 
But the way in which a person "loses" a discussion can tell you much 
about them, good or bad.) And, in general, those who are best at C tend 
to be those who aren't actually all that interested in status. What 
they're interested in is C. But there are times when a poster's personal 
experience is highly relevant. For example, Peter Seebach ("Seebs") was 
for some years an active member of the ISO committee responsible for 
updating the C language specification. (So was Larry Jones. He will no 
doubt correct me if I am wrong, but I *think* he's still on the 
committee.) Such people are not guaranteed to be right by any means, but 
proving them wrong requires care and skill!

You get to know, after a while, who tends to be right more often than 
not. Seebs is right more often than not. So is Keith Thompson. So is 
Eric Sosman. So is David Thompson. (Non-exhaustive list.) If you are 
ever lucky enough to see the return of Lawrence Kirby or Chris Torek or 
Steve Summit, you will find that they are hardly ever wrong (but "hardly 
ever" is not "never").

That's one reason that newcomers to a newsgroup (*any* newsgroup) do 
well to "lurk" (read, but not post) for a fairly long time - when Usenet 
was first becoming popular, six months was the general recommendation. 
In practice, most people don't do that, and it is hardly rare for them 
to regret posting prematurely.

By reading the group regularly, as I say, you get to know who are the 
people who actually know the language. As for how to deal with such 
people, you could do worse than check out articles by "blmblm" (B L 
Massingill, I think), who - although far from ignorant about C - would 
perhaps not lay claim to deep expertise, but whose articles are 
invariably polite and well-argued.

> In other words, I am a newcomer, here.
> I don't know any of you.  It might be beneficial to my understanding
> of C to get to know some of you. :)  But can I possibly know before-
> hand what magic words will set people off, such as "invent" and
> "claims"?

You can't, I suppose. But what you /can/ do is learn.

> 
> Is it reasonable for me to simply take note of these words and avoid
> them in the future?  Can I do so without feedback like yours,
> Richard?  My answer would be "no."  And so I thank you.

It ain't so much the words as the way how you use them. It comes with 
experience.

> 
> And also you have provided some evidence for the claim; this is
> recorded.  Would you have offered that evidence without my use of
> "claims"?

Nope. No point in rebutting a non-existent statement.


> Does that last question suggest that I used "claims"
> intentionally towards that end?  I didn't.  It was meant as a simple
> statement of fact.
> 
> "Claims" will be dropped from my vocabulary here now, surely.  Do you
> happen to know of a nice list of words to avoid, like these ones?
> That would be great. :)

It isn't so much a word-list as an exercise in objectivity. It can be 
quite difficult to stand back from the text you write and see it as 
others will see it. But it is a worthwhile exercise, nonetheless.


-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

Shao Miller wrote:

<snip>

> 01. void foo(void) {
> 02.   return;
> 03. }
> 04.
> 05. int main(void) {
> 06.   int i = 13;
> 07.   void *v = &i;
> 08.   (void)13;
> 09.   foo();
> 10.   *v;
> 11.   return 0;
> 12. }
> 
> When line 08 is evaluated by a conforming implementation, is the
> behaviour well-defined to produce a result for the expression
> '(void)13'?

Line 08 works like this. 13 (which is of type int) is evaluated. The 
value thus yielded is used as an operand for the cast operator. The cast 
is to void, so the value is discarded. It's hard to argue that there is 
any "result" here - the compiler is perfectly at liberty to ignore the 
line completely, since there are no side effects.

> Does that definition define both a type for the result as
> well as a value for the result?

There is no definition on line 08. The expression (void)13 has type 
void, and this type "comprises an empty set of values", so it is 
meaningless to talk about a "value" for an expression of void type.

> 
> When line 09 is evaluated by a conforming implementation, is the
> behaviour well-defined to produce a result for the expression
> 'foo()'?  Does that definition define both a type for the result as
> well as a value for the result?

See above.

> 
> Using a conforming implementation, is the evaluation of every
> expression within a strictly conforming program well-defined to
> produce a result?

What do you mean by "result" here? A value? If so, the answer is "no". 
Your line 09 is an example of an expression that produces no value.


> In this same circumstance, is that result well-
> defined to possess both a type as well as a value?

See above.

> When line 10 is evaluated by a conforming implementation, is the
> behaviour well-defined to produce a result for the expression '*v'?
> Does that definition define a type for the result?

Since void * cannot be dereferenced, the question does not arise.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

On 2010-07-24, Richard Heathfield <rjh@see.sig.invalid> wrote:
> You get to know, after a while, who tends to be right more often than 
> not. Seebs is right more often than not. So is Keith Thompson. So is 
> Eric Sosman. So is David Thompson. (Non-exhaustive list.) If you are 
> ever lucky enough to see the return of Lawrence Kirby or Chris Torek or 
> Steve Summit, you will find that they are hardly ever wrong (but "hardly 
> ever" is not "never").

My boss once found a bug in some of Chris Torek's code!

.... once.

I haven't yet, although I have now at least once managed to sneak a bug
past his code review.  (That said, my ability to sneak retroactively-obvious
bugs past code review has become something of a local legend.)

>> In other words, I am a newcomer, here.
>> I don't know any of you.  It might be beneficial to my understanding
>> of C to get to know some of you. :)  But can I possibly know before-
>> hand what magic words will set people off, such as "invent" and
>> "claims"?

> You can't, I suppose. But what you /can/ do is learn.

That said, I'm pretty sure the usual convention of using "invented" to mean
"made up" (and thus, not derived from reality, and thus implicitly dishonest)
is sufficiently widespread to not need special newsgroup-specific knowledge.

> It isn't so much a word-list as an exercise in objectivity. It can be 
> quite difficult to stand back from the text you write and see it as 
> others will see it. But it is a worthwhile exercise, nonetheless.

Very much so.

As a quick starting point, just check the things you say to see whether they
would make any sense at all if you were confident the people you're talking
to were being honest.  If they wouldn't, people will reasonably assume you
to be implying that they are dishonest.

Accusing someone of having "invented" something right after they've said
that a given text communicates it implies clearly that the text didn't
communicate that at all -- meaning it implies that they're being dishonest.

Interesting side note:  Several of our protagonist's problems with the
Standard reflect a similar problem -- not being aware of the logical
implications of what is said and what is unsaid.  If I were going to try to
address such a thing, I'd start by studying the Gricean Maxims, because
they're the underlying substrate over which words create meaning.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On Jul 24, 7:30=A0pm, Keith Thompson <ks...@mib.org> wrote:
>
> I don't understand the question. =A0The expression statement in question
> was
> =A0 =A0 (void)13;
> Determining the type of (void)13 is just one of the thousands
> of things an implementation is required to do.
>
Absolutely agreed that it is just one of those things.  The challenge
I perceive from this code is:

Why is a cast to 'void' well-defined but "dereferencing" a 'void *'
not well-defined?

If I'm not mistaken, an expression with 'void' type has no value
(6.3.2.2,p1 "nonexistent" , 6.2.5,p19 "empty set").  When we read
about the "Cast operators" (6.5.4), what I directly observe from its
text is that this operator "converts the value of the expression to
the named type."  The named type in '(void)13' is, of course, 'void'.
We know that an expression with 'void' type has no value, so that must
mean that the value is discarded during the conversion of the value,
would you agree?

Now we look at the text for the unary '*' operator (6.5.3.2,p4).
There we see a definition for the type of the result (of an
evaluation), just as we do for casting, would you agree?  Thus if the
operand has type pointer-to-void, it suggests that the result has type
'void'.  I would suggest that we must use the very same reasoning as
we do in our interpretation of cast operators to conclude that the
result is thus a void-expression (6.3.2.2,p1).  The sentences
describing the result if pointing to an object and pointing to a
function do not apply.  Nonetheless, the text appears to define the
result of evaluating application of unary '*' to an expression with
type pointer-to-void as being a result with type 'void'.  A result
with type 'void' can be considered a void expression just as much as
the cast can be, can it not?

Same thing with a "function returning void" (6.5.2.2,p1).  Its
evaluation is defined to be a result with type 'void' (6.5.2.2,p5).

Why is it that at least the C implementation named "GCC" appears to
distinguish between these three scenarios?  Do other implementations,
as well?

My experience and my "common sense" suggests that "you cannot
dereference a 'void *'."  Unfortunately, the text of the referenced
draft does not make that explicit (as far as I've yet been able to
determine; 6.5.3.2).  Then thinking it through, it appears that
there's really _no_need_ for such indirection to yield UB.  It could
simply be another form of void expression, like the two others.

If we can agree on this, what implications might there be for existent
implementations?  I can only perceive a change to treat the behaviour
(of dereferencing a pointer-to-void) as well-defined, rather than
undefined.  That really doesn't seem like a big deal, to me.

If we forget about _any_ of the debate regarding the "...has been
assigned..." business and accept it to mean what a quick glance might
suggest, we would _still_ have UB if the operand was a null pointer
value, if we additionally accept the non-normative footnote regarding
a null pointer being an invalid value.  No gigantic implications for
implementations, there.

I fear that someone might respond as though the "points to and object"
and "points to a function" combined sentence somehow has some type of
priority over the following "has type" sentence...  But _please_ note
the lack of "shall"s and "shall not"s.

I also fear that someone might respond that any 'void *' value would
be an invalid value, because such a value neither points to an object
nor to a function.  That argument would also ignore the equal
precedence of the sentence regarding "has type".

Direct comparison with the "cast operators" might be useful.  The text
does not define a value when the conversion is to type 'void'.  But
rather than being undefined behaviour, we know from other parts of the
draft that 'void' represents no value(s).  So defining the type of an
expression to be 'void' essentially defines the expression to be a
void expression.  I cannot see how this could be any different for the
unary '*' operator (which we might have to temporarily detach our
familiarity with in order to study in this regard).

Please take your time to consider the implications before responding.
I am very hopeful for an agreement here, but assume that if major
overhauls and negative implications might be perceived, that an
agreement is less likely to happen.  I really don't see how:

int x;
void *p =3D &x;
*p;

could be a huge deal as well-defined behaviour.

It is also possible that someone will point out a reference in the
text that I've read several times but have interpreted differently,
which makes the above proposal impossible.  I'm happy either way.

On Jul 24, 7:33=A0pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> ... ... ...
> > And also you have provided some evidence for the claim; this is
> > recorded. =A0Would you have offered that evidence without my use of
> > "claims"?
>
> Nope. No point in rebutting a non-existent statement.
>
You might have misunderstood me, here.  The "evidence" I meant to
refer to was another person offering that Peter _does_ have a wealth
of knowledge and experience for C.  Regardless of this evidence, to be
honest, it was never a question to me.  I have been operating under
the _assumption_ that _any_ intelligent response received in this
forum (as Peter Seebach's posts after his first are) are those of
seasoned C developers.  The benefit of the doubt is there; my
expectation would be for a responder to have to establish their self
as _less_than_that_ before I would begin to associate less
credibility.  Additionally, I shall not mistakenly associate personal
incompatibilities with a lack of C "seasoning".

>
> ... ... ...
>
I agree 100% with the entirety of this response post of yours,
Richard.  It is, in my opinion, a worth-while read for any newcomer in
my situation.  I will try to keep what you have stated in mind and
consider your references.  I can't thank you enough, really.  I did
not particularly anticipate these experiences when posting about
interests in C.

I'll also not be drawn into personal back-and-forth, because my focus
here is C.

It's possible that part of what has landed me in "hot water" here is
my expectation that discussion could take the form of directly
addressing a response's points in a manner of debate.  Also, that I
sometimes attempt to calibrate my responses based on inferences about
the posters.  This can obviously backfire, big-time.  For example, one
way to establish rapport might be to mimic some of the attitudes
perceived as being possessed by a discussant.  If a poster appears to
me to demonstrate authority without references, I might respond in the
same tone, insofar as it doesn't violate any of my personal
constraints for civil discussion.  It's quite possible to fail to
determine what constitutes civil discussion in the perspective of the
other poster.

Anyway, back to C... Because that's what the subject-at-hand is... :)

Shao Miller wrote:
> On Jul 24, 7:30 pm, Keith Thompson <ks...@mib.org> wrote:
>> I don't understand the question.  The expression statement in question
>> was
>>     (void)13;
>> Determining the type of (void)13 is just one of the thousands
>> of things an implementation is required to do.
>>
> Absolutely agreed that it is just one of those things.  The challenge
> I perceive from this code is:
> 
> Why is a cast to 'void' well-defined but "dereferencing" a 'void *'
> not well-defined?

Because the Standard defines the one but not the other. It's not clear 
what you're trying to get at here.


> If I'm not mistaken, an expression with 'void' type has no value
> (6.3.2.2,p1 "nonexistent" , 6.2.5,p19 "empty set").  When we read
> about the "Cast operators" (6.5.4), what I directly observe from its
> text is that this operator "converts the value of the expression to
> the named type."  The named type in '(void)13' is, of course, 'void'.
> We know that an expression with 'void' type has no value, so that must
> mean that the value is discarded during the conversion of the value,
> would you agree?

13 has a value. (void)13 has no value. Neither, it appears, does your point.

<snip>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

Shao Miller wrote:

<snip>

> The benefit of the doubt is there;

Yes, but you are rapidly using it up.


<snip>

> It's possible that part of what has landed me in "hot water" here is
> my expectation that discussion could take the form of directly
> addressing a response's points in a manner of debate.

No, that's the usual way of things in clc, so that is not the 
explanation for the high temperature of your entry into the group.

<snip>


-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

On Jul 25, 4:18=A0am, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> Because the Standard defines the one but not the other. It's not clear
> what you're trying to get at here.
>
I cannot refer to the standard at this time, I'm afraid.  I can only
refer to the draft with filename 'n1256.pdf'.  In the rest of my post
I have provided quite a bit of detail regarding my interpretation that
this draft _does_ fully define the result of evaluating the (sole)
unary-expression on the third line below of something like:

int i;
void *v =3D &i;
*v;

>
> 13 has a value. (void)13 has no value. Neither, it appears, does your poi=
nt.
>
Did you read the rest of the post?  If so, it would be beneficial to
me if you would address exactly where you perceive faults in my
reasoning about the subject matter.

"The Standard defines the one but not the other" and the implication
that my point has no value really do not help me.  My post provides
detail for how the draft _does_ define both.  I have even met with
agreement on this point by another discussant in another C-devoted
forum, whose pedantry and accuracy I have historically valued.

Why is it that you have snipped so much of my post instead of pointing
out statements you disagree with?

My point is that there is a form of void expression in C which is not
commonly considered.  I have observed at least one implementation to
print a warning, where I see no trouble.  I have reasoned that this
and any other implementation's treatment of this form of void
expression may need addressing.

Is that clear?

On Jul 25, 4:22=A0am, Richard Heathfield <r...@see.sig.invalid> wrote:
> Shao Miller wrote:
>
> > The benefit of the doubt is there;
>
> Yes, but you are rapidly using it up.
>
I am sorry to report that I do not understand this statement.  Could
you please clarify what you mean here?

>
> > It's possible that part of what has landed me in "hot water" here is
> > my expectation that discussion could take the form of directly
> > addressing a response's points in a manner of debate.
>
> No, that's the usual way of things in clc, so that is not the
> explanation for the high temperature of your entry into the group.
>
You have not provided any alternative explanation, but that's fine.  I
shall continue to focus on my concerns with C.

On Jul 25, 4:14=A0am, Shao Miller <sha0.mil...@gmail.com> wrote:
> ...to be
> honest, it was never a question to me. =A0I have been operating under
> the _assumption_ that _any_ intelligent response received in this
> forum (as Peter Seebach's posts after his first are) are those of
> seasoned C developers.
>
Please and kindly allow me to retract this statement regarding
intelligent responses.  It is wholly inaccurate.  The use of the term
"intelligent" was not at all appropriate here.  What I very well
should have said was simply "detailed," instead.  There is no doubt
about the intelligence of Peter Seebach's first post nor of any of his
subsequent posts; no doubt for me and there should be no doubt for any
other reader.  Unfortunately, I was missing a piece, here: "..._any_
intelligent response including detail..."  This inaccuracy has been a
failure of mine and I fully offer an apology for it.

On Sun, 25 Jul 2010 09:18:09 +0100, Richard Heathfield
<rjh@see.sig.invalid> wrote:

>Shao Miller wrote:
>> On Jul 24, 7:30 pm, Keith Thompson <ks...@mib.org> wrote:
>>> I don't understand the question.  The expression statement in question
>>> was
>>>     (void)13;
>>> Determining the type of (void)13 is just one of the thousands
>>> of things an implementation is required to do.
>>>
>> Absolutely agreed that it is just one of those things.  The challenge
>> I perceive from this code is:
>> 
>> Why is a cast to 'void' well-defined but "dereferencing" a 'void *'
>> not well-defined?
>
>Because the Standard defines the one but not the other. It's not clear 
>what you're trying to get at here.


Actually its pretty simple.  He's confused by the void/void*
hack.  Experienced C programmers are so used to it that it that
they don't see it as a hack.  Simply:

C has a whole bunch of primitive types, char, int, long, et al.
(It also has composite types, but let's not go there, okay.)
In addition there are pointer types.  The (almost) uniform rule
is dereferencing something of type T * yields something of type
T.  The exception, of course, is our friends, void and void *.
Despite appearances void * is not a pointer to a void.

Why is void an exception?  It's a hack.  When they were doing the
standard they had two issues they were trying to clear up.  One
was providing a way to say that a function returns nothing.  The
other was to provide generic pointers that would be automatically
converted without casting.  These are two different concepts.
The hack is that they used one keyword for the two concepts,
making void a "it's a dessert topping and a floorwax" thingie.

 

Shao Miller <sha0.miller@gmail.com> wrote:

> On Jul 21, 7:11=A0pm, Denis McMahon <denis.m.f.mcma...@googlemail.co.uk>
> > Do your own homework.
> 
> Wow.  I've not been a student since 1995, but never did homework then,
> either.

That explains a lot.

If you _had_ done your homework when you were in high school, you might
have learned to focus on the important details, not on the unimportant
ones.
The important detail in this case is: what _is_ the required behaviour,
in the abstract machine, of your code? Answer: there is none. And
therefore, the code's behaviour is undefined by omission _even if_ there
is no direct way to prove that it is undefined by commission.

Richard

Shao Miller <sha0.miller@gmail.com> writes:

> On Jul 24, 7:30 pm, Keith Thompson <ks...@mib.org> wrote:
>>
>> I don't understand the question.  The expression statement in question
>> was
>>     (void)13;
>> Determining the type of (void)13 is just one of the thousands
>> of things an implementation is required to do.
>>
> Absolutely agreed that it is just one of those things.  The challenge
> I perceive from this code is:
>
> Why is a cast to 'void' well-defined but "dereferencing" a 'void *'
> not well-defined?

As Richard Harter has said, to some extent it's just a consequence of
the over-use of one keyword.  But there is some logic to the
distinction: Evaluating an expression and throwing way the result is a
commonly done thing (although most often done implicitly).
Dereferencing a pointer to get nothing is a useless activity.

Putting aside the words of the standard for a moment, the purpose of
evaluating an expression of the form *E is to recover a function
designator or an object from a function pointer or an object pointer.
Since void is not an object type, applying * to an expression of type
void * is counter-intuitive and goes against the main point of the
operator.  C chooses to make it undefined.

<snip>
> Now we look at the text for the unary '*' operator (6.5.3.2,p4).
> There we see a definition for the type of the result (of an
> evaluation), just as we do for casting, would you agree?

They both talk about type, but the way the type is used is very
different.  A cast converts and a pointer dereference interprets.  Given
E of type T *, *E does not do any conversion (see the common trick of
"type-punning").

>  Thus if the
> operand has type pointer-to-void, it suggests that the result has type
> 'void'.

I'd say is true at some level, but since there is no defined result,
it's type is not really relevant.  It's like saying the result of 1/0 is
of type int.  Yes it in is some sense, but since it is undefined the
type could be double[7].  When it is not evaluated (and the UB is
avoided) it does then have a type, but so does *(void *)E.

>  I would suggest that we must use the very same reasoning as
> we do in our interpretation of cast operators to conclude that the
> result is thus a void-expression (6.3.2.2,p1).  The sentences
> describing the result if pointing to an object and pointing to a
> function do not apply.  Nonetheless, the text appears to define the
> result of evaluating application of unary '*' to an expression with
> type pointer-to-void as being a result with type 'void'.

Only if you accept that a result can be nothing but a type and if you
reject the "undefined by omission" clause.  Consider this:

  The best slogan will win a car!  The make of car will be the one
  your slogan refers to.

What is the result of submitting the losing slogan "Fords are OK"?

<snip>
> Please take your time to consider the implications before responding.

Some people could take offence at this and, at the same time, it is
unlikely to prevent ill-considered replies.

> I am very hopeful for an agreement here, but assume that if major
> overhauls and negative implications might be perceived, that an
> agreement is less likely to happen.  I really don't see how:
>
> int x;
> void *p = &x;
> *p;
>
> could be a huge deal as well-defined behaviour.

Some bugs (such as the above) would go undetected.  What is the gain
that makes this loss acceptable?  In effect, this is my suggestion in
another form: what useful program needs to apply * to a void *?

<snip>
-- 
Ben.

Shao Miller <sha0.miller@gmail.com> writes:

> On Jul 24, 11:51 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>>
>> Let me propose something else.  Post an example where you think that
>> some significant part of the meaning of the program depends on the
>> answers to your questions.  I.e. find an example that matters.  This
>> will interest people.

> Are you suggesting that the above example doesn't matter?

Not to me, not.  I can't, of course, speak for anyone else.

>> Everyone here (I am guessing) has their favourite examples of where the
>> literal wording in the standard falls short of giving an answer to some
>> question or other but most people want to write effective well-defined C
>> programs and they somehow manage to that despite these details.
>>
> One such well-defined program might even be itself a C
> implementation.  It would be good to do it right by everyone here.

Then I think you asked the wrong questions.  By analogy, it is as if you
asked: What is the result of this piece of C:

  0

because its clearly not an expression?  I am having a hard time
believing that you don't know what an implementation should do with

  (void)13;

-- 
Ben.

Shao Miller <sha0.miller@gmail.com> writes:

> On Jul 24, 11:09 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
<snip>
>> Underlying the specific issue you have is a problem that the standard
>> has never quite managed to resolve.  There are three attributes that
>> matter about an expression and/or its "result"...
>> ... ... ...
>> I'd prefer the wording to be done like this:
>>
>>    Form:        *E
>>    Constraints: The operand, E, must have type 'pointer to T'.
>>    Type:        An expression of the form *E has type T and is an
>>                 lvalue if T is an object type.
>>    Result:      If the result of evaluating E is a pointer to a function,
>>                 the result is a function designator denoting the pointed
>>                 to function.  If E the result of evaluating E is a
>>                 pointer to an object, the result denotes that object.
>>
>> It would then be clear that the type is not really "part of the result"
>> but a property of the expression form -- something essentially static
>> and not associated with the evaluation...
>> ... ... ...
> Agreed.

That suggests that you agree that type is not part of the result -- that
it is a static property of the expression form (roughly speaking, a
compile-time property rather than a run-time one).  If so, then a
type-only result (a run-time idea if ever there was one) in
meaningless.  That is certainly how I read the intent of the standard,
but I think you have repeated the type-only result idea in later replies.

<snip>
>> That is what most people take it to mean.  Why?  Because making special
>> provision for when a pointer is an object that has been assigned to
>> makes no sense when taken literally.  Given:
>>
>>   const int *ip = 0;
>>
> I see the truth of it.  This initialization specifies the value
> initially stored in the object but there is no assignment expression.
> If we take the text to mean "...assigned to the pointer by an
> assignment expression...", then "the pointer" could not have been
> assigned-to.
>
>>
>> *ip would not be covered but it would be after:
>>
>>   int *ip;
>>   ip = 0;
>>
>> Both would remain undefined by omission, so what value would the literal
>> interpretation serve?
>>
> I don't follow you here.  You said '*ip' "would be" covered "after"
> and then said both would remain undefined by omission.

Yes, that's confusing.  Forget for the moment that it is my contention
that both are undefined.  Let's take your reading where defining the
type alone is enough.  In the first case (const int *ip = 0; *ip) the
final sentence about the pointer having been assigned an invalid value
does not apply because there is no assignment.  In the second (int *ip;
ip = 0; *ip) it would be explicitly undefined.  What is the purpose of
this distinction?  Could it be that the wording is wrong?  Maybe
assignment has nothing to do with it and it is just the value of the
pointer that matters?

<snip>
>> Hmmm.  Now I doubt your sincerity again.  Read what you wrote.  You are
>> suggesting that I (and indirectly Tim) want you to treat the largely
>> unpaid work of dozens of experts over more than two decades as no more
>> than a guide to the language.
>>
> Please excuse me.  Have I said suggested incorrectly?

It's probably just a language thing.  "Guide" has this meaning:

  A book of instruction or information for beginners or novices (in an
  art, etc.).  [OED online second edition 1989]

(There are other meaning of course, such a book providing travel
information, but none could relate to the C standard except
figuratively.)

>  Have I
> suggested that this "unpaid work of dozens of experts over more than
> two decades" is not a valuable resource?  If so, what would cause you
> to suggest that have implied/meant/stated that?

Yes but it is probably unintentional.

>  I believe this
> resource to be _the_ most valuable resource for C.  Is it a guide?  In
> what way(s) is it more than guide?

It is not information or instruction for beginners.  It is an
international standard for a programming language.

>  Is it a math textbook?  I would
> answer that with "no."

Me too, but that's not the point.

>> Further more, neither of us is suggesting that "popular consensus" is
>> the main tool to be used when there is ambiguity.  That would be absurd.
>>
>> Do you see how that comes over?
>>
> Then I have misinterpreted and apologize.  What should be the main
> tool in case of ambiguity?

Reasoning, logic, common sense.  All are better than popular consensus.
An example is to follow thought the consequences to the "pointer has
been assigned" sentence to see what it would mean.  Do the consequences
make sense?  Could there be another somewhat figurative interpretation
that seems to make more sense?  It won't always work but it beats
popular consensus any day!

>> I think you need to refine your understanding of the term "common
>> sense".
>>
> An accepted possibility.  So do you suggest that common sense and
> perusal of the draft/standard is all that is required to develop a
> conforming implementation?

I don't know, but I doubt it.  The many formal defect reports suggest not.

>  If so, do you see how that might come over
> to someone?  Would you be willing to help to refine an interpretation
> of the term "common sense"?

Sure.  I gave one example.  In general, if there are two interpretations
that both have sound and useful consequences then we have a real problem
that might be hard to resolve.  It won't always be easy to tell what
constitutes such a conflict but your example of *(char *)0 is not, to my
mind, one of them.

<snip>
>> Either this can't be a constraint (because you mean to include something
>> that can't be tested at compile time) or you have now changed the
>> suggestion to catch only a few cases.  It all depends on what you mean
>> by "evaluating to a null pointer constant or to a null pointer constant
>> cast to any pointer type".
>>
> Can an expression at translation-time evaluate to a null pointer
> constant?

Yes.

>  Can an expression at run-time evaluate to a null pointer
> constant?

It can yield a value that compared equal to one.  Other than that I
don't know what the question means.

>  6.3.2.3 p3 includes detail concerning an "integer constant
> expression".  Could the value of an object be an integer constant
> expression?

The value of an object can compare equal to an integer constant
expression.  Is that what "be" means to you?

>  If everyone knows or at least is adamant that "you can't
> dereference a null pointer," could this constraint hurt the standard
> for C?

You mean, should it be added explicitly?  It think is, very nearly, in
the section you just cited (6.3.2.3 p3).  If you combine this with the
meaning of == between pointers you find that a null pointer can't point
at an object (not can it can't to a function) so * of it is undefined.

>  Could it help to prevent questions like mine from accumulating
> more responses than a single response with a citation?

Yes, probably.  I think we'll have to live without it though.

>> You proposed a constraint (which I have put back since you cut it)
>> "were that the pointer must either point to an object or to a
>> function".  My example (yes, we both agree it is UB) shows that you
>> can't tell *at compile time* if the constraint you originally proposed
>> is or is not violated.
>>
> Agreed.  I have abandoned that constraint in favour of the "null
> pointer constant" constraint mentioned.

That does not seem to be a big gain.  I've never seen a null pointer
constant dereferenced in 25 years of looking at C.  Making it a
constraint violation won't help much.

>> There is no mention of your suggested type-only results.  They would be
>> a major part of the language.  How do they work?  What can we do with
>> them?
>>
> Could a void expression be considered a type-only result?  6.3.2.2 p1
> describes an expression with no value (an empty set) and type 'void'.
> Did we agree that such an expression is evaluated?  They way I
> perceive them to work is: If an expression's type is defined to have a
> type "T" and a value is not defined for evaluation, and that type "T"
> is 'void', the expression is a void expression.  Is this a reasonable
> perspective?

Not to me, no.  In effect it adds only one new value to the language --
one that can't be used for anything.  That does not seem reasonable.  It
seems that you've rejected all other type-only values so do you see
*(char *)0  as undefined now?

-- 
Ben.

On 2010-07-25, Richard Heathfield <rjh@see.sig.invalid> wrote:
> Shao Miller wrote:
>> It's possible that part of what has landed me in "hot water" here is
>> my expectation that discussion could take the form of directly
>> addressing a response's points in a manner of debate.

> No, that's the usual way of things in clc, so that is not the 
> explanation for the high temperature of your entry into the group.

Exactly.  The use of "invented" to refer to someone else's position is not
addressing their position, but making a meta-claim about it, which is that
their position was manufactured, rather than being the result of study of
the external world.  That's what "invented" means.

And again, someone whose English skills don't make this fairly obvious should
not be arguing with people about the meanings of English sentences, in
general.

I've seen plenty of people with much more controversial points argue them
without trouble, because they didn't start out by insulting people and
ignoring what other people had to say, or dismissing it with nothing more
solid than "but I'm still not certain".  (The latter may be, if anything,
more annoying; once you've presented a rigorous formal proof, for someone
to continue to say "but I'm not convinced, show me more explicit evidence"
is at the very least going to be frustrating.)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On Jul 25, 10:59=A0am, c...@tiac.net (Richard Harter) wrote:
>
> Actually its pretty simple. =A0He's confused by the void/void*
> hack.
I disagree regarding confusion, but around the hack.

>
>=A0Experienced C programmers are so used to it that it that
> they don't see it as a hack. =A0Simply:
>
> C has a whole bunch of primitive types, char, int, long, et al.
> (It also has composite types, but let's not go there, okay.)
> In addition there are pointer types. =A0The (almost) uniform rule
> is dereferencing something of type T * yields something of type
> T. =A0The exception, of course, is our friends, void and void *.
> Despite appearances void * is not a pointer to a void.
>
I do not dispute that "void * is not a pointer to a void".  Does is
not, however, have type "pointer-to-void"?  I believe that it does.
That is not confusing.

>
> Why is void an exception? =A0It's a hack.
>
I deduced this the first time I'd read a book on C.  I might have
tried the same hack.

>=A0When they were doing the
> standard they had two issues they were trying to clear up. =A0One
> was providing a way to say that a function returns nothing. =A0The
> other was to provide generic pointers that would be automatically
> converted without casting.
Just a guess: The third was allowing for an uninteresting result to be
discarded.  Would you agree?

int func(void) {
  return 5;
}

int main(void) {
  (void)func();
  return 0;
}

>
>=A0These are two different concepts.
> The hack is that they used one keyword for the two concepts,
> making void a "it's a dessert topping and a floorwax" thingie.
>
Yes and I agree.  It slices and dices and makes orange juice out of
sawdust. :)

Thank you for your response, Richard.

On Jul 25, 11:57=A0am, ralt...@xs4all.nl (Richard Bos) wrote:
>
> That explains a lot.
>
> If you _had_ done your homework when you were in high school, you might
> have learned to focus on the important details, not on the unimportant
> ones.
>
It is not clear to me as to which discussion I've provided that
suggests a focus on unimportant details.  Perhaps you have only read
some of the posts, here?  Regardless of which details you mean, what
is it exactly that deems them as important or unimportant?  I think
that a detail with consequences would be more important than a detail
with none, in discussion of this subject matter.  Is that a quick,
cheap way to think of it that you would agree with?

>
> The important detail in this case is: what _is_ the required behaviour,
> in the abstract machine, of your code? Answer: there is none. And
> therefore, the code's behaviour is undefined by omission _even if_ there
> is no direct way to prove that it is undefined by commission.
>
The matter of '(void)*(char *)0;' is resolved for myself as certainly
UB, by the way.  Are you referring to some other code?  What would be
the best way to announce that the matter of the original post is
resolved, to avoid wasting the time of responders who still believe it
to be an issue?  What I did was to respond to the first post.  Was
there a better way?

On Jul 25, 12:12=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> As Richard Harter has said, to some extent it's just a consequence of
> the over-use of one keyword. =A0But there is some logic to the
> distinction: Evaluating an expression and throwing way the result is a
> commonly done thing (although most often done implicitly).
> Dereferencing a pointer to get nothing is a useless activity.
>
What I have attempted to suggest over and over again is that it should
be simply another form of void expression.  We have two already, why
not three?  Please consider:

static int i =3D 15;

void *func(void) {
  i++;
  return &i;
}

int main(void) {
  *func();
  return 0;
}

Compare 'main()' to this one:

int main(void) {
  (void)func();
  return 0;
}

My personal aesthetic would be for the former, rather than the
latter.  I have suggested that the unary '*' operator defines the
result of '*func()' above to have type 'void'.  Since this is known to
be a void expression (at translation time), and void expressions are
evaluated for their side effects, what is the problem here?  In this
context, the unary '*' would simply mean "throw away the returned
'void *'".  To me, that would be useful, not useless.

>
> Putting aside the words of the standard for a moment, the purpose of
> evaluating an expression of the form *E is to recover a function
> designator or an object from a function pointer or an object pointer.
>
Sure.  I even agree that that's the only way anyone I've ever known to
use it has used it.  It just so happens that another purpose might
yield a pleasantry.  Somewhat akin to the multiple purposes of 'void'
in the first place (the "hack").

>
> Since void is not an object type, applying * to an expression of type
> void * is counter-intuitive and goes against the main point of the
> operator. =A0C chooses to make it undefined.
>
Ok, but what about the referenced draft?  It appears to be well-
defined there as a void expression.

>
> They both talk about type, but the way the type is used is very
> different. =A0A cast converts and a pointer dereference interprets.
>
This is an interesting perspective to me and I will try to follow
along your train of thought, here.

>=A0Given
> E of type T *, *E does not do any conversion (see the common trick of
> "type-punning").
>
Agreed.  No conversion of a value.  However, if you consider taking an
operand of one type and returning a result with another type, that
might be considered to be a conversion of type.  Would you agree?

>
> > =A0Thus if the
> > operand has type pointer-to-void, it suggests that the result has type
> > 'void'.
>
> I'd say is true at some level, but since there is no defined result,
> it's type is not really relevant.
>
My reasoning goes:
1. A type for the result is defined.
2. That type is defined to be 'void'.
3. Such a result is a void expression.
4. By 1, 2, 3, it is defined to be a void expression.

Do you perceive a flaw in this reasoning for any of those points?
Compare to casting to 'void':
1. A type for the result is defined.
2. That type is defined to be 'void'.
3. Such a result is a void expression.
4. By 1, 2, 3, it is defined to be a void expression.

Essentially, does any other treatment not need to pull in that 'void
*' is not a valid type for an operand of unary '*' from somewhere?
Does any other treatment not need to suggest that the operand
_shall_only_ have type pointer-to-function-type or type pointer-to-
object-type?

>
>=A0It's like saying the result of 1/0 is
> of type int. =A0Yes it in is some sense, but since it is undefined the
> type could be double[7]. =A0When it is not evaluated (and the UB is
> avoided) it does then have a type, but so does *(void *)E.
>
We are in agreement, here.  Also note that in:

int i =3D 15;
void *p =3D &i;
void *q;
q =3D p;
*p;

Evaluation of 'p' is defined, because we can assign it to 'q'.  So at
what point exactly during evaluation of the last line does the
undefined behaviour creep in?  If 'p' had an invalid value
(uninitialized, unassigned), surely that would be UB.

>
> Only if you accept that a result can be nothing but a type and if you
> reject the "undefined by omission" clause.
>
Does the result of casting to 'void' not have nothing but a type?  Is
not the result of calling a "function returning void" one with nothing
but a type?  I readily accept the "undefined by omission" clause.  But
is it not _included_?  "If the operand has type =91=91pointer to type=92=92=
,
the result has type =91=91type=92=92." 6.5.3.2,p4.  Are 'void' and 'void *'
not both types?

>
>=A0Consider this:
>
> =A0 The best slogan will win a car! =A0The make of car will be the one
> =A0 your slogan refers to.
>
> What is the result of submitting the losing slogan "Fords are OK"?
>
The losing slogan is evaluated for its side effects (judges'
consideration) and the prize to the loser has no value and cannot be
used in any way.  Is that not so?

>
> Some people could take offence at this and, at the same time, it is
> unlikely to prevent ill-considered replies.
>
What do _you_ perceive as potentially offensive about this request?  I
cannot fathom how this could be offensive at all.  I explain directly
thereafter that I believe that if major overhauls or negative
implications are perceived, that we are less likely to reach an
agreement.  So if someone takes their time to consider the
implications, not only can they offer a nice set of implications, but
I can have some degree of certainty that their agreement was not based
on a quick read.

>
> Some bugs (such as the above) would go undetected.
>
I think what you are suggesting here is that if we agree on well-
defined behaviour and treat it as a void expression, that a programmer
might not have intended it and will have a tough time finding it.

Suppose, for a moment, the a programmer had forgotten the type of
'p' (thought it was 'int *') as well as the prefix increment
operator.  That might be a reasonably common error (it's two
keystrokes away from '*p;').  Constraint 6.5.3.1,p1 catches it.

Another "two-keystroker" would be a function call with no arguments.
If the programmer tried this and the function did not have type
"function returning pointer-to-void", we should catch either a "result
unused" or an attempt to dereference something not a pointer, perhaps.

No problems, with those.

>
>=A0What is the gain
> that makes this loss acceptable? =A0In effect, this is my suggestion in
> another form: what useful program needs to apply * to a void *?
>

static int i =3D 15;

void *func(void) {
  i++;
  return &i;
}

int main(void) {
  int *j;
  int k =3D 5;
  j =3D func();
  /* ... */
  j =3D &k;
  /*
   * We don't have a pointer to 'i' any more, but wish to increment
it.
   * We know that 'func()' does this, but we are using 'j' for 'k'
indirection.
   * Call 'func' and discard its result.
   */
  *func();
  return 0;
}

Thanks, Ben.

On Jul 25, 12:22=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> Not to me, not. =A0I can't, of course, speak for anyone else.
>
That's completely fair.

>
> Then I think you asked the wrong questions. =A0By analogy, it is as if yo=
u
> asked: What is the result of this piece of C:
>
> =A0 0
>
> because its clearly not an expression?
>
I believe that that is an expression.  "An expression is a sequence of
operators and operands that specifies computation of a
value, or that designates an object or a function, or that generates
side effects, or that
performs a combination thereof." 6.5,p1.  This definition has already
been noted by Keith and I believe yourself as odd.  We can agree to
reasonably try to disambiguate with other parts of the text.  "A
constant is a primary expression. Its type depends on its form and
value, as detailed in 6.4.4." 6.5.1,p3.

>
>=A0I am having a hard time
> believing that you don't know what an implementation should do with
>
> =A0 (void)13;
>
I believe that you have misunderstood my question.  Response posts
have continually demonstrated that my non-questions might be offensive
to some posters, despite my lack of intention for such offence.  I
have no trouble seeing that '(void)13;' should:
1. Convert the value of the expression '13' to a result with type
'void'.  'void' cannot have a value, so the value is discarded.
2. Note that an expression of type 'void' is a void expression.
3. Note that this expression is part of an expression statement.

On Jul 25, 1:44=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> Exactly. =A0The use of "invented" to refer to someone else's position is =
not
> addressing their position, but making a meta-claim about it, which is tha=
t
> their position was manufactured, rather than being the result of study of
> the external world. =A0That's what "invented" means.
>
I have apologized for my use of "invented" already, for how it was
interpreted.  If one allows one's self, just for a minute, to consider
the perspective of a person expecting each and every point in a
convincing argument to be something like:
A. Such-and-such, as per [reference]
B. Such-and-such-else, as per [reference]
C. Yet more, as per [reference]
D. Can we agree on [something without reference]?
E. I interpret "foo" to mean "bar"
F. Can we agree that with A, B, C, D, E, that "baz"?  That's how I got
to "baz" for myself.

That is, this draws from material accessible to both parties, instead
of knowledge and experience available to only one party.  It also
draws on agreements between both parties.  It also details a personal
interpretation of something, giving at least more detail about
something.

You might notice that many of my posts take this form.  Hopefully,
thus shows that I am not a hypocrite.

Now if one further allows one's self to additionally consider the use
of "invented" as meaning neither explicitly referenced, brought
forward as something to be agreed upon, nor brought forward as
anything more than a personal interpretation, its use makes sense
without insulting the knowledge and experience of the poster.  What it
means is "where does that come from?  You don't specify."

I had hoped that that was clear when I added to what I meant by
"invented."  When I first wrote "invented" and thought about it, I
thought, "that's too harsh."  Hopefully that can put to rest the
argument regarding familiarity with English speakers' use of English.
I added the additional meaning to try to help to clarify what was
meant.  I did not scroll up and type it out as high as I meant to,
before the first use of "invented."  It appears that even the
additional meaning was not enough to clarify.  In fact, "invent" has
proven here to be a word with a gigantic impact.  I imagine steam
coming out of ears and eyes wide.

If one allows one's self to be tolerant of the perspectives of others,
one might see how I was constraining my own interpretation of response
posts with this perspective.  That's my challenge to deal with the
consequences.  A huge mistake was having this expectation without ever
having agreed upon rules of engagement.  I have already apologized.

>
> And again, someone whose English skills don't make this fairly obvious sh=
ould
> not be arguing with people about the meanings of English sentences, in
> general.
>
And that's Peter Seebach's opinion on "invented" and "fairly obvious"
as being an insult.  The opinion has value to me, now.  I disagree
that a party's inappropriate use of one word warrants dismissal of any
other of that party's arguments.  That strikes me as too general an
argument for so little a "mistake".

>
> I've seen plenty of people with much more controversial points argue them
> without trouble, because they didn't start out by insulting people and
> ignoring what other people had to say, or dismissing it with nothing more
> solid than "but I'm still not certain". =A0(The latter may be, if anythin=
g,
> more annoying; once you've presented a rigorous formal proof, for someone
> to continue to say "but I'm not convinced, show me more explicit evidence=
"
> is at the very least going to be frustrating.)
>
A: Such-and-such.
B: No way!
A: Whatever.  You're obviously a moron without any capacity for
reasoning and I don't care.
B: That's fine that you don't care to discuss it any longer.

Compare to:
A: Such-and-such.
B: No way!  But it's fine if that leads you to not care to discuss it
anymore.
A: You're right.  I don't.

The latter avoids a personal attack and was fully my intention.  The
technique does not always work.

Shao Miller <sha0.miller@gmail.com> writes:

> On Jul 25, 12:22 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
<snip>
>> I am having a hard time
>> believing that you don't know what an implementation should do with
>>
>>   (void)13;
>>
> I believe that you have misunderstood my question.

Maybe.  But it does not matter.  You have a habit of cutting off all the
context so to explain myself I'd have to put it all back.  Life is too
short for that.

<snip>
-- 
Ben.

On Jul 25, 1:30=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> That suggests that you agree that type is not part of the result -- that
> it is a static property of the expression form (roughly speaking, a
> compile-time property rather than a run-time one). =A0If so, then a
> type-only result (a run-time idea if ever there was one) in
> meaningless. =A0That is certainly how I read the intent of the standard,
> but I think you have repeated the type-only result idea in later replies.
>
As someone pointed out, the meaning of "result" not being set out
explicitly in the discussion might be hindering mutual understanding.
I personally consider the "result" of an expression in C to have both
static properties available at translation time as well as possibly
associated values during evaluation at execution time.

As far as I'm concerned, an expression is "what you wrote" and a
result is "what you get."  You "get" some things at translation-time
and possibly other things during evaluation at execution time.

Without considering "result" in this way, it is possible that we might
consider it to only have meaning during evaluation at execution time,
and requiring a value.  That is simply not the way I consider it.  If
you or others would rather that I did, I shall do so for the purposes
of common meaning during discussion.  In that case, I'd have to resort
to using "expression" only.  I would be reluctant to do so since
'sizeof' would have trouble determining the type of the expression
'*(char *)c', since the text only defines the type for results.

>
> Yes, that's confusing. =A0Forget for the moment that it is my contention
> that both are undefined. =A0Let's take your reading where defining the
> type alone is enough. =A0In the first case (const int *ip =3D 0; *ip) the
> final sentence about the pointer having been assigned an invalid value
> does not apply because there is no assignment. =A0In the second (int *ip;
> ip =3D 0; *ip) it would be explicitly undefined. =A0What is the purpose o=
f
> this distinction? =A0Could it be that the wording is wrong? =A0Maybe
> assignment has nothing to do with it and it is just the value of the
> pointer that matters?
>
Hence my posts where I have agreed to treatment of that text to mean
it as it has been offered by other posters, including yourself.  Keith
pointed out that evaluation of a pointer yielded a value, and that
that value, not an lvalue, was the operand to '*'.  I think we all
agree with that.  I'm trying to drop discussion of the point.

>
> It's probably just a language thing. =A0"Guide" has this meaning:
>
> =A0 A book of instruction or information for beginners or novices (in an
> =A0 art, etc.). =A0[OED online second edition 1989]
>
> (There are other meaning of course, such a book providing travel
> information, but none could relate to the C standard except
> figuratively.)
>
Ahem.  Will you please observe the first two sentences found here[1]?
They are:

"The Oxford English Dictionary is the accepted authority on the
evolution of the English language over the last millennium. It is an
unsurpassed guide to the meaning, history, and pronunciation of over
half a million words, both present and past."

Please note that "guide" is included there, and that you have
referenced this guide to support your point that my use of the word
could be offensive.

Perhaps there is something else that could be offending.  I don't
really want to get into it, as it would be tangential to my current
interest regarding dereferencing pointers to 'void'.

> > =A0Have I
> > suggested that this "unpaid work of dozens of experts over more than
> > two decades" is not a valuable resource? =A0If so, what would cause you
> > to suggest that have implied/meant/stated that?
>
> Yes but it is probably unintentional.
>
No, I have not.  If you and certain other posters continue to inject
negative implications, connotations, or anything else that can be
perceived negatively to my statements just because you do not like
what I have to say, the most I can do is to address it and apologize.
Is it remotely possible that these "bad things" are being attached for
some other reason?  I appreciate that you have recognized that "it is
probably unintentional."  That's the absolute truth, so thanks for
seeing it.

> > =A0I believe this
> > resource to be _the_ most valuable resource for C. =A0Is it a guide? =
=A0In
> > what way(s) is it more than guide?
>
> It is not information or instruction for beginners. =A0It is an
> international standard for a programming language.
>
Right.

> > =A0Is it a math textbook? =A0I would
> > answer that with "no."
>
> Me too, but that's not the point.
>
The point is to avoid calling the draft for a standard of C with
filename 'n1256.pdf' a "guide."  Fine.  Another word to add to my
list.  Only identified with your kind feedback.

> >> Further more, neither of us is suggesting that "popular consensus" is
> >> the main tool to be used when there is ambiguity. =A0That would be abs=
urd.
>
> >> Do you see how that comes over?
>
> > Then I have misinterpreted and apologize. =A0What should be the main
> > tool in case of ambiguity?
>
> Reasoning, logic, common sense. =A0All are better than popular consensus.
> An example is to follow thought the consequences to the "pointer has
> been assigned" sentence to see what it would mean. =A0Do the consequences
> make sense? =A0Could there be another somewhat figurative interpretation
> that seems to make more sense? =A0It won't always work but it beats
> popular consensus any day!
>
I must have omitted that the path would be:
1. Read the material
2. Apply reasoning, logic, common sense
3. In case of ambiguity, find out how others interpret

For me, 3 is not possible without 2.  Ambiguity cannot be determined
without having applied these things.  Would you agree?

> >> I think you need to refine your understanding of the term "common
> >> sense".
>
> > An accepted possibility. =A0So do you suggest that common sense and
> > perusal of the draft/standard is all that is required to develop a
> > conforming implementation?
>
> I don't know, but I doubt it. =A0The many formal defect reports suggest n=
ot.
>
Agreed.

> > =A0If so, do you see how that might come over
> > to someone? =A0Would you be willing to help to refine an interpretation
> > of the term "common sense"?
>
> Sure. =A0I gave one example. =A0In general, if there are two interpretati=
ons
> that both have sound and useful consequences then we have a real problem
> that might be hard to resolve. =A0It won't always be easy to tell what
> constitutes such a conflict but your example of *(char *)0 is not, to my
> mind, one of them.
>
Tirelessly agreed-to.  Let us all please drop '(void)*(char *)0;' and
discuss dereferencing a pointer-to-void as a useful form of void
expression.

>
> >> Either this can't be a constraint (because you mean to include somethi=
ng
> >> that can't be tested at compile time) or you have now changed the
> >> suggestion to catch only a few cases. =A0It all depends on what you me=
an
> >> by "evaluating to a null pointer constant or to a null pointer constan=
t
> >> cast to any pointer type".
>
> > Can an expression at translation-time evaluate to a null pointer
> > constant?
>
> Yes.
>
Agreed.

> > =A0Can an expression at run-time evaluate to a null pointer
> > constant?
>
> It can yield a value that compared equal to one. =A0Other than that I
> don't know what the question means.
>
The "snipped" context was regarding my proposal for a constraint.  If
I "snipped" it, I apologize.  You've suggested in another post that
that behaviour on my part demands more time to restore context.  I'll
cut it out.  (Get it?)

Since the constraint regards an integer constant expression and casts,
the constraint is a legitimate translation-time constraint.  Would you
agree?

> > =A06.3.2.3 p3 includes detail concerning an "integer constant
> > expression". =A0Could the value of an object be an integer constant
> > expression?
>
> The value of an object can compare equal to an integer constant
> expression. =A0Is that what "be" means to you?
>
Sure it can compare equal to one.  This value cannot "be" one, right.
An expression can "be" one, can it not?  We are considering
expressions at translation-time.  The constraint has meaning.

> > =A0If everyone knows or at least is adamant that "you can't
> > dereference a null pointer," could this constraint hurt the standard
> > for C?
>
> You mean, should it be added explicitly? =A0It think is, very nearly, in
> the section you just cited (6.3.2.3 p3). =A0If you combine this with the
> meaning of =3D=3D between pointers you find that a null pointer can't poi=
nt
> at an object (not can it can't to a function) so * of it is undefined.
>
Yes, I did mean that I believe it should be added explicitly.  The
additional constraint results in an implementation being capable of
diagnosing it at translation-time.  That is valuable.  Undefined
behaviour by the last sentence is during evaluation.  Consider
'sizeof'.

> > =A0Could it help to prevent questions like mine from accumulating
> > more responses than a single response with a citation?
>
> Yes, probably. =A0I think we'll have to live without it though.
>
Agreed.  One can hope.

> >> You proposed a constraint (which I have put back since you cut it)
> >> "were that the pointer must either point to an object or to a
> >> function". =A0My example (yes, we both agree it is UB) shows that you
> >> can't tell *at compile time* if the constraint you originally proposed
> >> is or is not violated.
>
> > Agreed. =A0I have abandoned that constraint in favour of the "null
> > pointer constant" constraint mentioned.
>
> That does not seem to be a big gain. =A0I've never seen a null pointer
> constant dereferenced in 25 years of looking at C. =A0Making it a
> constraint violation won't help much.
>
Hey, I haven't seen one either, fortunately. :)  Help much?  Maybe
not, other than for 'sizeof', at least.  A better chance to request of
the novice, "What do you think you're doing?"

> >> There is no mention of your suggested type-only results. =A0They would=
 be
> >> a major part of the language. =A0How do they work? =A0What can we do w=
ith
> >> them?
>
> > Could a void expression be considered a type-only result? =A06.3.2.2 p1
> > describes an expression with no value (an empty set) and type 'void'.
> > Did we agree that such an expression is evaluated? =A0They way I
> > perceive them to work is: If an expression's type is defined to have a
> > type "T" and a value is not defined for evaluation, and that type "T"
> > is 'void', the expression is a void expression. =A0Is this a reasonable
> > perspective?
>
> Not to me, no. =A0In effect it adds only one new value to the language --
> one that can't be used for anything. =A0That does not seem reasonable. =
=A0It
> seems that you've rejected all other type-only values so do you see
> *(char *)0 =A0as undefined now?
See above.

Thanks, Ben.

[1] http://dictionary.oed.com/about/

Shao Miller <sha0.miller@gmail.com> writes:

> On Jul 25, 12:12 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>>
>> As Richard Harter has said, to some extent it's just a consequence of
>> the over-use of one keyword.  But there is some logic to the
>> distinction: Evaluating an expression and throwing way the result is a
>> commonly done thing (although most often done implicitly).
>> Dereferencing a pointer to get nothing is a useless activity.
>>
> What I have attempted to suggest over and over again is that it should
> be simply another form of void expression.  We have two already, why
> not three?  Please consider:
>
> static int i = 15;
>
> void *func(void) {
>   i++;
>   return &i;
> }
>
> int main(void) {
>   *func();
>   return 0;
> }
>
> Compare 'main()' to this one:
>
> int main(void) {
>   (void)func();
>   return 0;
> }
>
> My personal aesthetic would be for the former, rather than the
> latter.

Mine is for a third:

  func();

Your suggestion seems to have very little utility.

>  I have suggested that the unary '*' operator defines the
> result of '*func()' above to have type 'void'.  Since this is known to
> be a void expression (at translation time), and void expressions are
> evaluated for their side effects, what is the problem here?  In this
> context, the unary '*' would simply mean "throw away the returned
> 'void *'".  To me, that would be useful, not useless.

You do know it's undefined, yes?  The problem is suggesting a change to
a language standard with so little benefit.  I see from later text that
you don't agree that it's undefined.  If the current language permitted
it, there would be no problem.  I'd still advice people to chose my
simpler function call but you would free to use *func() all you want.

<void>
>> Since void is not an object type, applying * to an expression of type
>> void * is counter-intuitive and goes against the main point of the
>> operator.  C chooses to make it undefined.
>>
> Ok, but what about the referenced draft?  It appears to be well-
> defined there as a void expression.

Well, I think not.  void is an incomplete type not an object type and a
void * is therefore not a pointer to an object for the purposes of the *
operator.  If it were, * would yield an lvalue of type void which
directly contradicts 6.3.2.1 p1:

  An lvalue is an expression with an object type or an incomplete type
  other than void;

<snip>
>> Given
>> E of type T *, *E does not do any conversion (see the common trick of
>> "type-punning").
>>
> Agreed.  No conversion of a value.  However, if you consider taking an
> operand of one type and returning a result with another type, that
> might be considered to be a conversion of type.  Would you agree?

No.  Conversions have special rules in C.  To use the term for something
else would add confusion.

>> >  Thus if the
>> > operand has type pointer-to-void, it suggests that the result has type
>> > 'void'.
>>
>> I'd say is true at some level, but since there is no defined result,
>> it's type is not really relevant.
>>
> My reasoning goes:
> 1. A type for the result is defined.
> 2. That type is defined to be 'void'.
> 3. Such a result is a void expression.
> 4. By 1, 2, 3, it is defined to be a void expression.
>
> Do you perceive a flaw in this reasoning for any of those points?

Yes.  The type is not enough.  The pointer must be an object pointer not
a pointer to an incomplete type.

> Compare to casting to 'void':
> 1. A type for the result is defined.
> 2. That type is defined to be 'void'.
> 3. Such a result is a void expression.
> 4. By 1, 2, 3, it is defined to be a void expression.
>
> Essentially, does any other treatment not need to pull in that 'void
> *' is not a valid type for an operand of unary '*' from somewhere?
> Does any other treatment not need to suggest that the operand
> _shall_only_ have type pointer-to-function-type or type pointer-to-
> object-type?

Undefined by omission.  That's way stronger than a suggestion.  If you
don't accept it, just say and I'll shut up.  I have no interest in
persuading you one way or the other.

>> It's like saying the result of 1/0 is
>> of type int.  Yes it in is some sense, but since it is undefined the
>> type could be double[7].  When it is not evaluated (and the UB is
>> avoided) it does then have a type, but so does *(void *)E.
>>
> We are in agreement, here.  Also note that in:
>
> int i = 15;
> void *p = &i;
> void *q;
> q = p;
> *p;
>
> Evaluation of 'p' is defined, because we can assign it to 'q'.  So at
> what point exactly during evaluation of the last line does the
> undefined behaviour creep in?

When the * is applied to something that is no an object pointer (or a
function pointer).

>  If 'p' had an invalid value
> (uninitialized, unassigned), surely that would be UB.
>
>>
>> Only if you accept that a result can be nothing but a type and if you
>> reject the "undefined by omission" clause.
>>
> Does the result of casting to 'void' not have nothing but a type?  Is
> not the result of calling a "function returning void" one with nothing
> but a type?  I readily accept the "undefined by omission" clause.  But
> is it not _included_?  "If the operand has type ‘‘pointer to type’’,
> the result has type ‘‘type’’." 6.5.3.2,p4.  Are 'void' and 'void *'
> not both types?

You've lost me.  Yes they are both type.  Were the result defined, we'd
know its type.  It's pointless knowing the type if the result is not
defined.  That was the point of the analogy:

>> Consider this:
>>
>>   The best slogan will win a car!  The make of car will be the one
>>   your slogan refers to.
>>
>> What is the result of submitting the losing slogan "Fords are OK"?
>>
> The losing slogan is evaluated for its side effects (judges'
> consideration) and the prize to the loser has no value and cannot be
> used in any way.  Is that not so?

There is a prize to the loser?  Not by my reading.  The result is
undefined by omission in my book.  Knowing what type it _would_ be were
the slogan to win makes no difference to the undefined nature of the
result.

>> Some people could take offence at this and, at the same time, it is
>> unlikely to prevent ill-considered replies.
>>
> What do _you_ perceive as potentially offensive about this request?  I
> cannot fathom how this could be offensive at all.

It's just my opinion.  Please disregard it.

<snip> -- and I did not cut the code that is being discussed here.
>> Some bugs (such as the above) would go undetected.
>>
> I think what you are suggesting here is that if we agree on well-
> defined behaviour and treat it as a void expression, that a programmer
> might not have intended it and will have a tough time finding it.

"Tough time" is much more than I'd say.  You are proposing a relaxation
of a current rule (from my point of view -- I know you don't agree
with that view) so the space of valid programs grows a little, however
small.  This is a cost -- a tiny one -- which might be worth it if there
is a benefit.

> Suppose, for a moment, the a programmer had forgotten the type of
> 'p' (thought it was 'int *') as well as the prefix increment
> operator.  That might be a reasonably common error (it's two
> keystrokes away from '*p;').  Constraint 6.5.3.1,p1 catches it.
>
> Another "two-keystroker" would be a function call with no arguments.
> If the programmer tried this and the function did not have type
> "function returning pointer-to-void", we should catch either a "result
> unused" or an attempt to dereference something not a pointer, perhaps.
>
> No problems, with those.

I can't follow any of this.

>> What is the gain
>> that makes this loss acceptable?  In effect, this is my suggestion in
>> another form: what useful program needs to apply * to a void *?
>>
> static int i = 15;
>
> void *func(void) {
>   i++;
>   return &i;
> }
>
> int main(void) {
>   int *j;
>   int k = 5;
>   j = func();
>   /* ... */
>   j = &k;
>   /*
>    * We don't have a pointer to 'i' any more, but wish to increment
> it.
>    * We know that 'func()' does this, but we are using 'j' for 'k'
> indirection.
>    * Call 'func' and discard its result.
>    */
>   *func();
>   return 0;
> }

I'd call func();.  If you want to signal the discarded value,
(void)func(); does that much more clearly.  I don't see any benefit to
the *.

-- 
Ben.

Shao Miller <sha0.miller@gmail.com> writes:

> On Jul 25, 1:30 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>>
>> That suggests that you agree that type is not part of the result -- that
>> it is a static property of the expression form (roughly speaking, a
>> compile-time property rather than a run-time one).  If so, then a
>> type-only result (a run-time idea if ever there was one) in
>> meaningless.  That is certainly how I read the intent of the standard,
>> but I think you have repeated the type-only result idea in later replies.
>>
> As someone pointed out, the meaning of "result" not being set out
> explicitly in the discussion might be hindering mutual understanding.
> I personally consider the "result" of an expression in C to have both
> static properties available at translation time as well as possibly
> associated values during evaluation at execution time.
>
> As far as I'm concerned, an expression is "what you wrote" and a
> result is "what you get."  You "get" some things at translation-time
> and possibly other things during evaluation at execution time.
>
> Without considering "result" in this way, it is possible that we might
> consider it to only have meaning during evaluation at execution time,
> and requiring a value.  That is simply not the way I consider it.  If
> you or others would rather that I did, I shall do so for the purposes
> of common meaning during discussion.  In that case, I'd have to resort
> to using "expression" only.  I would be reluctant to do so since
> 'sizeof' would have trouble determining the type of the expression
> '*(char *)c', since the text only defines the type for results.

That does not clear up the question of whether, in your opinion, a
result can be defined because the type is defined (and nothing more).
Obviously I'm a "no" on that and I don't think any more debate will be
useful so a simple "yes" or "no" from you will be enough to end this
topic.

>> Yes, that's confusing.  Forget for the moment that it is my contention
>> that both are undefined.  Let's take your reading where defining the
>> type alone is enough.  In the first case (const int *ip = 0; *ip) the
>> final sentence about the pointer having been assigned an invalid value
>> does not apply because there is no assignment.  In the second (int *ip;
>> ip = 0; *ip) it would be explicitly undefined.  What is the purpose of
>> this distinction?  Could it be that the wording is wrong?  Maybe
>> assignment has nothing to do with it and it is just the value of the
>> pointer that matters?
>>
> Hence my posts where I have agreed to treatment of that text to mean
> it as it has been offered by other posters, including yourself.  Keith
> pointed out that evaluation of a pointer yielded a value, and that
> that value, not an lvalue, was the operand to '*'.  I think we all
> agree with that.  I'm trying to drop discussion of the point.

OK.  This whole thread will be wrapped up in no time!

>> It's probably just a language thing.  "Guide" has this meaning:
>>
>>   A book of instruction or information for beginners or novices (in an
>>   art, etc.).  [OED online second edition 1989]
>>
>> (There are other meaning of course, such a book providing travel
>> information, but none could relate to the C standard except
>> figuratively.)
>>
> Ahem.  Will you please observe the first two sentences found here[1]?
> They are:
>
> "The Oxford English Dictionary is the accepted authority on the
> evolution of the English language over the last millennium. It is an
> unsurpassed guide to the meaning, history, and pronunciation of over
> half a million words, both present and past."
>
> Please note that "guide" is included there, and that you have
> referenced this guide to support your point that my use of the word
> could be offensive.

Of course the OED is a guide to the language.  It is also an
authoritative dictionary of reference (another description from the same
site).  Being one does not preclude the other.  You said you failed to
regard the C standard as anything more that a guide.

> Perhaps there is something else that could be offending.  I don't
> really want to get into it, as it would be tangential to my current
> interest regarding dereferencing pointers to 'void'.

I agree.  I think arguments about tone are pointless.

>> >  Have I
>> > suggested that this "unpaid work of dozens of experts over more than
>> > two decades" is not a valuable resource?  If so, what would cause you
>> > to suggest that have implied/meant/stated that?
>>
>> Yes but it is probably unintentional.
>>
> No, I have not.  If you and certain other posters continue to inject
> negative implications, connotations, or anything else that can be
> perceived negatively to my statements just because you do not like
> what I have to say, the most I can do is to address it and apologize.
> Is it remotely possible that these "bad things" are being attached for
> some other reason?  I appreciate that you have recognized that "it is
> probably unintentional."  That's the absolute truth, so thanks for
> seeing it.

I won't comment on tone anymore.

<snip>
> The point is to avoid calling the draft for a standard of C with
> filename 'n1256.pdf' a "guide."  Fine.  Another word to add to my
> list.  Only identified with your kind feedback.

If you called is an "unsurpassed guide" I suspect some people would say you
are being too generous.  Calling it "no more than a guide" is another
matter.  I defined the word only because I suspected it was not quite
what you meant.  The word itself is not the problem.

>> >> Further more, neither of us is suggesting that "popular consensus" is
>> >> the main tool to be used when there is ambiguity.  That would be absurd.
>>
>> >> Do you see how that comes over?
>>
>> > Then I have misinterpreted and apologize.  What should be the main
>> > tool in case of ambiguity?
>>
>> Reasoning, logic, common sense.  All are better than popular consensus.
>> An example is to follow thought the consequences to the "pointer has
>> been assigned" sentence to see what it would mean.  Do the consequences
>> make sense?  Could there be another somewhat figurative interpretation
>> that seems to make more sense?  It won't always work but it beats
>> popular consensus any day!
>>
> I must have omitted that the path would be:
> 1. Read the material
> 2. Apply reasoning, logic, common sense
> 3. In case of ambiguity, find out how others interpret
>
> For me, 3 is not possible without 2.  Ambiguity cannot be determined
> without having applied these things.  Would you agree?

Yes, with the refinement that 1, 2 and 3 iterate.  The effect is a
careful consideration of the arguments and reasoning of others.  This is
very different to what I take the phrase "popular consensus" to mean.
For example, I'd bet that the popular consensus amongst C programmers is
that

  int two_d_array[10][10];
  two_d_array[0][20] = 42;

is well-defined, but it's hard to find well-reasoned arguments from C
experts to support that view.

<snip>
[We see to agree about constant expressions and null pointer constants]

>> >  If everyone knows or at least is adamant that "you can't
>> > dereference a null pointer," could this constraint hurt the standard
>> > for C?
>>
>> You mean, should it be added explicitly?  It think is, very nearly, in
>> the section you just cited (6.3.2.3 p3).  If you combine this with the
>> meaning of == between pointers you find that a null pointer can't point
>> at an object (not can it can't to a function) so * of it is undefined.
>>
> Yes, I did mean that I believe it should be added explicitly.  The
> additional constraint results in an implementation being capable of
> diagnosing it at translation-time.  That is valuable.  Undefined
> behaviour by the last sentence is during evaluation.  Consider
> 'sizeof'.

I think I now understand what you are proposing but I had to go back and
forth though the thread finding this spot in each message to see what
I'd said and what you'd then replied.  I now don't have the energy say
much more than if you want a constraint against * being applied to a
null pointer constant, go for it.  I don't mind one way or the other.
The effort in proposing a change to the standard calls seems to demand a
more significant benefit, but I won't be doing it.

<snip>
-- 
Ben.

On Jul 25, 7:19=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> > What I have attempted to suggest over and over again is that it should
> > be simply another form of void expression. =A0We have two already, why
> > not three? =A0Please consider:
>
> > static int i =3D 15;
>
> > void *func(void) {
> > =A0 i++;
> > =A0 return &i;
> > }
>
> > int main(void) {
> > =A0 *func();
> > =A0 return 0;
> > }
>
> > Compare 'main()' to this one:
>
> > int main(void) {
> > =A0 (void)func();
> > =A0 return 0;
> > }
>
> > My personal aesthetic would be for the former, rather than the
> > latter.
>
> Mine is for a third:
>
> =A0 func();
>
> Your suggestion seems to have very little utility.
>
Ok.

> > =A0I have suggested that the unary '*' operator defines the
> > result of '*func()' above to have type 'void'. =A0Since this is known t=
o
> > be a void expression (at translation time), and void expressions are
> > evaluated for their side effects, what is the problem here? =A0In this
> > context, the unary '*' would simply mean "throw away the returned
> > 'void *'". =A0To me, that would be useful, not useless.
>
> You do know it's undefined, yes? =A0The problem is suggesting a change to
> a language standard with so little benefit. =A0I see from later text that
> you don't agree that it's undefined. =A0If the current language permitted
> it, there would be no problem. =A0I'd still advice people to chose my
> simpler function call but you would free to use *func() all you want.
>
Ok.

> <void>
>
> >> Since void is not an object type, applying * to an expression of type
> >> void * is counter-intuitive and goes against the main point of the
> >> operator. =A0C chooses to make it undefined.
>
> > Ok, but what about the referenced draft? =A0It appears to be well-
> > defined there as a void expression.
>
> Well, I think not. =A0void is an incomplete type not an object type and a
> void * is therefore not a pointer to an object for the purposes of the *
> operator. =A0If it were, * would yield an lvalue of type void which
> directly contradicts 6.3.2.1 p1:
>
> =A0 An lvalue is an expression with an object type or an incomplete type
> =A0 other than void;
>
It's not a pointer to a function-type, either.  If it were, '*' would
yield a function designator with type 'void', which doesn't appear to
make sense, either.  Was there a reason you chose to treat 'void *' to
most closely resemble pointer-to-an-object-type versus pointer-to-a-
function-type, here?  I'm guessing that you figured it was more
obvious that 'void *' is not a pointer-to-a-function-type.  If I
recall correctly, ANSI C didn't even allow for a function pointer
value to be assigned to a 'void *'.  I could be misremembering.

>
> >>=A0Given
> >> E of type T *, *E does not do any conversion (see the common trick of
> >> "type-punning").
>
> > Agreed. =A0No conversion of a value. =A0However, if you consider taking=
 an
> > operand of one type and returning a result with another type, that
> > might be considered to be a conversion of type. =A0Would you agree?
>
> No. =A0Conversions have special rules in C. =A0To use the term for someth=
ing
> else would add confusion.
>
Ok.

> >> > =A0Thus if the
> >> > operand has type pointer-to-void, it suggests that the result has ty=
pe
> >> > 'void'.
>
> >> I'd say is true at some level, but since there is no defined result,
> >> it's type is not really relevant.
>
> > My reasoning goes:
> > 1. A type for the result is defined.
> > 2. That type is defined to be 'void'.
> > 3. Such a result is a void expression.
> > 4. By 1, 2, 3, it is defined to be a void expression.
>
> > Do you perceive a flaw in this reasoning for any of those points?
>
> Yes. =A0The type is not enough. =A0The pointer must be an object pointer =
not
> a pointer to an incomplete type.
>
Why have you omitted a function designator here, again?  Because it's
too obvious?

Also, why must the two "ifs" imply that the type of operand cannot be
'void *'?  Here's the text of 6.5.3.2,p4:

"The unary * operator denotes indirection. If the operand points to a
function, the result is
a function designator; if it points to an object, the result is an
lvalue designating the
object. If the operand has type =91=91pointer to type=92=92, the result has
type =91=91type=92=92. If an
invalid value has been assigned to the pointer, the behavior of the
unary * operator is
undefined."

Are you suggesting that according to the above, the lack of "...; if
it has type =91=91pointer to void=92=92, the result has no value and the
expression is a void expression..." is what would be needed for my
suggested interpretation to be valid; the omission of such thus
resulting in no definition for the behaviour?  I'm trying to pinpoint
why you consider this to not be a natural consequence of "If the
operand has type..." combined with "The (nonexistent) value of a void
expression (an expression that has type void)..." from 6.3.2.2,p1.

Should the constraint "The operand of the unary * operator shall have
pointer type." from 6.5.3.2,p2" be interpreted to mean "The operand of
the unary * operator shall have a pointer type suitable either for
pointing to an object or for pointing to a function." due to the
sentence "If the operand points to..." but _not_ due to the next
sentence "If the operand has type..."?

> > Compare to casting to 'void':
> > 1. A type for the result is defined.
> > 2. That type is defined to be 'void'.
> > 3. Such a result is a void expression.
> > 4. By 1, 2, 3, it is defined to be a void expression.
>
> > Essentially, does any other treatment not need to pull in that 'void
> > *' is not a valid type for an operand of unary '*' from somewhere?
> > Does any other treatment not need to suggest that the operand
> > _shall_only_ have type pointer-to-function-type or type pointer-to-
> > object-type?
>
> Undefined by omission. =A0That's way stronger than a suggestion. =A0If yo=
u
> don't accept it, just say and I'll shut up. =A0I have no interest in
> persuading you one way or the other.
>
Well, there's also the alternative to "shutting up" that is helping me
to understand your interpretation.  Even if I could never be persuaded
by some kind of stubbornness, it would still have value as an easily
accessible reference.  The choice is yours, clearly.

>
> >>=A0It's like saying the result of 1/0 is
> >> of type int. =A0Yes it in is some sense, but since it is undefined the
> >> type could be double[7]. =A0When it is not evaluated (and the UB is
> >> avoided) it does then have a type, but so does *(void *)E.
>
> > We are in agreement, here. =A0Also note that in:
>
> > int i =3D 15;
> > void *p =3D &i;
> > void *q;
> > q =3D p;
> > *p;
>
> > Evaluation of 'p' is defined, because we can assign it to 'q'. =A0So at
> > what point exactly during evaluation of the last line does the
> > undefined behaviour creep in?
>
> When the * is applied to something that is no an object pointer (or a
> function pointer).
>
That's what I've gathered as your meaning, from this post.  Thanks.

> > =A0If 'p' had an invalid value
> > (uninitialized, unassigned), surely that would be UB.
>
> >> Only if you accept that a result can be nothing but a type and if you
> >> reject the "undefined by omission" clause.
>
> > Does the result of casting to 'void' not have nothing but a type? =A0Is
> > not the result of calling a "function returning void" one with nothing
> > but a type? =A0I readily accept the "undefined by omission" clause. =A0=
But
> > is it not _included_? =A0"If the operand has type =91=91pointer to type=
=92=92,
> > the result has type =91=91type=92=92." 6.5.3.2,p4. =A0Are 'void' and 'v=
oid *'
> > not both types?
>
> You've lost me. =A0Yes they are both type. =A0Were the result defined, we=
'd
> know its type. =A0It's pointless knowing the type if the result is not
> defined.
>
"Cast operators", 6.5.4:

"...Constraints

2 Unless the type name specifies a void type, the type name shall
specify qualified or
unqualified scalar type and the operand shall have scalar type.

3 Conversions that involve pointers, other than where permitted by the
constraints of
6.5.16.1, shall be specified by means of an explicit cast.

Semantics

4 Preceding an expression by a parenthesized type name converts the
value of the
expression to the named type. This construction is called a cast.89) A
cast that specifies
no conversion has no effect on the type or value of an expression.

5 If the value of the expression is represented with greater precision
or range than required
by the type named by the cast (6.3.1.8), then the cast specifies a
conversion even if the
type of the expression is the same as the named type."

Where do we see a definition of the result of casting to 'void',
here?  Is it not omitted just the same as in the unary '*' operator?
Does that mean that casting to 'void' yields undefined behaviour?  I
should think not for the latter, as I'm positive you'd agree.

>
>=A0That was the point of the analogy:
>
> >>=A0Consider this:
>
> >> =A0 The best slogan will win a car! =A0The make of car will be the one
> >> =A0 your slogan refers to.
>
> >> What is the result of submitting the losing slogan "Fords are OK"?
>
> > The losing slogan is evaluated for its side effects (judges'
> > consideration) and the prize to the loser has no value and cannot be
> > used in any way. =A0Is that not so?
>
> There is a prize to the loser? =A0Not by my reading. =A0The result is
> undefined by omission in my book. =A0Knowing what type it _would_ be were
> the slogan to win makes no difference to the undefined nature of the
> result.
>
Ok.  I concede this.  A prize is not defined for the loser.  They have
what they had before the contest was judged, a Ford with an empty set
of physical components.  This is not quite the same as having a
prize.  So again to cast operators, where is the result of casting to
'void' defined?

> ... ... ... -- and I did not cut the code that is being discussed here.
>
> >> Some bugs (such as the above) would go undetected.
>
> > I think what you are suggesting here is that if we agree on well-
> > defined behaviour and treat it as a void expression, that a programmer
> > might not have intended it and will have a tough time finding it.
>
> "Tough time" is much more than I'd say. =A0You are proposing a relaxation
> of a current rule (from my point of view -- I know you don't agree
> with that view) so the space of valid programs grows a little, however
> small. =A0This is a cost -- a tiny one -- which might be worth it if ther=
e
> is a benefit.
>
Ok.

> > Suppose, for a moment, the a programmer had forgotten the type of
> > 'p' (thought it was 'int *') as well as the prefix increment
> > operator. =A0That might be a reasonably common error (it's two
> > keystrokes away from '*p;'). =A0Constraint 6.5.3.1,p1 catches it.
>
> > Another "two-keystroker" would be a function call with no arguments.
> > If the programmer tried this and the function did not have type
> > "function returning pointer-to-void", we should catch either a "result
> > unused" or an attempt to dereference something not a pointer, perhaps.
>
> > No problems, with those.
>
> I can't follow any of this.
>
Ok.

>
> >>=A0What is the gain
> >> that makes this loss acceptable? =A0In effect, this is my suggestion i=
n
> >> another form: what useful program needs to apply * to a void *?
>
> > static int i =3D 15;
>
> > void *func(void) {
> > =A0 i++;
> > =A0 return &i;
> > }
>
> > int main(void) {
> > =A0 int *j;
> > =A0 int k =3D 5;
> > =A0 j =3D func();
> > =A0 /* ... */
> > =A0 j =3D &k;
> > =A0 /*
> > =A0 =A0* We don't have a pointer to 'i' any more, but wish to increment
> > it.
> > =A0 =A0* We know that 'func()' does this, but we are using 'j' for 'k'
> > indirection.
> > =A0 =A0* Call 'func' and discard its result.
> > =A0 =A0*/
> > =A0 *func();
> > =A0 return 0;
> > }
>
> I'd call func();. =A0If you want to signal the discarded value,
> (void)func(); does that much more clearly. =A0I don't see any benefit to
> the *.
Ok.

Ben Bacarisse wrote:

<snip>

> For example, I'd bet that the popular consensus amongst C programmers is
> that
> 
>   int two_d_array[10][10];
>   two_d_array[0][20] = 42;
> 
> is well-defined, but it's hard to find well-reasoned arguments from C
> experts to support that view.

This is of course a well-chewed-over chestnut. My own view is that the 
behaviour of the code is theoretically undefined, *but* you'd be 
hard-pressed to find an implementation that did anything particularly 
surprising with it.

The reason I consider it to be undefined (which I'm sure I could make 
rigorous with references to the Standard, if only it weren't 3am) is as 
follows:

int two_d_array[10][10] has local scope (it must do, because the 
immediately following line is a statement, not a declaration, and 
statements at file scope are not allowed, so we must be inside a 
function). We can therefore unequivocally state that it is a definition 
(as opposed to a mere declaration). This isn't particularly relevant to 
the argument, but it does at least forestall arguments about terminology!

We can therefore say quite categorically that it *defines* an array of 
10 objects, each of which is an array. Each of these "sub-arrays" is an 
object in its own right, an array 10 elements wide.

two_d_array[0], therefore, describes an array of 10 ints. 
two_d_array[0][20] describes the 21st element in that array. Since the 
array has only ten elements, we have a problem.

We know that A[I] is equivalent to *(A + I). We know that we can 
legitimately form a pointer into any part of an object, *or* one past 
the end of an object. If we go further than that, we invoke UB. But 
two_d_array[0][20] is equivalent to *(two_d_array[0] + 20), which is 9 
past the end of the two_d_array[0] object - i.e. way more than one past 
the end. So the behaviour is quite definitely undefined.

Open and shut case, as they say.

BUT... we have to re-open the case on appeal, because we know that 
arrays are stored contiguously. We know that the two_d_array object is 
100 ints wide, and we know that two_d_array[0][20] is equivalent to 
*(two_d_array[0] + 20), which is equivalent to *(*(two_d_array + 0) + 
20), which is obviously well within the bounds of two_d_array.

So whether the behaviour is defined or undefined actually depends on 
which object the implementation thinks you're pointing into.

In practice, implementations are not going to add code to play 
bounds-cop on you when you are clearly well within program-owned memory. 
My own view, therefore, is that the behaviour is undefined in theory but 
well-defined in practice. In theory, theory and practice should be the 
same, but in practice we know that they aren't.

<snip>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

Richard Heathfield <rjh@see.sig.invalid> writes:

> Ben Bacarisse wrote:
>
> <snip>
>
>> For example, I'd bet that the popular consensus amongst C programmers is
>> that
>>
>>   int two_d_array[10][10];
>>   two_d_array[0][20] = 42;
>>
>> is well-defined, but it's hard to find well-reasoned arguments from C
>> experts to support that view.
>
> This is of course a well-chewed-over chestnut. My own view is that the
> behaviour of the code is theoretically undefined, *but* you'd be
> hard-pressed to find an implementation that did anything particularly
> surprising with it.

Yes.  I have a sort of internal scale of undefined behaviour and this is
over on the "not scary" end of the scale.  Close, but not quite so safe,
is running off front of an array.  At the other end is using a freed
pointer which is almost always disastrous.

However...

<snip>
> In practice, implementations are not going to add code to play
> bounds-cop on you when you are clearly well within program-owned
> memory. My own view, therefore, is that the behaviour is undefined in
> theory but well-defined in practice. In theory, theory and practice
> should be the same, but in practice we know that they aren't.

The real worry for me is that a compiler will use the UB to come to some
conclusion that I, as the programmer, disagree with.  It would be within
it's rights to conclude that 

   two_d_array[0][20] = 42;

does not change two_d_array[2][0] and so the register copy will do.  I
would not be 100% sure than nothing like that could happen.  For that
reason alone I consider it undefined in practice as well as in theory.

-- 
Ben.

On Jul 25, 9:02=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Shao Miller <sha0.mil...@gmail.com> writes:
> > On Jul 25, 1:30=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> >> That suggests that you agree that type is not part of the result -- th=
at
> >> it is a static property of the expression form (roughly speaking, a
> >> compile-time property rather than a run-time one). =A0If so, then a
> >> type-only result (a run-time idea if ever there was one) in
> >> meaningless. =A0That is certainly how I read the intent of the standar=
d,
> >> but I think you have repeated the type-only result idea in later repli=
es.
>
> > As someone pointed out, the meaning of "result" not being set out
> > explicitly in the discussion might be hindering mutual understanding.
> > I personally consider the "result" of an expression in C to have both
> > static properties available at translation time as well as possibly
> > associated values during evaluation at execution time.
>
> > As far as I'm concerned, an expression is "what you wrote" and a
> > result is "what you get." =A0You "get" some things at translation-time
> > and possibly other things during evaluation at execution time.
>
> > Without considering "result" in this way, it is possible that we might
> > consider it to only have meaning during evaluation at execution time,
> > and requiring a value. =A0That is simply not the way I consider it. =A0=
If
> > you or others would rather that I did, I shall do so for the purposes
> > of common meaning during discussion. =A0In that case, I'd have to resor=
t
> > to using "expression" only. =A0I would be reluctant to do so since
> > 'sizeof' would have trouble determining the type of the expression
> > '*(char *)c', since the text only defines the type for results.
>
> That does not clear up the question of whether, in your opinion, a
> result can be defined because the type is defined (and nothing more).
> Obviously I'm a "no" on that and I don't think any more debate will be
> useful so a simple "yes" or "no" from you will be enough to end this
> topic.
>
Yes.  Apologies for not abiding by the request for nothing further,
but: In the case of casting to 'void', the result is well-defined
(empty set of values, since it's type 'void') and a type for the
expression before evaluation is not explicitly defined.  I'm going to
assume the latter to be ridiculous due to the extremely common usage
of casting to void not yielding UB.  Somewhere, we must infer the type
for the expression regardless of the result of evaluation, in order
for it to qualify as a void expression.

> >> Yes, that's confusing. =A0Forget for the moment that it is my contenti=
on
> >> that both are undefined. =A0Let's take your reading where defining the
> >> type alone is enough. =A0In the first case (const int *ip =3D 0; *ip) =
the
> >> final sentence about the pointer having been assigned an invalid value
> >> does not apply because there is no assignment. =A0In the second (int *=
ip;
> >> ip =3D 0; *ip) it would be explicitly undefined. =A0What is the purpos=
e of
> >> this distinction? =A0Could it be that the wording is wrong? =A0Maybe
> >> assignment has nothing to do with it and it is just the value of the
> >> pointer that matters?
>
> > Hence my posts where I have agreed to treatment of that text to mean
> > it as it has been offered by other posters, including yourself. =A0Keit=
h
> > pointed out that evaluation of a pointer yielded a value, and that
> > that value, not an lvalue, was the operand to '*'. =A0I think we all
> > agree with that. =A0I'm trying to drop discussion of the point.
>
> OK. =A0This whole thread will be wrapped up in no time!
>
That is a desirable outcome.

> ... ... ...
> If you called is an "unsurpassed guide" I suspect some people would say y=
ou
> are being too generous. =A0Calling it "no more than a guide" is another
> matter. =A0I defined the word only because I suspected it was not quite
> what you meant. =A0The word itself is not the problem.
>
Very well.

>
> >> >> Further more, neither of us is suggesting that "popular consensus" =
is
> >> >> the main tool to be used when there is ambiguity. =A0That would be =
absurd.
>
> >> >> Do you see how that comes over?
>
> >> > Then I have misinterpreted and apologize. =A0What should be the main
> >> > tool in case of ambiguity?
>
> >> Reasoning, logic, common sense. =A0All are better than popular consens=
us.
> >> An example is to follow thought the consequences to the "pointer has
> >> been assigned" sentence to see what it would mean. =A0Do the consequen=
ces
> >> make sense? =A0Could there be another somewhat figurative interpretati=
on
> >> that seems to make more sense? =A0It won't always work but it beats
> >> popular consensus any day!
>
> > I must have omitted that the path would be:
> > 1. Read the material
> > 2. Apply reasoning, logic, common sense
> > 3. In case of ambiguity, find out how others interpret
>
> > For me, 3 is not possible without 2. =A0Ambiguity cannot be determined
> > without having applied these things. =A0Would you agree?
>
> Yes, with the refinement that 1, 2 and 3 iterate. =A0The effect is a
> careful consideration of the arguments and reasoning of others.
Agreed.

>
>=A0This is
> very different to what I take the phrase "popular consensus" to mean.
> For example, I'd bet that the popular consensus amongst C programmers is
> that
>
> =A0 int two_d_array[10][10];
> =A0 two_d_array[0][20] =3D 42;
>
> is well-defined, but it's hard to find well-reasoned arguments from C
> experts to support that view.
>
Aha.  My take would make good use of 6.5.2.1,p2:

"The definition of the subscript operator [] is that E1[E2] is
identical to (*((E1)+(E2)))."

So 'two_d_array[0][20]' becomes (ugh) '(*((*((two_d_array)+(0)))
+(20)))', evaluation of which proceeds as follows:
1. 'two_d_array' slides easily through its parentheses
'(*((*(two_d_array+(0)))+(20)))', 6.5.1,p6.
2. 'two_d_array' is not the operand to 'sizeof' nor '&', so it becomes
an expression having type pointer-to-int[20], pointing to the first
element, per 6.3.2.1,p3.  'sizeof two_d_array[0]' should confirm this.
3. '0' easily slides out of its parentheses.
4. We add '0' to the pointer result in step 2.  The declaration
provided an array object with 10 array-of-int objects.  The element
with offset 0 is within the bounds (+1) and we have a result with type
pointer-to-int[20]. '(*((*(result))+(20)))' per 6.5.6,p8.
5. The result of step 4 easily slides.  '(*((*result)+(20)))'
6. The unary '*' operator yields a result with type int[20].
'(*((result)+(20)))', per 6.5.3.2,p4.
7. The result from step 6 slides.  '(*(result+(20)))'
8. So does '20'.  '(*(result+20))'
9. The result of step 6 is not an operand to 'sizeof' or '&', has
array type, and is thus an expression having type pointer-to-int,
congruent with step 2's reference.
10. There is an 'int' object within the bounds of the array object at
offset 20, a pointer to this object is the result, congruent with step
4's reference.  '(*(result))'
11. The result of step 10 slides.  '(*result)'
12. The unary '*' operator yields a result having type 'int' and which
is an lvalue, congruent with the reference from step 6.  '(result)'
13. The result of step 12 slides.  It's still an lvalue.  'result'
14. The rest is assignment to that lvalue.
Where along here is there sometimes debate, if we can digress for at
least a moment? :)

>
> [We see to agree about constant expressions and null pointer constants]
>
Sure.

> >> > =A0If everyone knows or at least is adamant that "you can't
> >> > dereference a null pointer," could this constraint hurt the standard
> >> > for C?
>
> >> You mean, should it be added explicitly? =A0It think is, very nearly, =
in
> >> the section you just cited (6.3.2.3 p3). =A0If you combine this with t=
he
> >> meaning of =3D=3D between pointers you find that a null pointer can't =
point
> >> at an object (not can it can't to a function) so * of it is undefined.
>
> > Yes, I did mean that I believe it should be added explicitly. =A0The
> > additional constraint results in an implementation being capable of
> > diagnosing it at translation-time. =A0That is valuable. =A0Undefined
> > behaviour by the last sentence is during evaluation. =A0Consider
> > 'sizeof'.
>
> I think I now understand what you are proposing but I had to go back and
> forth though the thread finding this spot in each message to see what
> I'd said and what you'd then replied. =A0I now don't have the energy say
> much more than if you want a constraint against * being applied to a
> null pointer constant, go for it. =A0I don't mind one way or the other.
> The effort in proposing a change to the standard calls seems to demand a
> more significant benefit, but I won't be doing it.
>
I will keep in mind your comments regarding "snipping" and the
resulting energy it can waste for another poster.

Thanks, Ben!

Shao Miller <sha0.miller@gmail.com> writes:

> On Jul 25, 7:19 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
>> <void>
>>
>> >> Since void is not an object type, applying * to an expression of type
>> >> void * is counter-intuitive and goes against the main point of the
>> >> operator.  C chooses to make it undefined.
>>
>> > Ok, but what about the referenced draft?  It appears to be well-
>> > defined there as a void expression.
>>
>> Well, I think not.  void is an incomplete type not an object type and a
>> void * is therefore not a pointer to an object for the purposes of the *
>> operator.  If it were, * would yield an lvalue of type void which
>> directly contradicts 6.3.2.1 p1:
>>
>>   An lvalue is an expression with an object type or an incomplete type
>>   other than void;
>>
> It's not a pointer to a function-type, either.  If it were, '*' would
> yield a function designator with type 'void', which doesn't appear to
> make sense, either.  Was there a reason you chose to treat 'void *' to
> most closely resemble pointer-to-an-object-type versus pointer-to-a-
> function-type, here?  I'm guessing that you figured it was more
> obvious that 'void *' is not a pointer-to-a-function-type.

Yes.  I took it for granted that you did not think it might be a
function pointer.

<snip>
>> >> >  Thus if the
>> >> > operand has type pointer-to-void, it suggests that the result has type
>> >> > 'void'.
>>
>> >> I'd say is true at some level, but since there is no defined result,
>> >> it's type is not really relevant.
>>
>> > My reasoning goes:
>> > 1. A type for the result is defined.
>> > 2. That type is defined to be 'void'.
>> > 3. Such a result is a void expression.
>> > 4. By 1, 2, 3, it is defined to be a void expression.
>>
>> > Do you perceive a flaw in this reasoning for any of those points?
>>
>> Yes.  The type is not enough.  The pointer must be an object pointer not
>> a pointer to an incomplete type.
>>
> Why have you omitted a function designator here, again?  Because it's
> too obvious?

Yes.

> Also, why must the two "ifs" imply that the type of operand cannot be
> 'void *'?  Here's the text of 6.5.3.2,p4:
>
> "The unary * operator denotes indirection. If the operand points to a
> function, the result is a function designator; if it points to an
> object, the result is an lvalue designating the object. If the operand
> has type ‘‘pointer to type’’, the result has type ‘‘type’’. If an
> invalid value has been assigned to the pointer, the behavior of the
> unary * operator is undefined."
>
> Are you suggesting that according to the above, the lack of "...; if
> it has type ‘‘pointer to void’’, the result has no value and the
> expression is a void expression..." is what would be needed for my
> suggested interpretation to be valid; the omission of such thus
> resulting in no definition for the behaviour?  I'm trying to pinpoint
> why you consider this to not be a natural consequence of "If the
> operand has type..." combined with "The (nonexistent) value of a void
> expression (an expression that has type void)..." from 6.3.2.2,p1.

Let me try again.  All I am saying is that *(void *)E is undefined
because a void * is neither an object pointer nor a function pointer.
If one were unsure about this, both possibilities give rise to absurd
conclusions.  A void * can't be a function pointer for the rather silly
reason that void is not a function.  Some people might think it is an
object pointer, but that would mean * of it would be an lvalue in
contradiction of 6.3.2.1 p1.

There is no need to go this far: types are partitioned into three
groups: incomplete types, object types and function types, but some
people might be more persuaded by looking at the consequences of it
being either a function pointer or an object pointer.

> Should the constraint "The operand of the unary * operator shall have
> pointer type." from 6.5.3.2,p2" be interpreted to mean "The operand of
> the unary * operator shall have a pointer type suitable either for
> pointing to an object or for pointing to a function." due to the
> sentence "If the operand points to..." but _not_ due to the next
> sentence "If the operand has type..."?

I don't think there is any reason to interpret the constraint any more
narrowly than its literal meaning.

>> > Compare to casting to 'void':
>> > 1. A type for the result is defined.
>> > 2. That type is defined to be 'void'.
>> > 3. Such a result is a void expression.
>> > 4. By 1, 2, 3, it is defined to be a void expression.
>>
>> > Essentially, does any other treatment not need to pull in that 'void
>> > *' is not a valid type for an operand of unary '*' from somewhere?
>> > Does any other treatment not need to suggest that the operand
>> > _shall_only_ have type pointer-to-function-type or type pointer-to-
>> > object-type?
>>
>> Undefined by omission.  That's way stronger than a suggestion.  If you
>> don't accept it, just say and I'll shut up.  I have no interest in
>> persuading you one way or the other.
>>
> Well, there's also the alternative to "shutting up" that is helping me
> to understand your interpretation.

Of course, but I'm saying that I don't want to keep going round and
round and I can't see any way to make progress.  You don't even have to
say where you stand on this, I'm going to shut up about it one way or
the other.

<snip>
> "Cast operators", 6.5.4:
>
> "...Constraints
>
> 2 Unless the type name specifies a void type, the type name shall
> specify qualified or
> unqualified scalar type and the operand shall have scalar type.
>
> 3 Conversions that involve pointers, other than where permitted by the
> constraints of
> 6.5.16.1, shall be specified by means of an explicit cast.
>
> Semantics
>
> 4 Preceding an expression by a parenthesized type name converts the
> value of the
> expression to the named type. This construction is called a cast.89) A
> cast that specifies
> no conversion has no effect on the type or value of an expression.
>
> 5 If the value of the expression is represented with greater precision
> or range than required
> by the type named by the cast (6.3.1.8), then the cast specifies a
> conversion even if the
> type of the expression is the same as the named type."
>
> Where do we see a definition of the result of casting to 'void',
> here?  Is it not omitted just the same as in the unary '*' operator?
> Does that mean that casting to 'void' yields undefined behaviour?  I
> should think not for the latter, as I'm positive you'd agree.

That section does not define the result of any cast operator.  All it
says is that the cast performs a conversion.  There is a whole section
on conversions that gives the details.  Conversion to void is in
6.3.2.2.

>> That was the point of the analogy:
>>
>> >> Consider this:
>>
>> >>   The best slogan will win a car!  The make of car will be the one
>> >>   your slogan refers to.
>>
>> >> What is the result of submitting the losing slogan "Fords are OK"?
>>
>> > The losing slogan is evaluated for its side effects (judges'
>> > consideration) and the prize to the loser has no value and cannot be
>> > used in any way.  Is that not so?
>>
>> There is a prize to the loser?  Not by my reading.  The result is
>> undefined by omission in my book.  Knowing what type it _would_ be were
>> the slogan to win makes no difference to the undefined nature of the
>> result.
>>
> Ok.  I concede this.  A prize is not defined for the loser.  They have
> what they had before the contest was judged, a Ford with an empty set
> of physical components.  This is not quite the same as having a
> prize.

It seems we disagree about even this.  No matter; it was but an analogy
and they often fail to communicate the same thing to different people.

>  So again to cast operators, where is the result of casting to
> 'void' defined?

See above.

<snip>
-- 
Ben.

Shao Miller <sha0.miller@gmail.com> writes:

> On Jul 25, 9:02 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
<snip>
>> That does not clear up the question of whether, in your opinion, a
>> result can be defined because the type is defined (and nothing more).
>> Obviously I'm a "no" on that and I don't think any more debate will be
>> useful so a simple "yes" or "no" from you will be enough to end this
>> topic.
>>
> Yes.

Lets agree to differ then.

<snip>
>> This is
>> very different to what I take the phrase "popular consensus" to mean.
>> For example, I'd bet that the popular consensus amongst C programmers is
>> that
>>
>>   int two_d_array[10][10];
>>   two_d_array[0][20] = 42;
>>
>> is well-defined, but it's hard to find well-reasoned arguments from C
>> experts to support that view.
>>
> Aha.  My take would make good use of 6.5.2.1,p2:
>
> "The definition of the subscript operator [] is that E1[E2] is
> identical to (*((E1)+(E2)))."
>
> So 'two_d_array[0][20]' becomes (ugh) '(*((*((two_d_array)+(0)))
> +(20)))', evaluation of which proceeds as follows:
> 1. 'two_d_array' slides easily through its parentheses
> '(*((*(two_d_array+(0)))+(20)))', 6.5.1,p6.
> 2. 'two_d_array' is not the operand to 'sizeof' nor '&', so it becomes
> an expression having type pointer-to-int[20], pointing to the first
> element, per 6.3.2.1,p3.  'sizeof two_d_array[0]' should confirm this.
> 3. '0' easily slides out of its parentheses.
> 4. We add '0' to the pointer result in step 2.  The declaration
> provided an array object with 10 array-of-int objects.  The element
> with offset 0 is within the bounds (+1) and we have a result with type
> pointer-to-int[20]. '(*((*(result))+(20)))' per 6.5.6,p8.
> 5. The result of step 4 easily slides.  '(*((*result)+(20)))'
> 6. The unary '*' operator yields a result with type int[20].
> '(*((result)+(20)))', per 6.5.3.2,p4.
> 7. The result from step 6 slides.  '(*(result+(20)))'
> 8. So does '20'.  '(*(result+20))'
> 9. The result of step 6 is not an operand to 'sizeof' or '&', has
> array type, and is thus an expression having type pointer-to-int,
> congruent with step 2's reference.
> 10. There is an 'int' object within the bounds of the array object at
> offset 20, a pointer to this object is the result, congruent with step
> 4's reference.  '(*(result))'
> 11. The result of step 10 slides.  '(*result)'
> 12. The unary '*' operator yields a result having type 'int' and which
> is an lvalue, congruent with the reference from step 6.  '(result)'
> 13. The result of step 12 slides.  It's still an lvalue.  'result'
> 14. The rest is assignment to that lvalue.
> Where along here is there sometimes debate, if we can digress for at
> least a moment? :)

I don't think there is much debate.  If there is any, I think it is
about what array to use as the bounds.

I got lost in your explanation because you have phrases like "having
type pointer-to-int[20]" and "a result with type int[20]".  I'm not sure
what these mean.  The last is a C type but it does not occur in the
evaluation so I think you meant something else by it.

<snip>
-- 
Ben.

On Sun, 25 Jul 2010 11:43:00 -0700 (PDT), Shao Miller
<sha0.miller@gmail.com> wrote:

>On Jul 25, 10:59=A0am, c...@tiac.net (Richard Harter) wrote:
>>
>> Actually its pretty simple. =A0He's confused by the void/void*
>> hack.
>I disagree regarding confusion, but around the hack.
>
>>
>>=A0Experienced C programmers are so used to it that it that
>> they don't see it as a hack. =A0Simply:
>>
>> C has a whole bunch of primitive types, char, int, long, et al.
>> (It also has composite types, but let's not go there, okay.)
>> In addition there are pointer types. =A0The (almost) uniform rule
>> is dereferencing something of type T * yields something of type
>> T. =A0The exception, of course, is our friends, void and void *.
>> Despite appearances void * is not a pointer to a void.
>>
>I do not dispute that "void * is not a pointer to a void".  Does is
>not, however, have type "pointer-to-void"?  I believe that it does.
>That is not confusing.

I understand that you believe that it does.  None-the-less you
are confused.  The name of the type of void * can be considered
to be "pointer to void" since that is what the syntax indicates.
None-the-less something that has type void * is not a pointer to
void.  In the code

    void * p;

p is a pointer to a storage object of unspecified type.  That is,
the type of p is "pointer to a storage object of unspecified
type".  

The essence of the matter is that "void *" and "void" are
primitive types.  Despite the similarity in names they are
unrelated.
      

On Sun, 25 Jul 2010 11:43:00 -0700 (PDT), Shao Miller
<sha0.miller@gmail.com> wrote:

>On Jul 25, 10:59=A0am, c...@tiac.net (Richard Harter) wrote:

>>=A0When they were doing the
>> standard they had two issues they were trying to clear up. =A0One
>> was providing a way to say that a function returns nothing. =A0The
>> other was to provide generic pointers that would be automatically
>> converted without casting.
>Just a guess: The third was allowing for an uninteresting result to be
>discarded.  Would you agree?

No.

>
>int func(void) {
>  return 5;
>}
>
>int main(void) {
>  (void)func();
>  return 0;
>}

In the line 
    (void)func();
the (void) is not required and does nothing.  The line could have
read:
    func();
and the result would have been the same - a value would be
returned and discarded.  Caveat: If your warning level is set
high enough the compiler might give you a warning about ignoring
a returned value.

On Jul 25, 11:46=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Shao Miller <sha0.mil...@gmail.com> writes:
> > On Jul 25, 9:02=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> <snip>
> >> That does not clear up the question of whether, in your opinion, a
> >> result can be defined because the type is defined (and nothing more).
> >> Obviously I'm a "no" on that and I don't think any more debate will be
> >> useful so a simple "yes" or "no" from you will be enough to end this
> >> topic.
>
> > Yes.
>
> Lets agree to differ then.
>
Very well.  Agreed.

>
> >>=A0This is
> >> very different to what I take the phrase "popular consensus" to mean.
> >> For example, I'd bet that the popular consensus amongst C programmers =
is
> >> that
>
> >> =A0 int two_d_array[10][10];
> >> =A0 two_d_array[0][20] =3D 42;
>
> >> is well-defined, but it's hard to find well-reasoned arguments from C
> >> experts to support that view.
>
> > Aha. =A0My take would make good use of 6.5.2.1,p2:
>
> > "The definition of the subscript operator [] is that E1[E2] is
> > identical to (*((E1)+(E2)))."
>
> > So 'two_d_array[0][20]' becomes (ugh) '(*((*((two_d_array)+(0)))
> > +(20)))', evaluation of which proceeds as follows:
> > 1. 'two_d_array' slides easily through its parentheses
> > '(*((*(two_d_array+(0)))+(20)))', 6.5.1,p6.
> > 2. 'two_d_array' is not the operand to 'sizeof' nor '&', so it becomes
> > an expression having type pointer-to-int[20], pointing to the first
> > element, per 6.3.2.1,p3. =A0'sizeof two_d_array[0]' should confirm this=
..
> > 3. '0' easily slides out of its parentheses.
> > 4. We add '0' to the pointer result in step 2. =A0The declaration
> > provided an array object with 10 array-of-int objects. =A0The element
> > with offset 0 is within the bounds (+1) and we have a result with type
> > pointer-to-int[20]. '(*((*(result))+(20)))' per 6.5.6,p8.
> > 5. The result of step 4 easily slides. =A0'(*((*result)+(20)))'
> > 6. The unary '*' operator yields a result with type int[20].
> > '(*((result)+(20)))', per 6.5.3.2,p4.
> > 7. The result from step 6 slides. =A0'(*(result+(20)))'
> > 8. So does '20'. =A0'(*(result+20))'
> > 9. The result of step 6 is not an operand to 'sizeof' or '&', has
> > array type, and is thus an expression having type pointer-to-int,
> > congruent with step 2's reference.
> > 10. There is an 'int' object within the bounds of the array object at
> > offset 20, a pointer to this object is the result, congruent with step
> > 4's reference. =A0'(*(result))'
> > 11. The result of step 10 slides. =A0'(*result)'
> > 12. The unary '*' operator yields a result having type 'int' and which
> > is an lvalue, congruent with the reference from step 6. =A0'(result)'
> > 13. The result of step 12 slides. =A0It's still an lvalue. =A0'result'
> > 14. The rest is assignment to that lvalue.
> > Where along here is there sometimes debate, if we can digress for at
> > least a moment? :)
>
> I don't think there is much debate. =A0If there is any, I think it is
> about what array to use as the bounds.
>
Ok.  My impression of 'two_d_array[0] + 20' would be that
'two_d_array[0]' should yield a result with type 'int *', with an
intermediary state as an 'int[10]'.  So adding 20 should try to move
to the 20th 'int' element in the entire array object.  I believe that
6.5.6,p2 excludes an aggregate type, such as an array type.

"For addition, either both operands shall have arithmetic type, or one
operand shall be a pointer to an object type and the other shall have
integer type."

So I don't think an 'int[10]' could be an operand, here.  I think the
case for trouble would be:

two_d_array + 20  /* Having an operand with a type going from 'int[10]
[10] to 'int(*)[10]' */

versus:

two_d_array[0] + 20  /* Having an operand with a type going from
'int[10] to 'int *' */

The array-to-pointer conversions come from 6.3.2.1,p3.  That's an
example of an implicit conversion.

"...an expression that has type =91=91array of type=92=92 is converted to a=
n
expression with type =91=91pointer to type=92=92..."

>
> I got lost in your explanation because you have phrases like "having
> type pointer-to-int[20]" and "a result with type int[20]". =A0I'm not sur=
e
> what these mean. =A0The last is a C type but it does not occur in the
> evaluation so I think you meant something else by it.
>
Well I apologize.  I mixed styles here.  "pointer-to-int[20]" meaning
"int(*)[20]" and "int[20]" meaning just that.  Unfortunately, it's
actually a typo.  I should have written '10' instead of '20' in both
places.

On Jul 25, 11:59=A0pm, c...@tiac.net (Richard Harter) wrote:
> On Sun, 25 Jul 2010 11:43:00 -0700 (PDT), Shao Miller
>
>
>
> <sha0.mil...@gmail.com> wrote:
> >On Jul 25, 10:59=3DA0am, c...@tiac.net (Richard Harter) wrote:
>
> >> Actually its pretty simple. =3DA0He's confused by the void/void*
> >> hack.
> >I disagree regarding confusion, but around the hack.
>
> >>=3DA0Experienced C programmers are so used to it that it that
> >> they don't see it as a hack. =3DA0Simply:
>
> >> C has a whole bunch of primitive types, char, int, long, et al.
> >> (It also has composite types, but let's not go there, okay.)
> >> In addition there are pointer types. =3DA0The (almost) uniform rule
> >> is dereferencing something of type T * yields something of type
> >> T. =3DA0The exception, of course, is our friends, void and void *.
> >> Despite appearances void * is not a pointer to a void.
>
> >I do not dispute that "void * is not a pointer to a void". =A0Does is
> >not, however, have type "pointer-to-void"? =A0I believe that it does.
> >That is not confusing.
>
> I understand that you believe that it does. =A0None-the-less you
> are confused. =A0The name of the type of void * can be considered
> to be "pointer to void" since that is what the syntax indicates.
>
Beyond syntax, as well as the use of "pointer to void" in 6.3.2.3,p1
and 6.5.3.4,p5 and 6.5.15,p6, etc.  This last even goes so far as to
detail a qualified version of 'void', which might confuse someone
until they read 6.7.3,p3.  That seems like there's a decent effort to
integrate 'void' as a type, though it also "comprises an empty set of
values", as per 6.2.5,p19.

>
> None-the-less something that has type void * is not a pointer to
> void. =A0In the code
>
> =A0 =A0 void * p;
>
> p is a pointer to a storage object of unspecified type. =A0That is,
> the type of p is "pointer to a storage object of unspecified
> type".
>
That is roughly the way in which I interpret it, due to the type
partitioning in 6.2.5,p1, where 'void' would be an incomplete type,
and 'void *' a pointer to such a type.

>
> The essence of the matter is that "void *" and "void" are
> primitive types. =A0Despite the similarity in names they are
> unrelated.
>
This is very persuasive.  I would find it difficult to drop the
literal interpretation of 6.5.3.2,p2 (a constraint with a "shall"
which does not restrict the operand to a pointer to any of function,
object, or incomplete type) as well as 6.5.3.2,p4 (which describes a
type for the result, based on the type of the operand, and using
quotes to surround these).

Are there further references that might help to drop this literal
interpretation?  I believe that there is a major question regarding
some implied suggestion that the expression of a unary '*' operator
and its operand must have one of: Function type, object type, else
undefined.  But not incomplete type, as in 'void'.

Would you agree that you believe that 6.5.3.2 implies that the
expression must have one of those two types, despite the further
sentence which appears to define the type, also?  Is it remotely
possible that this sentence (the third of p4) can define the type
independently of the previous sentence, or is that not possible?

On Jul 26, 12:06=A0am, c...@tiac.net (Richard Harter) wrote:
> On Sun, 25 Jul 2010 11:43:00 -0700 (PDT), Shao Miller
>
> <sha0.mil...@gmail.com> wrote:
> >On Jul 25, 10:59=3DA0am, c...@tiac.net (Richard Harter) wrote:
> >>=3DA0When they were doing the
> >> standard they had two issues they were trying to clear up. =3DA0One
> >> was providing a way to say that a function returns nothing. =3DA0The
> >> other was to provide generic pointers that would be automatically
> >> converted without casting.
> >Just a guess: The third was allowing for an uninteresting result to be
> >discarded. =A0Would you agree?
>
> No.
>
Where does this response come from?  Are you suggesting that casting
to 'void' was not an original issue but came later on?  If so, this
sounds like a good history lesson worth reading.  I will try to find
it, since I could only "guess," above.

>
> >int func(void) {
> > =A0return 5;
> >}
>
> >int main(void) {
> > =A0(void)func();
> > =A0return 0;
> >}
>
> In the line
> =A0 =A0 (void)func();
> the (void) is not required and does nothing. =A0The line could have
> read:
> =A0 =A0 func();
> and the result would have been the same - a value would be
> returned and discarded. =A0Caveat: If your warning level is set
> high enough the compiler might give you a warning about ignoring
> a returned value.
Right...  So I'd also guess that you don't share my aesthetic
preference for how we could discard a 'void *' result with a single
keystroke, given such warning levels and compilers, and iff we (and
implementations) _did_ agree to the allowance of dereferencing a 'void
*'.  I only really meant to suggest a usefulness similar to that of
casting to 'void'.  You have described one such situation where
warnings result from an implementation without casting to 'void'.

Shao Miller <sha0.miller@gmail.com> writes:

> On Jul 25, 11:46 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> Shao Miller <sha0.mil...@gmail.com> writes:
>> > On Jul 25, 9:02 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
<snip>
>> >> For example, I'd bet that the popular consensus amongst C programmers is
>> >> that
>>
>> >>   int two_d_array[10][10];
>> >>   two_d_array[0][20] = 42;
>>
>> >> is well-defined, but it's hard to find well-reasoned arguments from C
>> >> experts to support that view.
<snip>

Just as everything else was all wrapped up...

> Ok.  My impression of 'two_d_array[0] + 20' would be that
> 'two_d_array[0]' should yield a result with type 'int *', with an
> intermediary state as an 'int[10]'.  So adding 20 should try to move
> to the 20th 'int' element in the entire array object.  I believe that
> 6.5.6,p2 excludes an aggregate type, such as an array type.
>
> "For addition, either both operands shall have arithmetic type, or one
> operand shall be a pointer to an object type and the other shall have
> integer type."
>
> So I don't think an 'int[10]' could be an operand, here.

The + is never applied to an array type, no.  I don't see why that means
you think the + 20 is done in relation to the whole array.  It seems
more logical to me that it is done in relation to two_d_array[0] and
that therefore the result is undefined.

<snip>
-- 
Ben.

On Jul 26, 9:32=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Shao Miller <sha0.mil...@gmail.com> writes:
> > On Jul 25, 11:46=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >> Shao Miller <sha0.mil...@gmail.com> writes:
> >> > On Jul 25, 9:02=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> <snip>
> >> >> For example, I'd bet that the popular consensus amongst C programme=
rs is
> >> >> that
>
> >> >> =A0 int two_d_array[10][10];
> >> >> =A0 two_d_array[0][20] =3D 42;
>
> >> >> is well-defined, but it's hard to find well-reasoned arguments from=
 C
> >> >> experts to support that view.
>
> <snip>
>
> Just as everything else was all wrapped up...
>
Only between you and I.  I would worry that this response might be
accidentally misread as "there are no outstanding questions in the
thread."  I doubt that's at all what you meant, here.

> > Ok. =A0My impression of 'two_d_array[0] + 20' would be that
> > 'two_d_array[0]' should yield a result with type 'int *', with an
> > intermediary state as an 'int[10]'. =A0So adding 20 should try to move
> > to the 20th 'int' element in the entire array object. =A0I believe that
> > 6.5.6,p2 excludes an aggregate type, such as an array type.
>
> > "For addition, either both operands shall have arithmetic type, or one
> > operand shall be a pointer to an object type and the other shall have
> > integer type."
>
> > So I don't think an 'int[10]' could be an operand, here.
>
> The + is never applied to an array type, no. =A0I don't see why that mean=
s
> you think the + 20 is done in relation to the whole array. =A0It seems
> more logical to me that it is done in relation to two_d_array[0] and
> that therefore the result is undefined.
>
I cannot think of a way in which any evaluation of the second array
subscript operator does not demand evaluation of the first, before-
hand.  Can you?

'two_d_array[0]' has type 'int[10]'.  'sizeof two_d_array[0] / sizeof
(int)' will confirm.

'two_d_array[0]' thus has array type.  That means that for anything
other than 'sizeof' or '&', it becomes 'int *'.  That pointer points
to a valid object and so does incrementing that pointer by '20'.

Shao Miller <sha0.miller@gmail.com> writes:

> On Jul 26, 9:32 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> Shao Miller <sha0.mil...@gmail.com> writes:
<snip>
>> > Ok.  My impression of 'two_d_array[0] + 20' would be that
>> > 'two_d_array[0]' should yield a result with type 'int *', with an
>> > intermediary state as an 'int[10]'.  So adding 20 should try to move
>> > to the 20th 'int' element in the entire array object.  I believe that
>> > 6.5.6,p2 excludes an aggregate type, such as an array type.
>>
>> > "For addition, either both operands shall have arithmetic type, or one
>> > operand shall be a pointer to an object type and the other shall have
>> > integer type."
>>
>> > So I don't think an 'int[10]' could be an operand, here.
>>
>> The + is never applied to an array type, no.  I don't see why that means
>> you think the + 20 is done in relation to the whole array.  It seems
>> more logical to me that it is done in relation to two_d_array[0] and
>> that therefore the result is undefined.
<snip>
> 'two_d_array[0]' has type 'int[10]'.  'sizeof two_d_array[0] / sizeof
> (int)' will confirm.
>
> 'two_d_array[0]' thus has array type.  That means that for anything
> other than 'sizeof' or '&', it becomes 'int *'.  That pointer points
> to a valid object and so does incrementing that pointer by '20'.

Yes, I know that is your position.  There is no point in our repeating
the same things over and over.

-- 
Ben.

Shao Miller <sha0.miller@gmail.com> writes:

> [snip] How many times should a person read something before
> asking for others to help by sharing their interpretations and their
> reasoning for those interpretations?

Continue reading until the urge to post purely captious
rhetoric subsides.

On Jul 26, 11:16=A0am, Tim Rentsch <t...@alumni.caltech.edu> wrote:
> Shao Miller <sha0.mil...@gmail.com> writes:
> > [snip] How many times should a person read something before
> > asking for others to help by sharing their interpretations and their
> > reasoning for those interpretations?
>
> Continue reading until the urge to post purely captious
> rhetoric subsides.
I have to ask non-rhetorical questions like these because it is
intended to establish at least one of: an agreement or a disagreement.

Hey, if you don't think I'm trying to bring some ambiguities in the
draft with filename 'n1256.pdf' to attention, you'd be wrong.  I'm
trying to do it at the same time as looking for an interpretation by
another C pedant (see the first couple of lines of post) which could
convince me that one particular interpretation can be demonstrated to
be less valuable than another.  Why?  Because there is always that
possibility that one interpretation is less valuable than another.
Many response posts have suggested that interpretations I have offered
are less valuable than theirs, so at least we're all in agreement
about differences in the value of interpretations.

Think again about an implementor for C.  To target the highest
conformance possible, is a thorough study of a standard (or draft) of
C warranted or not?

You suggest that there is little significance in the discussion I've
presented.  That's your opinion and you're welcome to it, clearly.
What I don't understand is why you (and others) think that it's
important to express that opinion repeatedly.

You "snipped" my saying that I perceived a "gross ambiguity" in
'n1256.pdf'.  Why else would I even ask the seemingly silly question
about dereferencing a null pointer, then later about a 'void *'?
Because it's important to me that the perceived ambiguity has at least
one of:
1. The perception corrected, or
2. the ambiguity corrected

Because I enjoy C.

That I need to use "I" this much in posts means the focus is in the
wrong place.

On 2010-07-26, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Shao Miller <sha0.miller@gmail.com> writes:
>> 'two_d_array[0]' thus has array type.  That means that for anything
>> other than 'sizeof' or '&', it becomes 'int *'.  That pointer points
>> to a valid object and so does incrementing that pointer by '20'.

> Yes, I know that is your position.  There is no point in our repeating
> the same things over and over.

But since I haven't pointed it out yet:

Type is not all there is to a pointer.  There is also a question of what
object the pointer points into.  two_d_array[0] is an array[10], so when
it decays into a pointer, it decays into a pointer into that array of 10
objects.  An implementation is welcome to detect attempts to move outside
the boundaries of that array.

To put it another way:

	int two_d_array[10][10];

	/* should be fine, this is guaranteed to be true */
	assert((two_d_array[0] + 10) == &(two_d_array[1][0]));
	two_d_array[1][0] = 1; /* valid */
	two_d_array[0][10] = 1; /* undefined behavior */

Comparison between pointers does not compare their boundaries.  (The assert
is safe because you are allowed to calculate the address of the object one
past the end of an array.)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

cri@tiac.net (Richard Harter) writes:

> [snip] The name of the type of void * can be considered
> to be "pointer to void" since that is what the syntax indicates.
> None-the-less something that has type void * is not a pointer to
> void.  In the code
>
>     void * p;
>
> p is a pointer to a storage object of unspecified type.  That is,
> the type of p is "pointer to a storage object of unspecified
> type".  
>
> The essence of the matter is that "void *" and "void" are
> primitive types.  Despite the similarity in names they are
> unrelated.

As a way of looking at things I think this point of view is not
unreasonable.  However, it is at odds with how the Standard
itself describes the relationship between void and void* (which
is just the same as any other type and its derived pointer type).
It's not possible to access an object that has type void (and
even if it were doing so wouldn't do anything) but that doesn't
mean the notion of a void object is automatically nonsensical.
By analogy, if we have a pointer 'struct void_s *pvs;', where
'struct void_s' is never defined, there certainly can be pointers
to objects that are 'struct void_s' objects as far as the
compiler is concerned and as far as the code that uses them can
tell.  The situation with void and void* is different only in
that converting to (void) has a special meaning, and void* is
freely interconvertible with other pointer types (with the
obvious qualifiers [no pun intended] about const etc).  Array
types provide another example:

   typedef unsigned char UCA[];

The type UCA is very much like void, an incomplete type that will
never be completed, and also having the property that objects of
the type cannot be accessed directly but only through other kinds
of pointer type.  Despite that surely there can be objects of
type UCA.  Is it unreasonable to use similar reasoning with void?

On Jul 26, 12:24=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-07-26, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> > Shao Miller <sha0.mil...@gmail.com> writes:
> >> 'two_d_array[0]' thus has array type. =A0That means that for anything
> >> other than 'sizeof' or '&', it becomes 'int *'. =A0That pointer points
> >> to a valid object and so does incrementing that pointer by '20'.
> > Yes, I know that is your position. =A0There is no point in our repeatin=
g
> > the same things over and over.
>
> But since I haven't pointed it out yet:
>
> Type is not all there is to a pointer.
>
Agreed.

>
> There is also a question of what
> object the pointer points into.
>
Agreed.

>
>=A0two_d_array[0] is an array[10],
>
Agreed.  Taking as valid our declaration, the sub-expression
'two_d_array[0]' is an expression with the type "array of int with ten
elements."  Another useful notation in addition to Peter's could be
'int[10]'.  Section 6.7.6 of the C standard draft with filename
'n1256.pdf'.

>
> so when
> it decays into a pointer, it decays into a pointer into that array of 10
> objects.
>
Agreed...

It could possibly be confusing for a reader of the draft when
regarding "array type" versus "array object," if only "array" is
mentioned.  For example, 5.1.2.2.1,p2 "argv array", where "object" is
perhaps intended (there's no mention of 'argv' as a type).

Also, if only "an array object" is specified (as in 6.5.6,p8), it
might not be clear to a reader whether _any_ array object will do, or
if only _a_particular_ array object will do.

Unfortunately, 6.5.6,p8 results in a circular definition for "Array
subscripting", 6.5.2.1,p2, which defines the subscript operator in
terms including pointer arithmetic via the binary '+' operator, who
then defines pointer arithmetic in terms including the "difference of
the subscripts".  Oops.

For an object with "allocated" "storage duration" (6.2.4,p1), there
isn't even a "declared type" for an array object to work with, but
only the type of an lvalue used to access it (6.5,p6).  If we accept
"only _a_particular_ array object" above, it might be difficult to
accept any accesses to elements within an array object with allocated
storage, since:

The effective type is the type of the lvalue used to access the
object, in the case of an object with allocated storage.

>
>=A0An implementation is welcome to detect attempts to move outside
> the boundaries of that array.
>
Agreed.  Some bounds of arrays are known at translation-time and some
are not, also.

Furthermore, the decay Peter describes above looks like:

int[10] ---> int *

If an implementation attempts to keep track of the 'int *'-typed
result as "must point within an object with type 'int[10]'" instead of
discarding the bound, we can at least work around this by casting the
result to 'void *' or 'char *', then to 'int(*)[sizeof two_d_array /
sizeof two_d_array[0][0]]', then back to 'void *' or 'char *', then
back to an 'int *' like we started with.  The middle-measure should
discard any bound the implementation might have been attempting to
track.

>
> To put it another way:
>
> =A0 =A0 =A0 =A0 int two_d_array[10][10];
>
> =A0 =A0 =A0 =A0 /* should be fine, this is guaranteed to be true */
> =A0 =A0 =A0 =A0 assert((two_d_array[0] + 10) =3D=3D &(two_d_array[1][0]))=
;
> =A0 =A0 =A0 =A0 two_d_array[1][0] =3D 1; /* valid */
> =A0 =A0 =A0 =A0 two_d_array[0][10] =3D 1; /* undefined behavior */
>
Well at least there's a work-around (detailed above) for concerns of
UB, here.

>
> Comparison between pointers does not compare their boundaries. =A0(The as=
sert
> is safe because you are allowed to calculate the address of the object on=
e
> past the end of an array.)
>
I would suggest that implementations should attempt to work with the
knowledge of which locations are valid for which object types
('two_d_array' being declared for 100 contiguous 'int's), OR to drop
any tracked bound during the conversion of 'int[10]' to 'int *'.  Just
a suggestion.

In a four-dimensional array:

int fd[10][10][10][10];

'fd' (alone) is an expression with type 'int[10][10][10][10]', which
might become 'int(*)[10][10][10]'.
'fd[0]' (alone) is an expression with type 'int[10][10][10]', which
might become 'int(*)[10][10]'.
'fd[0][0]' (alone) is an expression with type 'int[10][10]', which
might become 'int(*)[10]'.
'fd[0][0][0]' (alone) is an expression with type 'int[10]', which
might become 'int *'.

On Jul 26, 10:52=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Shao Miller <sha0.mil...@gmail.com> writes:
> > On Jul 26, 9:32=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >> Shao Miller <sha0.mil...@gmail.com> writes:
> <snip>
> >> > Ok. =A0My impression of 'two_d_array[0] + 20' would be that
> >> > 'two_d_array[0]' should yield a result with type 'int *', with an
> >> > intermediary state as an 'int[10]'. =A0So adding 20 should try to mo=
ve
> >> > to the 20th 'int' element in the entire array object. =A0I believe t=
hat
> >> > 6.5.6,p2 excludes an aggregate type, such as an array type.
>
> >> > "For addition, either both operands shall have arithmetic type, or o=
ne
> >> > operand shall be a pointer to an object type and the other shall hav=
e
> >> > integer type."
>
> >> > So I don't think an 'int[10]' could be an operand, here.
>
> >> The + is never applied to an array type, no. =A0I don't see why that m=
eans
> >> you think the + 20 is done in relation to the whole array. =A0It seems
> >> more logical to me that it is done in relation to two_d_array[0] and
> >> that therefore the result is undefined.
> <snip>
> > 'two_d_array[0]' has type 'int[10]'. =A0'sizeof two_d_array[0] / sizeof
> > (int)' will confirm.
>
> > 'two_d_array[0]' thus has array type. =A0That means that for anything
> > other than 'sizeof' or '&', it becomes 'int *'. =A0That pointer points
> > to a valid object and so does incrementing that pointer by '20'.
>
> Yes, I know that is your position. =A0There is no point in our repeating
> the same things over and over.
Ben!  I think I see your point!  Is it roughly:

int main(void) {
  union {
    char bar[1];
    char baz[2];
  } foo;

  foo.baz[0] =3D 'z';
  foo.baz[1] =3D 'z';
  foo.bar[0] =3D 'r';
  return foo.bar[1];    /* Undefined behaviour */
}

?  That the implementation is free to reject/diagnose the 'return'
line above as out-of-bounds?

Thanks for bringing this one up; it's been neat to think about. :)

Just a summary of some of the valuable discussion from respondants.
"The wording" below usually means for either the C draft with filename
'n1256.pdf' or the C Standard.

In regards to '(void)*(char *)0;':


Richard Heathfield: {

- An implementation can handle "any way it likes"

- The expression in the expression statement is evaluated

- '*(char *)0' alone is undefined behaviour

- '*(char *)0' has the side effect of undefined behaviour

- Any evaluation with UB means UB regardless of use

- A null ponter is not a valid operand for unary '*', hence UB

- Experience and knowledge accumulated towards C is valuable

- Operators yield values during evaluation

- Membership during one's lifetime on the committee responsible for
the C Standard does not guarantee correctness of one's detail about C,
but is likely

}


Keith Thompson: {

- '(void)42' is well-defined

- The wording for unary '*' needs to be improved

- The intent is unambiguous

- The "has been assigned" wording only makes sense for a pointer
object as the operand

- In the wording, "pointer" is used to mean one or both of "pointer
value" and "pointer object"

- Likely a small mistake by the author of "has been assigned"

- The intent of "has been assigned" is to define undefined behaviour
for an invalid pointer value [regardless of any assignment]

- If the wording meant the case of an lvalue having been assigned an
invalid value, it could have been worded more clearly for that

- A result has a value, as well as a type

- The result of unary '*(char *)0' has no defined value

- A value cannot be assigned to the pointer operand of unary '*'
unless it's a pointer object

- The operand of unary '*' is not a pointer object [lvalue]

- The "has been assigned" wording was simply a mistaken assumption

- Expressions are not precisely defined by the wording.  Keith
provides examples.  Keith suggests that the definition for expressions
should refer to the syntax

}


Tim Rentsch: {

- It is undefined behaviour

- '*(struct foo*)0' is undefined behaviour for the same reason

- The draft's wording about the matter might be imprecise

- '*(char *)0' is undefined if evaluated

- The wording could be better but should not be interpreted the way
one might interpret a math textbook

- The pointer operand for unary '*' is never assigned, since it's a
value and not an lvalue.  (I might have misremembered who brought this
up first during discussion.  Sorry, Tim.)

- The wording for "has been assigned" thus cannot be taken literally

- Reading the Standard carefully and considering what it entails for
the abstract machine can answer questions about subjects like
'(void)*(char *)0;'

- Objections raised towards the C Standard can be considered captious

}


Christian Bau: {

- '*(char *)0' is well-defined to yield and lvalue

- When that lvalue becomes an rvalue, we get undefined behaviour

- C++ differs

- Don't do it if in doubt

- A compiler might attempt to read '(char *)0'

}


Daniel "Stargazer": {

- The location '0' might not be valid for an object of any type

- A null pointer is guaranteed not to point to an object

- Dereferencing a null pointer yields undefined behaviour

}


Ben Bacarisse: {

- '*(char *)0' is well-defined for use with '&'

- '*(char *)0' is well-defined for use with 'sizeof'

- The wording might allow an implementation to define the behaviour;
to optimize side-effect-free expressions

- [Something about] '*(char *)0' is undefined

- The wording omits definition of the case where the operand for unary
'*' does not point to an object [or function], so [evaluation of] the
result is undefined behaviour

- The wording about "has been assigned" is clumsy

- '*E' is only defined when 'E' points to an object or a function

- A null pointer point to neither an object nor a function

- The sentence in the wording for unary '*' about "If...the result is
a function designator; if...the result is an lvalue..." are the only
definitions for the result

- The sentence in the wording for unary '*' about "If the operand has
type..." is the only definition for the type [of the result, I assume]

- These two sentences are two separate attributes for the expression,
not three ["if object, if function, if type"]

- The type for an expression is defined in parts of the wording where
the result is not defined

- Knowing the type does not guarantee defined behaviour

- The '<<' and '>>' operators are an example of defined type but a
possibly undefined result/behaviour

- Failure to define behaviour in the wording means undefined behaviour

- Even knowing the type does not mean that the expression has a
defined result

- The result of '*p' is the entire object [when the operand is a
pointer to a type suitable for an object, presumably]

- A compiler needn't fetch anything from an object designated by '*p',
but might only fetch what is needed (maybe only a member)

- Because it's an expression, '*(char *)0' must either generate side-
effects, designate an object or a function, or specify the computation
of a value.  Since it does none of those, it's undefined behaviour for
evaluation

- We know the type for '*(char *)0' is 'char', but we don't know which
'char', so it's undefined

- When the pointer operand for unary '*' points to neither a function
nor an object, there is no defined behaviour

- Every expression does not require a value.  Ben provides an example
of casting to 'void'

- The wording should not be interpreted the way one might interpret a
math textbook.  Common sense is required while reading

- The wording does not define "result" on its own, but is by most
people some notion of a quantity with a type

- A constraint for the unary '*' operator to point to either an object
or to a function is not possible

- There are three attributes of a an expression and its [evaluated]
result: The quantity [value], the type, and whether it's an lvalue

- The type and lvalue-ness can be determined by syntax alone.  [They
are translation-time determinable]

- The value is a run-time property

- The word "result" clouds the distinction between these three
attributes

- Revising the C Standard to make these distinctions would be a huge
challenge

- The "has been assigned..." wording for unary '*' should be
interpreted to mean an invalid pointer value

- The C Standard is more than a guide

- A "shall not be a null pointer constant..." constraint is not
possible for unary '*' since it is not determinable at compile time

- Type-only results are not mentioned [in the wording]

- There are interesting cases where the wording fails to give an
answer to give an answer to a question about C

}


Richard Harter: {

- '*(char *)0' has a defined type

- Evaluation of '*(char *)0' is undefined

}


Peter "Seebs" Seebach: {

- '(char *)0' is a pointer that doesn't point to an object, so '*(char
*)0' is undefined behaviour for evaluation, regardless of use in a
cast, or of the value

- The wording might be poorly-phrased, but the intention is clear

- Failure to define behaviour in the wording means undefined behaviour

- '(char *)0' points to an object type

- "Has been assigned to" could be considered as being clumsy wording,
but obviously includes pointer values regardless of assignment

- The wording for unary '*' about "If...the result is a function
designator; if...the result is an lvalue..." could be considered the
sum total of definitions.  No definition for the null pointer case
means undefined behaviour.

- The wording for unary '*' regarding "If the operand has type..."
could be considered to define '*(char *)0' to have an lvalue result,
but lack of designating an object would yield undefined behaviour

- Dereferencing null pointers yields undefined behaviour

- The Standard is clear on the matter

- The wording does not define behaviour for when the operand for unary
'*' does not point to an object [or function]

- The wording could doubtlessly be improved is can be asserted
confidently as being poor, but is not ambiguous and the meaning is
clear

- Only knowing the type of the result (and nothing else) means an
undefined result

- Implementation consistency makes the meaning of the wording for
unary '*' obvious

- 30 years of experience and knowledge accumulation makes the wording
for unary '*' obvious

- Committee membership during one's lifetime on the committee
rsponsible for the C Standard makes the wording obvious

- The committee responsible for the C Standard has always agreed that
dereferencing a null pointer is undefined behaviour

- An invalid pointer not pointing to an object [or function] causes
the undefined behaviour when an operand for unary '*'

- The wording is consistent about invalid pointers meaning pointers
not pointing to an object [or function]

- The Standard of C is the total definition for defined behaviour

- Value and type are two different things.  We might even know the
value [of something] and not its type

- '(char *)' is a pointer to an object type

- 'sizeof' is magical because it uses a type but not a value.  It
doesn't evaluate its operand's expression

}


Morris Keesan: {

- If evaluation of '*(char *)0' is undefined, so are any side-effects

}


Rich Webb: {

- Implementations might choose to define behaviour for evaluation of
'*(char *)0' or '*(void *)0'

- '*(char *)0' and '*(void *)0' are constraint violations

}


pete: {

- The C Standard only mentions values for expressions with an object
type

}



Concerning '*(void *)0':


Peter "Seebs" Seebach: {

- '*(void *)0' is a constraint violation

}


Richard Heathfield: {

- 'void *' cannot be dereferenced

- The C Standard does not define dereferencing a 'void *'

- The C Standard does define casting to 'void'

- Richard discusses an interesting example of C code which is disputed
to be either well-behaved or undefined behaviour

}


Richard Harter: {

- 'void' and 'void *' are hacks, developed during standardization of C
to deal with generic pointers and functions returning nothing

- Dereferencing is almost universally that something of type 'T *' [as
an operand] yields something of type 'T'

- A 'void *' is a pointer to a storage object of unspecified type

- 'void' and 'void *' are unrelated

- Casting to 'void' was not the solution to any issue of discarding an
uninteresting result during development of the C Standard

- It is easier to call a function and discard its result than to
explicitly discard the result [using additional code]

- Compilers might warn about implicitly discarding a function call's
result

}


Ben Bacarisse: {

- Evaluating an expression and throwing away the result is commonly
done

- Dereferencing a pointer to get nothing is useless

- The purpose of dereferencing is to recover an object or function
designator

- 'void' is not an object [or function] type, so unary '*' application
is counter-intuitive and undefined

- A cast converts and a pointer dereference interprets

- Casting and dereferencing both have definitions for type

- Defining a result for evaluation of unary '*' with a 'void *'
operand would allow for bugs but might not yield any gain

- Type is a static property of an expression form (roughly compile-
time versus run-time)

- Reasoning, logic, and common sense are all better than popular
consensus, when considering a potential case of ambiguity [in the C
Standard/draft]

- There are formal defect reports for the C Standard/draft

- A null pointer can point to neither an object nor a function

- It's likely that an additional constraint for the unary '*' operator
to help to clarify it is unlikely to be added to the C standard/draft

- A constraint to prevent null pointer constants (or casts of such) is
not likely to help C programmers, since it's avoided by them anyway

- Allowing unary '*' to yield a void expression has a value for C that
cannot be used

- Discarding a 'void *' result from a function call is easier to
accomplish by simply calling the function versus dereferencing that
'void *' to accomplish a void expression [were that "defined," which
is disputed]

- That unary '*' defines the type of result as 'void' upon a 'void *'
operand is insufficient to produce a void expression

- Conversions should be discussed for values only; such would be
confusing for discussion of types

- The result of application of unary '*' to anything other than a
function pointer [type] or an object pointer [type] is undefined

- It is pointless to know the type of a result if the result is not
defined

- Allowing to dereference a 'void *' would constitute a relaxation of
a current rule, which allows for currently invalid programs to become
valid.  There appears to be little benefit for such an allowance

- Ben provides an interesting example of C code which is disputed as
being well-defined or undefined behaviour

- Types are partitioned into three groups: Incomplete, object, and
function

- Casts specify conversions, but the wording for the cast operator
does not define a result.  The section about conversions define the
results

}


Tim Rentsch: {

- Comparing 'void' and 'void *' to other 'type' and 'type *'
relationships might be a reasonable from reading the wording

- Tim provides examples of types which either are not or cannot be
completed, but which pointer types for pointing-to can exist and be
used in C code

}



A thought that still sits with me is from 6.3.2.2:

"The (nonexistent) value of a void expression (an expression that has
type void) shall not be used in any way, and implicit or explicit
conversions (except to void) shall not be applied to such an
expression. If an expression of any other type is evaluated as a void
expression, its value or designator is discarded. (A void expression
is evaluated for its side effects.)"

In retrospect, the majority of my questions and points seem to have
had this piece of the draft as their basis, didn't they?

Nobody agreed to a suggestion that if the type for an expression is
defined to be 'void', that expression is a 'void' expression by
definition, period; that ((no value) is defined) versus (no (value is
defined)).  That's fine, isn't it?

Nobody touched on any other form of void expression beyond a function
returning 'void', or a cast to 'void', until simply 'func();' was
mentioned, but it was not explicitly identified as a void expression
(6.8.3,p2).  That's fine, isn't it?

I find it most unfortunate that some of the discussion involved
misinterpreted "tone" and my use of English for perceived purposes of
offense in my posts, and that some of the discussion involved insults
or accusations of lesser intelligence or reasoning faculties.  That's
likely a risk in any Usenet group, however.  Life moves on, doesn't
it?

As for the valuable discussion above, now's as good a time as any to
pass on my most sincere thanks for the time and effort of those who
attempted to provide answers and clarification.

It was valuable of you all to do so, for what that's worth.  Learning
happened, didn't it?  Thankyouthankyouthankyouthankyouthankyou!

Please forgive any errors, omissions, and lack of context that might
be in the previous "summary" post.  Any such are unintentional.  The
context of the original posts should be considered the only authority
for interpretation of meaning of the "summary" points.  Thanks.

Shao Miller <sha0.miller@gmail.com> writes:
> On Jul 26, 10:52 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
<snip>
>> Yes, I know that is your position.  There is no point in our repeating
>> the same things over and over.
> Ben!  I think I see your point!  Is it roughly:
>
> int main(void) {
>   union {
>     char bar[1];
>     char baz[2];
>   } foo;
>
>   foo.baz[0] = 'z';
>   foo.baz[1] = 'z';
>   foo.bar[0] = 'r';
>   return foo.bar[1];    /* Undefined behaviour */
> }
>
> ?

No.  I see no connection to what I was saying about 2D arrays.

>  That the implementation is free to reject/diagnose the 'return'
> line above as out-of-bounds?

I can't see any permission to do that in the standard.

-- 
Ben.

On Jul 28, 10:54=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Shao Miller <sha0.mil...@gmail.com> writes:
> > On Jul 26, 10:52=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> <snip>
> >> Yes, I know that is your position. =A0There is no point in our repeati=
ng
> >> the same things over and over.
> > Ben! =A0I think I see your point! =A0Is it roughly:
>
> > int main(void) {
> > =A0 union {
> > =A0 =A0 char bar[1];
> > =A0 =A0 char baz[2];
> > =A0 } foo;
>
> > =A0 foo.baz[0] =3D 'z';
> > =A0 foo.baz[1] =3D 'z';
> > =A0 foo.bar[0] =3D 'r';
> > =A0 return foo.bar[1]; =A0 =A0/* Undefined behaviour */
> > }
>
> > ?
>
> No. =A0I see no connection to what I was saying about 2D arrays.
>
> > =A0That the implementation is free to reject/diagnose the 'return'
> > line above as out-of-bounds?
>
> I can't see any permission to do that in the standard.
>
> --
> Ben.

Ok, I misunderstood.  Thanks anyway, Ben!  It was still neat to think
about. :)

Shao Miller <sha0.miller@gmail.com> writes:

> Just a summary of some of the valuable discussion from respondants.

Why not summarise what you have concluded to be the standard's meaning,
rather than paraphrasing other people and taking their comments out of
context (which often makes the unintelligible)?

<snip>
-- 
Ben.

Shao Miller <sha0.miller@gmail.com> writes:

> Please forgive any errors, omissions, and lack of context that might
> be in the previous "summary" post.  Any such are unintentional.  The
> context of the original posts should be considered the only authority
> for interpretation of meaning of the "summary" points.  Thanks.

I agree, but why post it then?

-- 
Ben.

On Jul 28, 11:05=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Shao Miller <sha0.mil...@gmail.com> writes:
> > Just a summary of some of the valuable discussion from respondants.
>
> Why not summarise what you have concluded to be the standard's meaning,
> rather than paraphrasing other people and taking their comments out of
> context (which often makes the unintelligible)?
>
> <snip>
> --
> Ben.

Ok, perhaps I'll try that next time...  Unless you want one now, for
this subject.  Hopefully the summary does demonstrate how valuable the
discussion was, however.

On Jul 28, 11:06=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Shao Miller <sha0.mil...@gmail.com> writes:
> > Please forgive any errors, omissions, and lack of context that might
> > be in the previous "summary" post. =A0Any such are unintentional. =A0Th=
e
> > context of the original posts should be considered the only authority
> > for interpretation of meaning of the "summary" points. =A0Thanks.
>
> I agree, but why post it then?
>
> --
> Ben.

Because if I'd come across a thread like this when I first had these
questions, a summary post like that would give me a quick digest.  It
might answer the questions right away, or I might have to dig deeper
into the thread.  However it's important to be sensitive to
perceptions of misrepresentation, hence this "disclaimer" for those
who provided such good discussion.

On Jul 25, 3:29=A0am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-07-24, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> > The word "claim" is rather loaded.Peter/does/ have a wealth of
> > knowledge and experience. That doesn't mean he is necessarily right, bu=
t
> > it does mean that the probability of his being right is significantly
> > high. When I find myself disagreeing withPeter, it always gives me
> > pause for thought.
>
> Which, given who's saying it, I find quite flattering.
>
> I guess that word, again, strengthens my point: =A0If those remarks reall=
y
> aren't intended as offensive (and "claim" has the same sorts of connotati=
ons
> of dishonesty that "invented" does), then that implies a level of familia=
rity
> with English inconsistent with arguing with more fluent speakers when the=
y
> tell you that a given text is clear in its meaning.
>
> -s
> --
> Copyright 2010, all wrongs reversed. =A0PeterSeebach/ usenet-nos...@seebs=
..nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp=
://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

You kiss my ass
And I will kiss yours
Even if we're ignorant
Even if we're bores
This is an echo chamber
Far below the deep blue sea
We reinforce each others' ignorance
I love you and you love me.

On Wed, 28 Jul 2010 21:27:45 -0700 (PDT), spinoza1111
<spinoza1111@yahoo.com> wrote:

>On Jul 25, 3:29=A0am, Seebs <usenet-nos...@seebs.net> wrote:
[snip Seebishism]
[Snip Vogon Poetry]

Hey, Seebs, your stalker is back.

On 2010-07-29, Richard Harter <cri@tiac.net> wrote:
> Hey, Seebs, your stalker is back.

I think on principle I appreciate being alerted, but this does raise
a (sometimes C-related) question:

Is there any point to testing for an error condition without some idea
in mind of what you'd do about it if it occurred?

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs wrote:
<snip>

> 
> I think on principle I appreciate being alerted, but this does raise
> a (sometimes C-related) question:
> 
> Is there any point to testing for an error condition without some idea
> in mind of what you'd do about it if it occurred?

#include <stdio.h>

void report_error(const char *s)
{
   if(fprintf(stderr, "%s\n", s) < 0)
   {
     report_error("Can't write to stderr");
   }
}

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

Richard Heathfield <rjh@see.sig.invalid> writes:
> Seebs wrote:
> <snip>
>> 
>> I think on principle I appreciate being alerted, but this does raise
>> a (sometimes C-related) question:
>> 
>> Is there any point to testing for an error condition without some idea
>> in mind of what you'd do about it if it occurred?
>
> #include <stdio.h>
>
> void report_error(const char *s)
> {
>    if(fprintf(stderr, "%s\n", s) < 0)
>    {
>      report_error("Can't write to stderr");
>    }
> }

Clever trick.  If you can't write to stderr, a stack overflow is
likely to cause the OS to do something that will catch the user's
attention.

On the other hand, if the compiler optimizes tail-recursion ...

Hey, if writing to stderr fails, you could try writing to stdin;
the user is bound to notice when error messages start coming out
of the keyboard.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

In article <__mdnYamw8-m5dbRnZ2dnUVZ7q-dnZ2d@bt.com>,
Richard Heathfield  <rjh@see.sig.invalid> wrote:
> Shao Miller wrote:
> > On Jul 24, 6:42 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> The word "claim" is rather loaded. Peter /does/ have a wealth of
> >> knowledge and experience. That doesn't mean he is necessarily right, but
> >> it does mean that the probability of his being right is significantly
> >> high. When I find myself disagreeing with Peter, it always gives me
> >> pause for thought.
> >>
> > Is it possible that "claims" could be injected with additional meaning
> > by the reader but not by the writer?
> 
> Yes, of course, and there's nothing the writer can do about that. 


I would be inclined, in this situation, to try to explicitly defuse
the negative connotations of "claims" -- something like "he claims
to be an expert, and he may very well be one -- I don't know enough
to judge".  ?


> That's 
> why we have to be careful how we write, if we do not wish to be 
> misunderstood. (That applies to everyone, in all contexts, not just in 
> comp.lang.c, and it applies as much to me as it does to you or to anyone 
> else.)
> 
> 
> > If I don't fully know the whole
> > picture regarding everyone's status, can I reasonably say "has"
> > instead of "claims to have"?


I would not -- I would take the approach described above.  But this
sort-of-advice should probably be taken with a big block of salt,
because it does make for a rather wordy and pedantic style, maybe,
and while that's pretty appropriate for me, maybe not so much for
the OP.


> Status is as status does. People acquire "status" (if that's the right 
> word) in comp.lang.c by posting good, sound advice, by entering civilly 
> into technical discussions and demonstrating their knowledge of C in 
> those discussions. 

[ snip ]

> By reading the group regularly, as I say, you get to know who are the 
> people who actually know the language. As for how to deal with such 
> people, you could do worse than check out articles by "blmblm" (B L 
> Massingill, I think), who - although far from ignorant about C - would 
> perhaps not lay claim to deep expertise, but whose articles are 
> invariably polite and well-argued.


Good heavens.  Thanks for the kind words!  (That's mostly why
I'm replying here, and I *almost* didn't notice this post, since
I don't even try to read everything in this group.  I'm apt to
become curious, though, when a thread seems to be generating more
posts than one might expect from the subject line.)

And yes, "not ignorant, but not laying claim to deep expertise" is
pretty close to how I'd describe my knowledge of C.

The OP might however want to avoid my tendency to drift off-topic.
Just sayin'.  :-)?


> > In other words, I am a newcomer, here.
> > I don't know any of you.  It might be beneficial to my understanding
> > of C to get to know some of you. :)  But can I possibly know before-
> > hand what magic words will set people off, such as "invent" and
> > "claims"?
> 
> You can't, I suppose. But what you /can/ do is learn.


Agreed -- but really, it kind of surprises me that someone who
seems entirely fluent in English would not know that both of
these words can have negative connotations.  But there may be
some obvious explanation for that, one that's not occurring to me.

(Keeping a lot of quoted text here because it does seem relevant.)


> > Is it reasonable for me to simply take note of these words and avoid
> > them in the future?  Can I do so without feedback like yours,
> > Richard?  My answer would be "no."  And so I thank you.
> 
> It ain't so much the words as the way how you use them. It comes with 
> experience.
> 
> > 
> > And also you have provided some evidence for the claim; this is
> > recorded.  Would you have offered that evidence without my use of
> > "claims"?
> 
> Nope. No point in rebutting a non-existent statement.
> 
> 
> > Does that last question suggest that I used "claims"
> > intentionally towards that end?  I didn't.  It was meant as a simple
> > statement of fact.
> > 
> > "Claims" will be dropped from my vocabulary here now, surely.  Do you
> > happen to know of a nice list of words to avoid, like these ones?
> > That would be great. :)
> 
> It isn't so much a word-list as an exercise in objectivity. It can be 
> quite difficult to stand back from the text you write and see it as 
> others will see it. But it is a worthwhile exercise, nonetheless.
> 
> 
> -- 
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line vacant - apply within
> 

Quoting the signature too to comment that I do like the dmr quote!

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

On Jul 30, 11:03=A0am, blm...@myrealbox.com <blm...@myrealbox.com>
wrote:
> In article <__mdnYamw8-m5dbRnZ2dnUVZ7q-dn...@bt.com>,
> Richard Heathfield =A0<r...@see.sig.invalid> wrote:
>
> > Shao Miller wrote:
> > > Is it possible that "claims" could be injected with additional meanin=
g
> > > by the reader but not by the writer?
>
> > Yes, of course, and there's nothing the writer can do about that.
>
> I would be inclined, in this situation, to try to explicitly defuse
> the negative connotations of "claims" -- something like "he claims
> to be an expert, and he may very well be one -- I don't know enough
> to judge". =A0?
>
If a person receives an electric shock every time one reads "claims,"
that is sufficient reason to avoid using it around such a person.
Other such reasons and words are possible, and none of my business to
argue about, but to try to respect, instead.

An "insider's" perspective on the use of "claims to have" versus "has"
might very well perceive a negative connotation.  I did not, and thus
didn't intend it.  Consider an "outsider's" perspective which might
simply use "claims" as part of describing a logical reasoning
process.  Statements can make a claim, sound or unsound.  To use "has"
instead of "claims to have" is illogical.  Deeming a statement as a
claim does not imply the claim is false (negative connotations).  I
cannot help that three people perceive a negative connotation.  This
paragraph can try and succeed, or try and fail.

> > That's
> > why we have to be careful how we write, if we do not wish to be
> > misunderstood. (That applies to everyone, in all contexts, not just in
> > comp.lang.c, and it applies as much to me as it does to you or to anyon=
e
> > else.)
>
> > > If I don't fully know the whole
> > > picture regarding everyone's status, can I reasonably say "has"
> > > instead of "claims to have"?
>
> I would not -- I would take the approach described above. =A0But this
> sort-of-advice should probably be taken with a big block of salt,
> because it does make for a rather wordy and pedantic style, maybe,
> and while that's pretty appropriate for me, maybe not so much for
> the OP.
>
Agreed on "wordy and pedantic style."  Styles can be adapted, also.
Let's call it what it is, though: Being especially sensitive to a list
of trigger words with possible emotional associations for readers.  I
have failed to demonstrate such sensitivity, which warrants an
apology.  I'm sorry.  Perhaps we have cultural differences.  Please
forgive and be tolerant.  There is no objective implication of dispute
using "claims to have," so one cannot guarantee "loading" of a "word-
weapon" and ill intent.

> ... ... ...
> The OP might however want to avoid my tendency to drift off-topic.
> Just sayin'. =A0:-)?
>
It's difficult to avoid being drawn into personal back-and-forth,
despite determination.

> > > In other words, I am a newcomer, here.
> > > I don't know any of you. =A0It might be beneficial to my understandin=
g
> > > of C to get to know some of you. :) =A0But can I possibly know before=
-
> > > hand what magic words will set people off, such as "invent" and
> > > "claims"?
>
> > You can't, I suppose. But what you /can/ do is learn.
>
> Agreed -- but really, it kind of surprises me that someone who
> seems entirely fluent in English would not know that both of
> these words can have negative connotations. =A0But there may be
> some obvious explanation for that, one that's not occurring to me.
>
This implies that fluency in English is sufficient cause for awareness
of negative connotations for these words.  Connotations are cultural
and not universal to a language.  That is the cause for your surprise.

I daresay that connotations are also fuzzy without context.  There was
no personal attack happening, so use of "claims to have" need not
carry a negative connotation.  It is understandable that someone
perceiving a personal attack might also perceive a negative
connotation.  So in general: stop perceiving personal attacks where
there are none.  A history of personal attacks in Usenet might make
this challenging.

I took part of Richard's advice the day of his kind words and read a
good number of your posts.  Thanks, B.

In article <ee0d5533-2ac2-46fb-9be7-6c341904a66c@y11g2000yqm.googlegroups.com>,
Shao Miller  <sha0.miller@gmail.com> wrote:
> On Jul 30, 11:03 am, blm...@myrealbox.com <blm...@myrealbox.com>
> wrote:
> > In article <__mdnYamw8-m5dbRnZ2dnUVZ7q-dn...@bt.com>,
> > Richard Heathfield  <r...@see.sig.invalid> wrote:
> >
> > > Shao Miller wrote:
> > > > Is it possible that "claims" could be injected with additional meaning
> > > > by the reader but not by the writer?
> >
> > > Yes, of course, and there's nothing the writer can do about that.
> >
> > I would be inclined, in this situation, to try to explicitly defuse
> > the negative connotations of "claims" -- something like "he claims
> > to be an expert, and he may very well be one -- I don't know enough
> > to judge".  ?
> >
> If a person receives an electric shock every time one reads "claims,"
> that is sufficient reason to avoid using it around such a person.
> Other such reasons and words are possible, and none of my business to
> argue about, but to try to respect, instead.
> 
> An "insider's" perspective on the use of "claims to have" versus "has"
> might very well perceive a negative connotation.  I did not, and thus
> didn't intend it.  Consider an "outsider's" perspective which might
> simply use "claims" as part of describing a logical reasoning
> process.  Statements can make a claim, sound or unsound.  To use "has"
> instead of "claims to have" is illogical.  Deeming a statement as a
> claim does not imply the claim is false (negative connotations).  I
> cannot help that three people perceive a negative connotation.  This
> paragraph can try and succeed, or try and fail.

(I'm going to continue this off-topic discussion just a bit more,
with the excuse that maybe by doing so I'll reduce the odds of similar
kerfuffles in the future .... )

Sure, I understood why you said "claims to have" rather than "has" --
I do that myself when I don't really have any basis for knowing
about the truth of the claim.  But I'm aware that for some people
"claims to have" is not just a statement of fact, but one that casts
doubt on the claim.  So I try to make it clear that I'm not trying
to be insulting.  People [*] aren't always logical!  

[*] There could be exceptions.  I'm not sure I've ever met one, 
but with, what, over 6 billion people on the planet, who can say ... 

> > > That's
> > > why we have to be careful how we write, if we do not wish to be
> > > misunderstood. (That applies to everyone, in all contexts, not just in
> > > comp.lang.c, and it applies as much to me as it does to you or to anyone
> > > else.)
> >
> > > > If I don't fully know the whole
> > > > picture regarding everyone's status, can I reasonably say "has"
> > > > instead of "claims to have"?
> >
> > I would not -- I would take the approach described above.  But this
> > sort-of-advice should probably be taken with a big block of salt,
> > because it does make for a rather wordy and pedantic style, maybe,
> > and while that's pretty appropriate for me, maybe not so much for
> > the OP.
> >
> Agreed on "wordy and pedantic style."  

Careful, there, who are you calling "wordy and pedantic" ....  

Oh, maybe no one.  (And even if you were, it would be true of me,
though a "smile when you say that, pardner" [*] would be in order.)

[*] Possibly US-centric cultural reference to -- some movie from
long ago, I think.  The point is that it's easier to be laughed
*with* than laughed *at*.  If that doesn't make sense say so and
I'll try to clarify.

> Styles can be adapted, also.
> Let's call it what it is, though: Being especially sensitive to a list
> of trigger words with possible emotional associations for readers.  I
> have failed to demonstrate such sensitivity, which warrants an
> apology.  I'm sorry.  Perhaps we have cultural differences.  Please
> forgive and be tolerant.  There is no objective implication of dispute
> using "claims to have," so one cannot guarantee "loading" of a "word-
> weapon" and ill intent.

"Cultural differences" is a possibility.  I'm writing from the
US, which is where I grew up and currently reside.  I don't think
I'm much more provincial and US-centric than most people in this
country, but admittedly that's a low bar.

To me you're coming across as someone who considers only the logical
meaning of words and not their potential emotional impact on readers.
I suspect that this puts you in a small minority, though I could be
wrong about that.  I also suspect that "logical meaning only" people
are apt to be more readily found in technical fields than elsewhere.

> > ... ... ...
> > The OP might however want to avoid my tendency to drift off-topic.
> > Just sayin'.  :-)?
> >
> It's difficult to avoid being drawn into personal back-and-forth,
> despite determination.

Isn't it, though.

[ snip ]

> > Agreed -- but really, it kind of surprises me that someone who
> > seems entirely fluent in English would not know that both of
> > these words can have negative connotations.  But there may be
> > some obvious explanation for that, one that's not occurring to me.
> >
> This implies that fluency in English is sufficient cause for awareness
> of negative connotations for these words.  Connotations are cultural
> and not universal to a language.  That is the cause for your surprise.

Fair enough.  (I did think it might be something along those lines
but couldn't think how to express that thought politely enough.)

> I daresay that connotations are also fuzzy without context.  There was
> no personal attack happening, so use of "claims to have" need not
> carry a negative connotation.  It is understandable that someone
> perceiving a personal attack might also perceive a negative
> connotation.  So in general: stop perceiving personal attacks where
> there are none.  A history of personal attacks in Usenet might make
> this challenging.
> 
> I took part of Richard's advice the day of his kind words and read a
> good number of your posts.  Thanks, B.

If I've helped -- happy to do so.  You may have observed that on
some occasions (not in this discussion, but in others) I can be
too quick to take offense where none was intended.  It's one of
the hazards of a text-only medium, I think!

Indeed, this discussion is another example ....

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

On 2010-07-31, blmblm  myrealbox.com <blmblm@myrealbox.com> wrote:
> To me you're coming across as someone who considers only the logical
> meaning of words and not their potential emotional impact on readers.
> I suspect that this puts you in a small minority, though I could be
> wrong about that.  I also suspect that "logical meaning only" people
> are apt to be more readily found in technical fields than elsewhere.

This is not implausible.  Ironically, it took me years of study to
start picking up connotations.

>> This implies that fluency in English is sufficient cause for awareness
>> of negative connotations for these words.  Connotations are cultural
>> and not universal to a language.  That is the cause for your surprise.

> Fair enough.  (I did think it might be something along those lines
> but couldn't think how to express that thought politely enough.)

While it's true that connotations are often cultural, I am not aware
of any culture in which accusing someone of having invented something
when they cite to a text as showing it does not constitute an
accusation of dishonesty.  I have spoken with English-speakers from
many countries, and in this case, the connotation is not so much
cultural as a question of Gricean maxims.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On Jul 31, 4:13=A0pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <ee0d5533-2ac2-46fb-9be7-6c341904a...@y11g2000yqm.googlegroups=
..com>,
> Shao Miller =A0<sha0.mil...@gmail.com> wrote:
>
>
>
> > On Jul 30, 11:03 am, blm...@myrealbox.com <blm...@myrealbox.com>
> > wrote:
> > > In article <__mdnYamw8-m5dbRnZ2dnUVZ7q-dn...@bt.com>,
> > > Richard Heathfield =A0<r...@see.sig.invalid> wrote:
>
> > > > Shao Miller wrote:
> > > > > Is it possible that "claims" could be injected with additional me=
aning
> > > > > by the reader but not by the writer?
>
> > > > Yes, of course, and there's nothing the writer can do about that.
>
> > > I would be inclined, in this situation, to try to explicitly defuse
> > > the negative connotations of "claims" -- something like "he claims
> > > to be an expert, and he may very well be one -- I don't know enough
> > > to judge". =A0?
>
> > If a person receives an electric shock every time one reads "claims,"
> > that is sufficient reason to avoid using it around such a person.
> > Other such reasons and words are possible, and none of my business to
> > argue about, but to try to respect, instead.
>
> > An "insider's" perspective on the use of "claims to have" versus "has"
> > might very well perceive a negative connotation. =A0I did not, and thus
> > didn't intend it. =A0Consider an "outsider's" perspective which might
> > simply use "claims" as part of describing a logical reasoning
> > process. =A0Statements can make a claim, sound or unsound. =A0To use "h=
as"
> > instead of "claims to have" is illogical. =A0Deeming a statement as a
> > claim does not imply the claim is false (negative connotations). =A0I
> > cannot help that three people perceive a negative connotation. =A0This
> > paragraph can try and succeed, or try and fail.
>
> (I'm going to continue this off-topic discussion just a bit more,
> with the excuse that maybe by doing so I'll reduce the odds of similar
> kerfuffles in the future .... )
>
By all means, that's a worthy cause. :)

> Sure, I understood why you said "claims to have" rather than "has" --
> I do that myself when I don't really have any basis for knowing
> about the truth of the claim. =A0But I'm aware that for some people
> "claims to have" is not just a statement of fact, but one that casts
> doubt on the claim. =A0So I try to make it clear that I'm not trying
> to be insulting. =A0People [*] aren't always logical! =A0
>
> [*] There could be exceptions. =A0I'm not sure I've ever met one,
> but with, what, over 6 billion people on the planet, who can say ...
>
I agree.  I believe that people associating a claim of a claim with a
dispute for the latter claim will find their doubt-casting.  That can
be reconditioned just as avoidance of "bad words" can be
reconditioned.

>
> > > > That's
> > > > why we have to be careful how we write, if we do not wish to be
> > > > misunderstood. (That applies to everyone, in all contexts, not just=
 in
> > > > comp.lang.c, and it applies as much to me as it does to you or to a=
nyone
> > > > else.)
>
> > > > > If I don't fully know the whole
> > > > > picture regarding everyone's status, can I reasonably say "has"
> > > > > instead of "claims to have"?
>
> > > I would not -- I would take the approach described above. =A0But this
> > > sort-of-advice should probably be taken with a big block of salt,
> > > because it does make for a rather wordy and pedantic style, maybe,
> > > and while that's pretty appropriate for me, maybe not so much for
> > > the OP.
>
> > Agreed on "wordy and pedantic style." =A0
>
> Careful, there, who are you calling "wordy and pedantic" .... =A0
>
> Oh, maybe no one. =A0(And even if you were, it would be true of me,
> though a "smile when you say that, pardner" [*] would be in order.)
>
"Wordy and pedantic style" applies to _my_ posts _already_. :)  It
will _continue_ to apply as more emotional lighteners and/or
neutralizers are sprinkled in.

"...who are you calling..." is another example of a perceived
attack. :S  I have already requested that in general: stop perceiving
personal attacks where
there are none; even though a history of personal attacks in Usenet
might make this challenging. :S

> [*] Possibly US-centric cultural reference to -- some movie from
> long ago, I think. =A0The point is that it's easier to be laughed
> *with* than laughed *at*. =A0If that doesn't make sense say so and
> I'll try to clarify.
>
That cultural reference is familiar to me, outside of the U. S. A.
Agreed that the reference comes from that culture. :)

Nobody should be laughing when the subject is people's feelings being
hurt, in my opinion.  It's a very serious matter.  That is why there
aren't any smile tokens in that post.  A smile token might encourage
laughter.

> > Styles can be adapted, also.
> > Let's call it what it is, though: Being especially sensitive to a list
> > of trigger words with possible emotional associations for readers. =A0I
> > have failed to demonstrate such sensitivity, which warrants an
> > apology. =A0I'm sorry. =A0Perhaps we have cultural differences. =A0Plea=
se
> > forgive and be tolerant. =A0There is no objective implication of disput=
e
> > using "claims to have," so one cannot guarantee "loading" of a "word-
> > weapon" and ill intent.
>
> "Cultural differences" is a possibility. =A0I'm writing from the
> US, which is where I grew up and currently reside. =A0I don't think
> I'm much more provincial and US-centric than most people in this
> country, but admittedly that's a low bar.
>
> To me you're coming across as someone who considers only the logical
> meaning of words and not their potential emotional impact on readers.
> I suspect that this puts you in a small minority, though I could be
> wrong about that. =A0I also suspect that "logical meaning only" people
> are apt to be more readily found in technical fields than elsewhere.
>
Agreed on "more readily found."  And here is a clue as to why
attention to readers' emotional needs was not anticipated as requiring
more care than I am used to. :)

> > > ... ... ...
> > > The OP might however want to avoid my tendency to drift off-topic.
> > > Just sayin'. =A0:-)?
>
> > It's difficult to avoid being drawn into personal back-and-forth,
> > despite determination.
>
> Isn't it, though.
>
> [ snip ]
>
> > > Agreed -- but really, it kind of surprises me that someone who
> > > seems entirely fluent in English would not know that both of
> > > these words can have negative connotations. =A0But there may be
> > > some obvious explanation for that, one that's not occurring to me.
>
> > This implies that fluency in English is sufficient cause for awareness
> > of negative connotations for these words. =A0Connotations are cultural
> > and not universal to a language. =A0That is the cause for your surprise=
..
>
> Fair enough. =A0(I did think it might be something along those lines
> but couldn't think how to express that thought politely enough.)
>
Thanks for being polite. :)

> > I daresay that connotations are also fuzzy without context. =A0There wa=
s
> > no personal attack happening, so use of "claims to have" need not
> > carry a negative connotation. =A0It is understandable that someone
> > perceiving a personal attack might also perceive a negative
> > connotation. =A0So in general: stop perceiving personal attacks where
> > there are none. =A0A history of personal attacks in Usenet might make
> > this challenging.
>
> > I took part of Richard's advice the day of his kind words and read a
> > good number of your posts. =A0Thanks, B.
>
> If I've helped -- happy to do so. =A0You may have observed that on
> some occasions (not in this discussion, but in others) I can be
> too quick to take offense where none was intended. =A0It's one of
> the hazards of a text-only medium, I think!
>
It is.

> Indeed, this discussion is another example ....
It is.

On Jul 31, 5:53=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-07-31, blmblm =A0myrealbox.com <blm...@myrealbox.com> wrote:
>
> > To me you're coming across as someone who considers only the logical
> > meaning of words and not their potential emotional impact on readers.
> > I suspect that this puts you in a small minority, though I could be
> > wrong about that. =A0I also suspect that "logical meaning only" people
> > are apt to be more readily found in technical fields than elsewhere.
>
> This is not implausible. =A0Ironically, it took me years of study to
> start picking up connotations.
>
Thank for your acknowledging that fluency in English is not sufficient
cause for awareness of the negative connotations you perceive.  I
agree.

> >> This implies that fluency in English is sufficient cause for awareness
> >> of negative connotations for these words. =A0Connotations are cultural
> >> and not universal to a language. =A0That is the cause for your surpris=
e.
> > Fair enough. =A0(I did think it might be something along those lines
> > but couldn't think how to express that thought politely enough.)
>
> While it's true that connotations are often cultural, I am not aware
> of any culture in which accusing someone of having invented something
> when they cite to a text as showing it does not constitute an
> accusation of dishonesty. =A0I have spoken with English-speakers from
> many countries, and in this case, the connotation is not so much
> cultural as a question of Gricean maxims.
It's not an accusation.  It's a claim that there is no supporting
reference to the text given.  You can demonstrate otherwise.  You can
choose to ignore (ie. "plonk").  Your knowledge that there _is_ text
to support your statements is not accessible to me.  If you do not
include the references, the knowledge cannot be accessed.  The
original post includes a great number of references.  That was my
expectation for responses.  That was my mistake.  "Highest levels of
pedantry" was a mistake to request.

These are my claims.  I offer no external references for them.  Thus,
they are also my inventions. :)

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Shao Miller <sha0.miller@gmail.com> writes:
> <snip>
>>> int main(void) {
>>>   static int foo = 15;
>>>   struct bar {
>>>     char c[(size_t)&foo];
>>>     int baz;
>>>   };
>>>   return (*(struct foo *)0).baz;
>>> }
>>
>> That's a constraint violation.  If your compiler does not complain about
>> it get another one!  The array size must be an integer constant
>> expression.
>
> Actually it is not a constraint violation but it certainly violates a
> "shall" about integer constant expressions (6.6 p6).  I am surprised
> this is not a CV since I can't see any reason it can't be checked at
> compile time, but it's not one.

My impression is that such things are deliberate omissions,
so that implemenations may accept them as "other forms of
constant expressions" under 6.6p10 without having to issue
a diagnostic.

Richard Heathfield <rjh@see.sig.invalid> writes:

> Ben Bacarisse wrote:
>
> <snip>
>
>> For example, I'd bet that the popular consensus amongst C programmers is
>> that
>>
>>   int two_d_array[10][10];
>>   two_d_array[0][20] = 42;
>>
>> is well-defined, but it's hard to find well-reasoned arguments from C
>> experts to support that view.
>
> This is of course a well-chewed-over chestnut. My own view is that the
> behaviour of the code is theoretically undefined, *but* you'd be
> hard-pressed to find an implementation that did anything particularly
> surprising with it.
>
> The reason I consider it to be undefined (which I'm sure I could make
> rigorous with references to the Standard, if only it weren't 3am) is
> as follows:
>
> int two_d_array[10][10] has local scope (it must do, because the
> immediately following line is a statement, not a declaration, and
> statements at file scope are not allowed, so we must be inside a
> function). We can therefore unequivocally state that it is a
> definition (as opposed to a mere declaration). This isn't particularly
> relevant to the argument, but it does at least forestall arguments
> about terminology!
>
> We can therefore say quite categorically that it *defines* an array of
> 10 objects, each of which is an array. Each of these "sub-arrays" is
> an object in its own right, an array 10 elements wide.
>
> two_d_array[0], therefore, describes an array of 10
> ints. two_d_array[0][20] describes the 21st element in that
> array. Since the array has only ten elements, we have a problem.
>
> We know that A[I] is equivalent to *(A + I). We know that we can
> legitimately form a pointer into any part of an object, *or* one past
> the end of an object. If we go further than that, we invoke UB. But
> two_d_array[0][20] is equivalent to *(two_d_array[0] + 20), which is 9
> past the end of the two_d_array[0] object - i.e. way more than one
> past the end. So the behaviour is quite definitely undefined.
>
> Open and shut case, as they say.
>
> BUT... we have to re-open the case on appeal, because we know that
> arrays are stored contiguously. We know that the two_d_array object is
> 100 ints wide, and we know that two_d_array[0][20] is equivalent to
> *(two_d_array[0] + 20), which is equivalent to *(*(two_d_array + 0) +
> 20), which is obviously well within the bounds of two_d_array.
>
> So whether the behaviour is defined or undefined actually depends on
> which object the implementation thinks you're pointing into.

The problem is that the Standard should define unambiguously what
that object is in each of the various different circumstances;
unfortunately, it doesn't.


> In practice, implementations are not going to add code to play
> bounds-cop on you when you are clearly well within program-owned
> memory. My own view, therefore, is that the behaviour is undefined in
> theory but well-defined in practice.  [snip]

I mostly agree, but intra-function or intra-translation-unit
alias analysis is an important exception.  These cases may
very well manifest unde{sir,fin}ed behavior upon such usage.

Shao Miller <sha0.miller@gmail.com> writes:

> Just a summary of some of the valuable discussion from respondants.
> [snip]
>
> Tim Rentsch: {  [snip]

was misquoted/misinterpreted.  Interested parties should
refer to the original postings.

On Aug 1, 9:06=A0am, Tim Rentsch <t...@alumni.caltech.edu> wrote:
> Shao Miller <sha0.mil...@gmail.com> writes:
> > Just a summary of some of the valuable discussion from respondants.
> > [snip]
>
> > Tim Rentsch: { =A0[snip]
>
> was misquoted/misinterpreted. =A0Interested parties should
> refer to the original postings.
Those aren't quotations, by any means.  They are a summary of valuable
points that were brought up.

If I misinterpreted, I apologize.  Sorry, Tim!

On Jul 29, 9:16=A0pm, c...@tiac.net (Richard Harter) wrote:
> On Wed, 28 Jul 2010 21:27:45 -0700 (PDT),spinoza1111
>
> <spinoza1...@yahoo.com> wrote:
> >On Jul 25, 3:29=3DA0am, Seebs <usenet-nos...@seebs.net> wrote:
>
> [snip Seebishism]
> [Snip Vogon Poetry]
>
> Hey, Seebs, your stalker is back.

I'm not a stalker. Seebach unleashed a cybernetic mob on Herb Schildt
a number of years ago in order to advance himself in a career for
which Seebach is just not qualified, and I examined Seebach's attack
to find it to be garbage. My article about this matter was accepted
for publication in the competently moderated and prestigious group
comp.risks. The moderator was then spammed by the sort of cybernetic
mob Seebach had marshaled against Schildt and printed an apology for
accepting my article, but then accepted a second article on an
unrelated topic (the California payroll system crisis).

The sort of half-literate creeps and stalkers indeed who dominate this
newsgroup aren't typically accepted for publication in decent circles,
although Richard Heathfield, Seebach et al. were accepted by Sams, a
rather Low Rent computer publisher that mistreats authors. This
triggers their destructive rage.

I've pretty much stopped programming at this time since I'm in a much
more humane profession and am also developing a painting online, and
documenting it at http://spinoza1111.wordpress.com. But I may return
at any time if some issue catches my interest.

You're all stalkers. Your programming craftsmanship is nil except in a
few cases such as Navia and Bacarisse, and even the latter is being
corrupted by the fact that it's a myth that corporations need
"excellent programmers". A corporation, as the BP oil spill makes
clear, exists solely to make money and to use your negative
capabilities (fear and hatred) to do so.

You sit in front of your work stations
Pretending to work for corporations
That pretend to give a fuck about you
And hatred you spew against all that is true
Like petroleum at the bottom of the sea.

On Jul 29, 11:58=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-07-29, Richard Harter <c...@tiac.net> wrote:
>
> > Hey, Seebs, your stalker is back.
>
> I think on principle I appreciate being alerted, but this does raise
> a (sometimes C-related) question:
>
> Is there any point to testing for an error condition without some idea
> in mind of what you'd do about it if it occurred?

I'd say, yes. I'd say that you better get an idea of what to do. You
can always terminate, can't you, in almost all environments? Of
course, my experience since 1971 is that incompetent programmers, as a
rule, ignore errors, and that in many nasty little data processing
shops, finding errors in a way that is not pre-approved can be a
"termination" offense, since it deconstructs the idea that the work
group knows what it is doing.

[Of course, unless Peter has got religion, he will talk to someone
else about me in a critical way rather than answer my post. This is
directed at others here for their comments for that reason.]

>
> -s
> --
> Copyright 2010, all wrongs reversed. =A0Peter Seebach / usenet-nos...@see=
bs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny picturesht=
tp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On Jul 30, 4:57=A0am, Richard Heathfield <r...@see.sig.invalid> wrote:
> Seebs wrote:
>
> <snip>
>
>
>
> > I think on principle I appreciate being alerted, but this does raise
> > a (sometimes C-related) question:
>
> > Is there any point to testing for an error condition without some idea
> > in mind of what you'd do about it if it occurred?
>
> #include <stdio.h>
>
> void report_error(const char *s)
> {
> =A0 =A0if(fprintf(stderr, "%s\n", s) < 0)
> =A0 =A0{
> =A0 =A0 =A0report_error("Can't write to stderr");
> =A0 =A0}
>
> }

That's a beaut, Dickie. Go into an infinite loop when you cannot write
to stderr?

Perhaps you jest.

>
> --
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line vacant - apply within

On Jul 30, 5:05=A0am, Keith Thompson <ks...@mib.org> wrote:
> Richard Heathfield <r...@see.sig.invalid> writes:
> > Seebs wrote:
> > <snip>
>
> >> I think on principle I appreciate being alerted, but this does raise
> >> a (sometimes C-related) question:
>
> >> Is there any point to testing for an error condition without some idea
> >> in mind of what you'd do about it if it occurred?
>
> > #include <stdio.h>
>
> > void report_error(const char *s)
> > {
> > =A0 =A0if(fprintf(stderr, "%s\n", s) < 0)
> > =A0 =A0{
> > =A0 =A0 =A0report_error("Can't write to stderr");
> > =A0 =A0}
> > }
>
> Clever trick. =A0If you can't write to stderr, a stack overflow is
> likely to cause the OS to do something that will catch the user's
> attention.

Duh! I was wrong. Keith is right. You will blow the stack.

But there was nothing clever about the code. Get a clue!
>
> On the other hand, if the compiler optimizes tail-recursion ...

....infinite loop after all?
>
> Hey, if writing to stderr fails, you could try writing to stdin;
> the user is bound to notice when error messages start coming out
> of the keyboard.
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org =A0<http://www.ghoti.net/~=
kst>
> Nokia
> "We must do something. =A0This is something. =A0Therefore, we must do thi=
s."
> =A0 =A0 -- Antony Jay and Jonathan Lynn, "Yes Minister"

On Aug 1, 4:13=A0am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <ee0d5533-2ac2-46fb-9be7-6c341904a...@y11g2000yqm.googlegroups=
..com>,
> Shao Miller =A0<sha0.mil...@gmail.com> wrote:
>
>
>
>
>
> > On Jul 30, 11:03 am, blm...@myrealbox.com <blm...@myrealbox.com>
> > wrote:
> > > In article <__mdnYamw8-m5dbRnZ2dnUVZ7q-dn...@bt.com>,
> > > Richard Heathfield =A0<r...@see.sig.invalid> wrote:
>
> > > > Shao Miller wrote:
> > > > > Is it possible that "claims" could be injected with additional me=
aning
> > > > > by the reader but not by the writer?
>
> > > > Yes, of course, and there's nothing the writer can do about that.
>
> > > I would be inclined, in this situation, to try to explicitly defuse
> > > the negative connotations of "claims" -- something like "he claims
> > > to be an expert, and he may very well be one -- I don't know enough
> > > to judge". =A0?
>
> > If a person receives an electric shock every time one reads "claims,"
> > that is sufficient reason to avoid using it around such a person.
> > Other such reasons and words are possible, and none of my business to
> > argue about, but to try to respect, instead.
>
> > An "insider's" perspective on the use of "claims to have" versus "has"
> > might very well perceive a negative connotation. =A0I did not, and thus
> > didn't intend it. =A0Consider an "outsider's" perspective which might
> > simply use "claims" as part of describing a logical reasoning
> > process. =A0Statements can make a claim, sound or unsound. =A0To use "h=
as"
> > instead of "claims to have" is illogical. =A0Deeming a statement as a
> > claim does not imply the claim is false (negative connotations). =A0I
> > cannot help that three people perceive a negative connotation. =A0This
> > paragraph can try and succeed, or try and fail.
>
> (I'm going to continue this off-topic discussion just a bit more,
> with the excuse that maybe by doing so I'll reduce the odds of similar
> kerfuffles in the future .... )
>
> Sure, I understood why you said "claims to have" rather than "has" --
> I do that myself when I don't really have any basis for knowing
> about the truth of the claim. =A0But I'm aware that for some people
> "claims to have" is not just a statement of fact, but one that casts
> doubt on the claim. =A0So I try to make it clear that I'm not trying
> to be insulting. =A0People [*] aren't always logical! =A0
>
> [*] There could be exceptions. =A0I'm not sure I've ever met one,
> but with, what, over 6 billion people on the planet, who can say ...
>
>
>
>
>
> > > > That's
> > > > why we have to be careful how we write, if we do not wish to be
> > > > misunderstood. (That applies to everyone, in all contexts, not just=
 in
> > > > comp.lang.c, and it applies as much to me as it does to you or to a=
nyone
> > > > else.)
>
> > > > > If I don't fully know the whole
> > > > > picture regarding everyone's status, can I reasonably say "has"
> > > > > instead of "claims to have"?
>
> > > I would not -- I would take the approach described above. =A0But this
> > > sort-of-advice should probably be taken with a big block of salt,
> > > because it does make for a rather wordy and pedantic style, maybe,
> > > and while that's pretty appropriate for me, maybe not so much for
> > > the OP.
>
> > Agreed on "wordy and pedantic style." =A0
>
> Careful, there, who are you calling "wordy and pedantic" .... =A0
>
> Oh, maybe no one. =A0(And even if you were, it would be true of me,
> though a "smile when you say that, pardner" [*] would be in order.)
>
> [*] Possibly US-centric cultural reference to -- some movie from
> long ago, I think. =A0The point is that it's easier to be laughed
> *with* than laughed *at*. =A0If that doesn't make sense say so and
> I'll try to clarify.
>
> > Styles can be adapted, also.
> > Let's call it what it is, though: Being especially sensitive to a list
> > of trigger words with possible emotional associations for readers. =A0I
> > have failed to demonstrate such sensitivity, which warrants an
> > apology. =A0I'm sorry. =A0Perhaps we have cultural differences. =A0Plea=
se
> > forgive and be tolerant. =A0There is no objective implication of disput=
e
> > using "claims to have," so one cannot guarantee "loading" of a "word-
> > weapon" and ill intent.
>
> "Cultural differences" is a possibility. =A0I'm writing from the
> US, which is where I grew up and currently reside. =A0I don't think
> I'm much more provincial and US-centric than most people in this
> country, but admittedly that's a low bar.
>
> To me you're coming across as someone who considers only the logical
> meaning of words and not their potential emotional impact on readers.
> I suspect that this puts you in a small minority, though I could be
> wrong about that. =A0I also suspect that "logical meaning only" people
> are apt to be more readily found in technical fields than elsewhere.

Actually, it is quite US centric of you to use ugly phrases such as
"you are coming across as", which imply that the group knows the
person better than he knows himself. It's a way of criticising a
person, and evading the matter he raises which is overused in
corporations in the US.

It's a lazy way of justifying sloppy thinking and self-centered
hermeneutics, at worse.

I see you are still quite the female enabler of male bullying. You
pour honey on people merely to attract the fire ants.

That's a metaphor, my dear. I teach English.

>
> > > ... ... ...
> > > The OP might however want to avoid my tendency to drift off-topic.
> > > Just sayin'. =A0:-)?
>
> > It's difficult to avoid being drawn into personal back-and-forth,
> > despite determination.
>
> Isn't it, though.
>
> [ snip ]
>
> > > Agreed -- but really, it kind of surprises me that someone who
> > > seems entirely fluent in English would not know that both of
> > > these words can have negative connotations. =A0But there may be
> > > some obvious explanation for that, one that's not occurring to me.
>
> > This implies that fluency in English is sufficient cause for awareness
> > of negative connotations for these words. =A0Connotations are cultural
> > and not universal to a language. =A0That is the cause for your surprise=
..
>
> Fair enough. =A0(I did think it might be something along those lines
> but couldn't think how to express that thought politely enough.)
>
> > I daresay that connotations are also fuzzy without context. =A0There wa=
s
> > no personal attack happening, so use of "claims to have" need not
> > carry a negative connotation. =A0It is understandable that someone
> > perceiving a personal attack might also perceive a negative
> > connotation. =A0So in general: stop perceiving personal attacks where
> > there are none. =A0A history of personal attacks in Usenet might make
> > this challenging.
>
> > I took part of Richard's advice the day of his kind words and read a
> > good number of your posts. =A0Thanks, B.
>
> If I've helped -- happy to do so. =A0You may have observed that on
> some occasions (not in this discussion, but in others) I can be
> too quick to take offense where none was intended. =A0It's one of
> the hazards of a text-only medium, I think!
>
> Indeed, this discussion is another example ....
>
> --
> B. L. Massingill
> ObDisclaimer: =A0I don't speak for my employers; they return the favor.

On 26 July, 06:45, Shao Miller <sha0.mil...@gmail.com> wrote:
> On Jul 26, 12:06=A0am, c...@tiac.net (Richard Harter) wrote:
> On Sun, 25 Jul 2010 11:43:00 -0700 (PDT), Shao Miller
> > <sha0.mil...@gmail.com> wrote:
> > >On Jul 25, 10:59=3DA0am, c...@tiac.net (Richard Harter) wrote:


> > >> When they were doing the
> > >> standard they had two issues they were trying to clear up. One
> > >> was providing a way to say that a function returns nothing. The
> > >> other was to provide generic pointers that would be automatically
> > >> converted without casting.

and they used the same keyword for both.


> > >Just a guess: The third was allowing for an uninteresting result to be
> > >discarded. =A0Would you agree?
>
> > No.
>
> Where does this response come from?

because it isn't so?


> =A0Are you suggesting that casting
> to 'void' was not an original issue but came later on?

what is "an original issue"

I don't think the standard gives any particular meaning to a cast to
void

>=A0If so, this
> sounds like a good history lesson worth reading. =A0I will try to find
> it, since I could only "guess," above.
>
> > >int func(void) {
> > > =A0return 5;
> > >}
>
> > >int main(void) {
> > > =A0(void)func();
> > > =A0return 0;
> > >}
>
> > In the line
> > =A0 =A0 (void)func();
> > the (void) is not required and does nothing. =A0The line could have
> > read:
> > =A0 =A0 func();
>
> > and the result would have been the same - a value would be
> > returned and discarded. =A0Caveat: If your warning level is set
> > high enough the compiler might give you a warning about ignoring
> > a returned value.

but that is nothing to do with the standard but only what certain
implementaions choose to do (particularly some older and more broken
lints). An implemention may issue a warning ("diagnostic" in
standardese) for anything it feels like.

> Right... =A0So I'd also guess that you don't share my aesthetic
> preference for how we could discard a 'void *' result with a single
> keystroke,

what? What single keystroke discarded a void* value? Note that by
dereferencing a null pointer you've *already* committted UB. Thre is
in a sense no value to discard.


> given such warning levels and compilers, and iff we (and
> implementations) _did_ agree to the allowance of dereferencing a 'void
> *'. =A0

the standard says it's undefined behaviour. If the implementaion
chooses to return a value that's still compliant. *Any* behaviour is
compliant with undefined behaviour. You might be confusing
implmentation with language definition.

I've used compilers that *did* return a value for *NULL. Usually the
contents of location zero.

> I only really meant to suggest a usefulness similar to that of
> casting to 'void'.

I'm not sure it *is* useful and I think ascribing a meaning to

   (void) *NULL;

is simply stupid

>=A0You have described one such situation where
> warnings result from an implementation without casting to 'void'.

I regard such implementations as broken


--

If you want to build a ship, don't drum up the men to gather wood,
 divide the work and give orders.
Instead, teach them to yearn for the vast and endless sea.
 - A. de Saint-Exupery

On Aug 2, 3:41=A0am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 26 July, 06:45, Shao Miller <sha0.mil...@gmail.com> wrote:
>
> > On Jul 26, 12:06=A0am, c...@tiac.net (Richard Harter) wrote:
> > On Sun, 25 Jul 2010 11:43:00 -0700 (PDT), Shao Miller
> > > <sha0.mil...@gmail.com> wrote:
> > > >On Jul 25, 10:59=3DA0am, c...@tiac.net (Richard Harter) wrote:
> > > >> When they were doing the
> > > >> standard they had two issues they were trying to clear up. One
> > > >> was providing a way to say that a function returns nothing. The
> > > >> other was to provide generic pointers that would be automatically
> > > >> converted without casting.
>
> and they used the same keyword for both.
>
Sure they did.  Later on, it would even be used inside parameter
lists.

> > > >Just a guess: The third was allowing for an uninteresting result to =
be
> > > >discarded. =A0Would you agree?
>
> > > No.
>
> > Where does this response come from?
>
> because it isn't so?
>
The question might need clarification: How can I know that as well as
you know it?

> > =A0Are you suggesting that casting
> > to 'void' was not an original issue but came later on?
>
> what is "an original issue"
>
Maybe Richard can clarify.  Otherwise, "original issue" means an issue
that was being considered at the time "When they were doing the
standard..."

> I don't think the standard gives any particular meaning to a cast to
> void
>
Well, in casting to 'void', 6.5.4,p4 converts a value to 'void' type.
6.2.5,p19 defines "The void type comprises an empty set of values..."
How do you convert a value to an empty set of values?  You discard
it.  6.3.2.2,p1 goes on to describe how "a void expression" has no
value, but can nonetheless be cast to 'void', beyond the semantics for
cast operators (6.5.4,p4) describing converting a value.  Then there's
the constraint 6.5.4,p2 which actually says "a void type".  That seems
pretty particular to me.

It's interesting to think about what "If an expression of any other
type is evaluated as a void expression, its value or designator is
discarded" might mean.  In cases where we call a function and discard
its value, might that be considered an expression of a non-'void' type
being evaluated as a void expression?

> >=A0If so, this
> > sounds like a good history lesson worth reading. =A0I will try to find
> > it, since I could only "guess," above.
>
> > > >int func(void) {
> > > > =A0return 5;
> > > >}
>
> > > >int main(void) {
> > > > =A0(void)func();
> > > > =A0return 0;
> > > >}
>
> > > In the line
> > > =A0 =A0 (void)func();
> > > the (void) is not required and does nothing. =A0The line could have
> > > read:
> > > =A0 =A0 func();
>
> > > and the result would have been the same - a value would be
> > > returned and discarded. =A0Caveat: If your warning level is set
> > > high enough the compiler might give you a warning about ignoring
> > > a returned value.
>
> but that is nothing to do with the standard but only what certain
> implementaions choose to do (particularly some older and more broken
> lints). An implemention may issue a warning ("diagnostic" in
> standardese) for anything it feels like.
>
Agreed.

> > Right... =A0So I'd also guess that you don't share my aesthetic
> > preference for how we could discard a 'void *' result with a single
> > keystroke,
>
> what? What single keystroke discarded a void* value? Note that by
> dereferencing a null pointer you've *already* committted UB. Thre is
> in a sense no value to discard.
>
You might have confused "null pointer" with 'void *', here.  You might
have also missed some posts.  Briefly:

int main(void) {
  int i =3D 5;
  void *vp =3D &i;
  *vp;
  return 0;
}

'vp' has type 'void *'.  The suggestion was that the unary '*' could
simply take that expression as an operand and yield a void expression,
since "If the operand has type =91=91pointer to type=92=92, the result has
type =91=91type=92=92." (6.5.3.2,p4)  Thus the single keystroke '*' would b=
e
equivalent to '(void)', for that very particular scenario.

> > given such warning levels and compilers, and iff we (and
> > implementations) _did_ agree to the allowance of dereferencing a 'void
> > *'. =A0
>
> the standard says it's undefined behaviour.
That statement was part of what was being discussed.  Just to break it
down: It does not include the text "dereferencing a 'void *' is
undefined behaviour."  If it did, then it would have "said" it's
undefined behaviour.  It doesn't.  People say that.

Now comes the undefined-behaviour-by-omission argument, but read again
"If the operand has type =91=91pointer to type=92=92, the result has type
=91=91type=92=92." (6.5.3.2,p4)  That readily appears to define the
behaviour.  If the expression is '*E', and 'E' has type =91=91pointer to
void=92=92, then constraints are met, the result has type =91=91void=92=92,=
 that's
a 'void' expression, so it's evaluated, evaluating 'E' does no harm
(it's just a value).

Now comes the doesn't-match-object-pointer-or-function-pointer
argument.  But where is it stated that this is a requirement?  It
isn't stated.  Those are "if"s.  The case of a 'void *' operand is
sufficiently covered by "If the operand has type =91=91pointer to type=92=
=92,
the result has type =91=91type=92=92." (6.5.3.2,p4).  Then read "The void t=
ype
comprises an empty set of values..." (6.2.5,p19).  Then read "The
(nonexistent) value of a void expression (an expression that has type
void) shall not be used in any way..." (6.3.2.2,p1).

Those were some of the arguments.

> If the implementaion
> chooses to return a value that's still compliant. *Any* behaviour is
> compliant with undefined behaviour. You might be confusing
> implmentation with language definition.
>
Well I specifically meant an allowance by interpreting our reading as
providing a definition other than "undefined behaviour."  Yes an
implementation can define what they like, but that's not guaranteed to
be in the spirit of portability. :)

> I've used compilers that *did* return a value for *NULL. Usually the
> contents of location zero.
>
Now you've switched back over to a null pointer.  Ok. :)  It seems
that your compilers that did that used something other than '((void
*)0)' for their definition of 'NULL'.  Possibly '((char *)0)'.
Otherwise, it would be hard to imagine a value for '*NULL'.

> > I only really meant to suggest a usefulness similar to that of
> > casting to 'void'.
>
> I'm not sure it *is* useful and I think ascribing a meaning to
>
> =A0 =A0(void) *NULL;
>
> is simply stupid
>
Ugh.  I don't remember suggesting that.  Maybe someone else did or
maybe you misunderstood something.  Sorry.

> >=A0You have described one such situation where
> > warnings result from an implementation without casting to 'void'.
>
> I regard such implementations as broken
>
Or at least enthusiastic about informing the programmer that they
might be forgetting to check an important return value, such as:

int *foo;
foo =3D malloc(sizeof (int[100]));
if (!foo) /* ... */

being mistakenly, partially deleted to:

int *foo;
 malloc(sizeof (int[100]));
if (!foo) /* ... */

In article <14700fda-3ca2-4d27-a151-72607d3dd80b@u26g2000yqu.googlegroups.com>,
Shao Miller  <sha0.miller@gmail.com> wrote:
> On Jul 31, 4:13 pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > In article <ee0d5533-2ac2-46fb-9be7-6c341904a...@y11g2000yqm.googlegroups.com>,
> > Shao Miller  <sha0.mil...@gmail.com> wrote:
> >
> >
> >
> > > On Jul 30, 11:03 am, blm...@myrealbox.com <blm...@myrealbox.com>
> > > wrote:
> > > > In article <__mdnYamw8-m5dbRnZ2dnUVZ7q-dn...@bt.com>,
> > > > Richard Heathfield  <r...@see.sig.invalid> wrote:

[ snip ]

> > > If a person receives an electric shock every time one reads "claims,"
> > > that is sufficient reason to avoid using it around such a person.
> > > Other such reasons and words are possible, and none of my business to
> > > argue about, but to try to respect, instead.
> >
> > > An "insider's" perspective on the use of "claims to have" versus "has"
> > > might very well perceive a negative connotation.  I did not, and thus
> > > didn't intend it.  Consider an "outsider's" perspective which might
> > > simply use "claims" as part of describing a logical reasoning
> > > process.  Statements can make a claim, sound or unsound.  To use "has"
> > > instead of "claims to have" is illogical.  Deeming a statement as a
> > > claim does not imply the claim is false (negative connotations).  I
> > > cannot help that three people perceive a negative connotation.  This
> > > paragraph can try and succeed, or try and fail.

[ snip ]

> > Sure, I understood why you said "claims to have" rather than "has" --
> > I do that myself when I don't really have any basis for knowing
> > about the truth of the claim.  But I'm aware that for some people
> > "claims to have" is not just a statement of fact, but one that casts
> > doubt on the claim.  So I try to make it clear that I'm not trying
> > to be insulting.  People [*] aren't always logical!  
> >
> > [*] There could be exceptions.  I'm not sure I've ever met one,
> > but with, what, over 6 billion people on the planet, who can say ...
> >
> I agree.  I believe that people associating a claim of a claim with a
> dispute for the latter claim will find their doubt-casting.  

I don't understand what you mean by that sentence, but maybe it's
not very important.

> That can
> be reconditioned just as avoidance of "bad words" can be
> reconditioned.

[ snip ]

> > > > I would not -- I would take the approach described above.  But this
> > > > sort-of-advice should probably be taken with a big block of salt,
> > > > because it does make for a rather wordy and pedantic style, maybe,
> > > > and while that's pretty appropriate for me, maybe not so much for
> > > > the OP.
> >
> > > Agreed on "wordy and pedantic style."  
> >
> > Careful, there, who are you calling "wordy and pedantic" ....  
> >
> > Oh, maybe no one.  (And even if you were, it would be true of me,
> > though a "smile when you say that, pardner" [*] would be in order.)
> >
> "Wordy and pedantic style" applies to _my_ posts _already_. :)  

"You said it, not me" ?  (But yeah, now that you mention it ....)

I'd better add a :-), no?

> It
> will _continue_ to apply as more emotional lighteners and/or
> neutralizers are sprinkled in.
> 
> "...who are you calling..." is another example of a perceived
> attack. :S  

Meaning "an example of perceiving an attack where none was meant"?

> I have already requested that in general: stop perceiving
> personal attacks where
> there are none; even though a history of personal attacks in Usenet
> might make this challenging. :S
> 
> > [*] Possibly US-centric cultural reference to -- some movie from
> > long ago, I think.  The point is that it's easier to be laughed
> > *with* than laughed *at*.  If that doesn't make sense say so and
> > I'll try to clarify.
> >
> That cultural reference is familiar to me, outside of the U. S. A.
> Agreed that the reference comes from that culture. :)
> 
> Nobody should be laughing when the subject is people's feelings being
> hurt, in my opinion.  It's a very serious matter.  That is why there
> aren't any smile tokens in that post.  A smile token might encourage
> laughter.

Well, yeah, but my point was that sometimes the same words can be
perceived either as an attack or an invitation to join in laughing
about shared foibles.  In a text-only medium it can be hard to
tell the difference.  Emoticons can be irritating when overused,
but sometimes they do help.

[ snip ]

> > Fair enough.  (I did think it might be something along those lines
> > but couldn't think how to express that thought politely enough.)
> >
> Thanks for being polite. :)

I'm on my best behavior here because of the RH post that prompted
me to put in my two cents' worth.  Also maybe a :-).

[ snip ]

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

In article <e743861c-57c3-4340-9965-47a89948ad7b@w30g2000yqw.googlegroups.com>,
Shao Miller  <sha0.miller@gmail.com> wrote:
> On Jul 31, 5:53 pm, Seebs <usenet-nos...@seebs.net> wrote:
> > On 2010-07-31, blmblm  myrealbox.com <blm...@myrealbox.com> wrote:
> >
> > > To me you're coming across as someone who considers only the logical
> > > meaning of words and not their potential emotional impact on readers.
> > > I suspect that this puts you in a small minority, though I could be
> > > wrong about that.  I also suspect that "logical meaning only" people
> > > are apt to be more readily found in technical fields than elsewhere.
> >
> > This is not implausible.  Ironically, it took me years of study to
> > start picking up connotations.
> >
> Thank for your acknowledging that fluency in English is not sufficient
> cause for awareness of the negative connotations you perceive.  I
> agree.

I think, though, that Seebs's remark about how it took him a while
may have less to do with the inherent difficulty of understanding
about connotations than with the fact that he's -- well, he's
said in other posts that he's something of an outlier on some
measures related to social skills.  I'll let him explain further
if he wants to.

> > >> This implies that fluency in English is sufficient cause for awareness
> > >> of negative connotations for these words.  Connotations are cultural
> > >> and not universal to a language.  That is the cause for your surprise.
> > > Fair enough.  (I did think it might be something along those lines
> > > but couldn't think how to express that thought politely enough.)
> >
> > While it's true that connotations are often cultural, I am not aware
> > of any culture in which accusing someone of having invented something
> > when they cite to a text as showing it does not constitute an
> > accusation of dishonesty.  I have spoken with English-speakers from
> > many countries, and in this case, the connotation is not so much
> > cultural as a question of Gricean maxims.
> It's not an accusation.  It's a claim that there is no supporting
> reference to the text given.  

But that also *might* be an accusation, of a sort -- if you
mean that no supporting evidence *exists*, rather than that no
supporting evidence *has been presented*.  It's not clear to me
which of these meanings is intended, though admittedly the latter
might be somewhat more probable.

In any case, I agree with Seebs that in context "invented" is
difficult to interpret as anything *but* an insult.

How did we get into *this* mess ....  You wrote in another post
the following:

>>You have invented the requirement for the pointer operand to "point to
>>an object".  Consider a function pointer.  You have invented
>>supposedly undefined behaviour.  In this Method #1, you have not
>>convinced me, I'm sorry to say.  I was hopeful.  It might even be of
>>no consequence to you whether I've been convinced or not.  That's
>>fine.
>>
>>Where I might say "invented" below, I additionally mean, "or have not
>>cited a reference which supports."

That second paragraph -- I'm guessing that was your attempt
to clarify your meaning, but the use of "below" introduces at
least some ambiguity about whether it applies to the preceding
paragraph, and I'm just not sure what "additionally" means here.
(I'd have left it out.)

How would I reword ....

The first sentence could read "You state/imply a requirement ...."
And then you could go on to ask whether he can cite a reference
for this claim.

> You can demonstrate otherwise.  You can
> choose to ignore (ie. "plonk").  Your knowledge that there _is_ text
> to support your statements is not accessible to me.  If you do not
> include the references, the knowledge cannot be accessed.  The
> original post includes a great number of references.  That was my
> expectation for responses.  That was my mistake.  "Highest levels of
> pedantry" was a mistake to request.

Oh no, I think in *THIS* group, asking for the highest level
of pedantry is not only thoroughly appropriate, given the local
culture, but might even be interpreted as something of an inside
joke.  Sort of a :-).

> These are my claims.  I offer no external references for them.  Thus,
> they are also my inventions. :)

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

(Maybe if I put the "OT" in parentheses rather than brackets it
will survive better.  It appears that GG's posting interface
strips off tags in brackets.  Anyone know why that might have
seemed like a good idea??)

In article <d04cc085-ca7d-4331-83ec-9f8f15f53fff@z34g2000pro.googlegroups.com>,
spinoza1111  <spinoza1111@yahoo.com> wrote:
> On Jul 29, 9:16 pm, c...@tiac.net (Richard Harter) wrote:
> > On Wed, 28 Jul 2010 21:27:45 -0700 (PDT),spinoza1111
> >
> > <spinoza1...@yahoo.com> wrote:
> > >On Jul 25, 3:29=A0am, Seebs <usenet-nos...@seebs.net> wrote:

[ snip ]

> I'm not a stalker. Seebach unleashed a cybernetic mob on Herb Schildt
> a number of years ago in order to advance himself in a career for
> which Seebach is just not qualified, and I examined Seebach's attack
> to find it to be garbage. My article about this matter was accepted
> for publication in the competently moderated and prestigious group
> comp.risks. The moderator was then spammed by the sort of cybernetic
> mob Seebach had marshaled against Schildt and printed an apology for
> accepting my article, 

Why?  If he was right to accept your article, why not print(?)
a defense instead?  It seems to me that you're contradicting
yourself here -- the moderation is competent, and yet the moderator
succumbed to pressure?

> but then accepted a second article on an
> unrelated topic (the California payroll system crisis).

Yes, I noticed that one, and ....  You know, it's possible that my
reaction was influenced more than it should have been by the name
of the author, but aside from drawing attention to an interesting
item in the mainstream press, the post seemed to me to be, hm,
long on speculation and short on content appropriate to the venue.

My two cents' worth.  I notice the next two issues of the digest
have contained some responses that -- eh, anyone who reads your
post should probably read those too.  Just sayin'.

[ snip ]

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

In article <0356c8f5-eb5a-4c75-88d8-1e109f23aca2@z30g2000prg.googlegroups.com>,
spinoza1111  <spinoza1111@yahoo.com> wrote:
> On Aug 1, 4:13 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > In article <ee0d5533-2ac2-46fb-9be7-6c341904a...@y11g2000yqm.googlegroups.com>,
> > Shao Miller  <sha0.mil...@gmail.com> wrote:

[ snip ]

> > > Styles can be adapted, also.
> > > Let's call it what it is, though: Being especially sensitive to a list
> > > of trigger words with possible emotional associations for readers.  I
> > > have failed to demonstrate such sensitivity, which warrants an
> > > apology.  I'm sorry.  Perhaps we have cultural differences.  Please
> > > forgive and be tolerant.  There is no objective implication of dispute
> > > using "claims to have," so one cannot guarantee "loading" of a "word-
> > > weapon" and ill intent.
> >
> > "Cultural differences" is a possibility.  I'm writing from the
> > US, which is where I grew up and currently reside.  I don't think
> > I'm much more provincial and US-centric than most people in this
> > country, but admittedly that's a low bar.
> >
> > To me you're coming across as someone who considers only the logical
> > meaning of words and not their potential emotional impact on readers.
> > I suspect that this puts you in a small minority, though I could be
> > wrong about that.  I also suspect that "logical meaning only" people
> > are apt to be more readily found in technical fields than elsewhere.
> 
> Actually, it is quite US centric of you to use ugly phrases such as
> "you are coming across as", which imply that the group knows the
> person better than he knows himself. 

Oh?  In my usage, "you are coming across as" means "you are being
perceived as" -- and really, isn't that something about which
the perceivers (the group) *do* know more than the perceived
(the person)?  Does it mean something else in your usage?

You might notice also that I said "*to me* [emphasis added] you
are coming across as", so indeed it would seem to me that I'm
making claims only about my own perceptions rather than those of
some nebulous group, and surely I do know more about those?

Is my intended meaning clearer?  Would it have been less offensive
if phrased another way?  if so, perhaps you can suggest another
wording that doesn't involve phrases you find ugly.

> It's a way of criticising a
> person, and evading the matter he raises which is overused in
> corporations in the US.
> 
> It's a lazy way of justifying sloppy thinking and self-centered
> hermeneutics, at worse.
> 
> I see you are still quite the female enabler of male bullying. You
> pour honey on people merely to attract the fire ants.
> 
> That's a metaphor, my dear. I teach English.

And apparently you're still being patronizing.  

(So much for my attempt to be on my best behavior in this thread.
Sigh.)

[ snip ]

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

On 2010-08-03, blmblm  myrealbox.com <blmblm@myrealbox.com> wrote:
> I think, though, that Seebs's remark about how it took him a while
> may have less to do with the inherent difficulty of understanding
> about connotations than with the fact that he's -- well, he's
> said in other posts that he's something of an outlier on some
> measures related to social skills.  I'll let him explain further
> if he wants to.

I'm autistic.  Not "severely", or whatever, but enough that I had to be
explicitly told that connotations existed, and I still couldn't understand
most of the implication logic until someone told me about Gricean
maxims.

>> It's not an accusation.  It's a claim that there is no supporting
>> reference to the text given.  

> But that also *might* be an accusation, of a sort -- if you
> mean that no supporting evidence *exists*, rather than that no
> supporting evidence *has been presented*.  It's not clear to me
> which of these meanings is intended, though admittedly the latter
> might be somewhat more probable.

"Invented" implies that the supporting evidence does not *exist*.  If it
were extant, but unpresented, you wouldn't be inventing it.

> Oh no, I think in *THIS* group, asking for the highest level
> of pedantry is not only thoroughly appropriate, given the local
> culture, but might even be interpreted as something of an inside
> joke.  Sort of a :-).

Yes.

And for what it's worth, I did, as I recall, point to the statements that
the lack of a definition shows undefined behavior, which is the point that
was apparently missing.  If we are told that:

* If A, then the result is X.
* If B, then the result is Y.

this means that, if !(A||B), the behavior is undefined, because no definition
was provided, and in the absence of a definition, things are undefined.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

In regards to:

int two_d_array[10][10];
two_d_array[0][20] =3D 1;

On Aug 1, 9:01 am, Tim Rentsch <t...@alumni.caltech.edu> wrote:
> The problem is that the Standard should define unambiguously what
> that object is in each of the various different circumstances;
> unfortunately, it doesn't.
>
It would be nice if it did; agreed.  We have section 3.14 (there's
something familiar about that number), point 1:

"object

1 region of data storage in the execution environment, the contents of
which can represent
values

2 NOTE When referenced, an object may be interpreted as having a
particular type; see 6.3.2.1."

In 6.3.2.1,p3, we see "...If the array object has register storage
class, the behavior is undefined" which suggests that array objects
needn't even be addressable, but an implementation could choose to
provide some definition.  It might be tricky to imagine array
subscripting in terms of the equivalence to pointer arithmetic in such
a case, since it might be tricky to imagine a pointer pointing into a
register. :)

In 7.20.3,p1 for 'malloc' and family reads, "...Each such allocation
shall yield a pointer to an object disjoint from any other object..."
and a bit before that "...used to access such an object or an array of
such objects..." :)  7.30.3.3,p2 describes 'malloc' to allocate space
for "...an object whose size is is specified..." whereas 7.20.3.1,p2
describes 'calloc' to allocate space "...for an array of...objects..."

Back to 6.5.6,p7, pointer arithmetic on a pointer to a single object
is defined to be the same as if that object is an array object with
one element of that object's type.  So for any pointer 'p', we can
point one-past with 'p + 1' without overflow.

For object(s) with "allocated" "storage duration" (6.2.4,p1), we have
no declared type but only "effective type" (6.5,p6).  The text also
reads that the effective type for an object can change, which is
similar to the notion that a union is an object whose type depends on
which member is used to modify a value within that object.  The text
also reads that copying into an object via treatment of that object as
an array of character type is valid.  This implies copying _from_ some
other object, so it also implies that an object can validly be read as
an array of character type.

Putting this all together, it seems that:
- All objects may be considered as array objects with one element for
pointer arithmetic
- The notion of an object is simply a region of data storage where
there are values possible
- You need an effective type to _interpret_ such possible values
- You need an effective type to _access_ (read/modify) such possible
values, _or_ you can read an object as an array of character type
- We need some interpretation of "number of elements" for pointer
arithmetic, but we are guaranteed >=3D 1.  We could interpret:
  (a) based on effective type of the region of data storage, or
  (b) based on declared type, but this latter interpretation would
make pointer arithmetic undefined for data regions with "allocated"
storage duration, or
  (c) based on declared type if available, otherwise effective type.
That might seem odd, but hey. :)

It might be debatable what the declared type of the object pointed-to
by 'two_d_array[0]' is, since the declaration declares 'two_d_array',
doesn't declare any objects of pointer type. :)

For 'sizeof', 'two_d_array[0]' has type 'int[10]'.  Regardless of non-
evaluation, consider that the semantics of evaluation suggest
'two_d_array[0]' being equivalent to '(*((two_d_array) + (0)))'.  We
have 'two_d_array' become 'int(*)[10]', we'd add 0, then we'd
dereference to yield type 'int[10]'.

For '&', we have the equivalence of '&(*((two_d_array) + (0)))' where
neither '&' nor '*' are part of the evaluation.  So we are left with
'((two_d_array) + (0))'.  That would yield a result with type 'int(*)
[10]'.  So the pointed-to type for the object could be considered
'int[10]', but we're the operand to '&', so we don't care.

For anything else, 'two_d_array[0]' or '(*((two_d_array) + (0)))'
yields the same type as for 'sizeof', 'int[10]'.  But this isn't a
pointer type. :)  'int[10]' cannot point into an object, since it's an
array type.  A further subscript operator requires a pointer operand,
by constraint 6.5.2.1,p1.  Fortunately, the result "decays" into 'int
*' and satisfies the constraint.

But after all of this pedantry, what was the declared type for the
region of storage (object) we might associate with "being pointed
into" by 'two_d_array[0]'?  Is it 'int[10]' or 'int'?  If it's the
former, which sure looks like the declaration, then we should require
a pointer with type 'int(*)[10]' to get at it.  But we can get two
different kinds of pointers from 'two_d_array[0]'.  One for '&' with
type 'int(*)[10]'.  One for everything else with type 'int *'.

Ugh. :)

> > In practice, implementations are not going to add code to play
> > bounds-cop on you when you are clearly well within program-owned
> > memory. My own view, therefore, is that the behaviour is undefined in
> > theory but well-defined in practice. =A0[snip]
>
> I mostly agree, but intra-function or intra-translation-unit
> alias analysis is an important exception. =A0These cases may
> very well manifest unde{sir,fin}ed behavior upon such usage.
Exactly!  So if we treat the object caused into existence (heh) by
'int two_d_array[10][10];' for the subject of pointer arithmetic as a
single object, it's an array object.  If we treat the space as
multiple objects, where are the boundaries drawn?  At sub-arrays (each
'int[10]')?  At elements (each 'int')?  We can copy the whole space as
array of 'char' and we might expect that to be well-defined.  How does
our use of 'char *' in such a copy work?  Could we run out-of-bounds
at object boundaries we've drawn at a sub-array level?

It seems to me that C's model for objects in the abstract machine are
rather typeless and that the types and operations of the code
"project" types and values onto these objects.  Is that a fair
interpretation?

On 3 Aug, 01:08, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <e743861c-57c3-4340-9965-47a89948a...@w30g2000yqw.googlegroups=
..com>,
> Shao Miller =A0<sha0.mil...@gmail.com> wrote:

<snip>

> > [...] =A0Your knowledge that there _is_ text
> > to support your statements is not accessible to me. =A0If you do not
> > include the references, the knowledge cannot be accessed. =A0The
> > original post includes a great number of references. =A0That was my
> > expectation for responses. =A0That was my mistake. =A0"Highest levels o=
f
> > pedantry" was a mistake to request.
>
> Oh no, I think in *THIS* group, asking for the highest level
> of pedantry is not only thoroughly appropriate, given the local
> culture, but might even be interpreted as something of an inside
> joke. =A0Sort of a :-).

old clc quote:

in comp.lang.c, the very people most capable of making the inference
are those least likely to make it. This newsgroup considers pedantry
to be an art form.
                           Richard Heathfield



> > These are my claims. =A0I offer no external references for them. =A0Thu=
s,
> > they are also my inventions. :)

In article <slrni5f0nf.939.usenet-nospam@guild.seebs.net>,
Seebs  <usenet-nospam@seebs.net> wrote:
> On 2010-08-03, blmblm  myrealbox.com <blmblm@myrealbox.com> wrote:
> > I think, though, that Seebs's remark about how it took him a while
> > may have less to do with the inherent difficulty of understanding
> > about connotations than with the fact that he's -- well, he's
> > said in other posts that he's something of an outlier on some
> > measures related to social skills.  I'll let him explain further
> > if he wants to.
> 
> I'm autistic.  Not "severely", or whatever, but enough that I had to be
> explicitly told that connotations existed, and I still couldn't understand
> most of the implication logic until someone told me about Gricean
> maxims.

You mentioned those (Gricean maxims) before, and now I'm curious ....

Well, I stopped after the first few paragraphs of the Wikipedia
article.  Maybe I'm not *that* curious.  :-)  Still, interesting.
Interesting, too, to think about how some people can only (but
can!) acquire by conscious study what others pick up without
thinking about it.

(Your explanation was just what I had in mind, by the way --
but I didn't feel like I could or should attempt it myself.)

> >> It's not an accusation.  It's a claim that there is no supporting
> >> reference to the text given.  
> 
> > But that also *might* be an accusation, of a sort -- if you
> > mean that no supporting evidence *exists*, rather than that no
> > supporting evidence *has been presented*.  It's not clear to me
> > which of these meanings is intended, though admittedly the latter
> > might be somewhat more probable.
> 
> "Invented" implies that the supporting evidence does not *exist*.  If it
> were extant, but unpresented, you wouldn't be inventing it.

Yes, yes ....  I think I didn't make my meaning clear.  When I said
"that also *might* be an accusation, of a sort", I was referring to
the quoted sentence immediately above ("It's a claim that ...."),
which I think could be parsed two ways.  I'm not sure how to explain
this, but maybe using { } as grouping brackets .... :

"It's a claim that there is no supporting reference to {the text 
given}." 

versus

"It's a claim that there is no {supporting reference to the text}
given."

The second simply says that no evidence has been given; the first
rather implies that no such evidence exists.

I'm probably not explaining this very well and indeed may not have
it entirely clear in my head.  But maybe this clarifies just a bit.

[ snip ]

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

On Aug 3, 8:14=A0am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <0356c8f5-eb5a-4c75-88d8-1e109f23a...@z30g2000prg.googlegroups=
..com>,
>
> spinoza1111=A0<spinoza1...@yahoo.com> wrote:
> > On Aug 1, 4:13 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > > In article <ee0d5533-2ac2-46fb-9be7-6c341904a...@y11g2000yqm.googlegr=
oups.com>,
> > > Shao Miller =A0<sha0.mil...@gmail.com> wrote:
>
> [ snip ]
>
>
>
>
>
> > > > Styles can be adapted, also.
> > > > Let's call it what it is, though: Being especially sensitive to a l=
ist
> > > > of trigger words with possible emotional associations for readers. =
=A0I
> > > > have failed to demonstrate such sensitivity, which warrants an
> > > > apology. =A0I'm sorry. =A0Perhaps we have cultural differences. =A0=
Please
> > > > forgive and be tolerant. =A0There is no objective implication of di=
spute
> > > > using "claims to have," so one cannot guarantee "loading" of a "wor=
d-
> > > > weapon" and ill intent.
>
> > > "Cultural differences" is a possibility. =A0I'm writing from the
> > > US, which is where I grew up and currently reside. =A0I don't think
> > > I'm much more provincial and US-centric than most people in this
> > > country, but admittedly that's a low bar.
>
> > > To me you're coming across as someone who considers only the logical
> > > meaning of words and not their potential emotional impact on readers.
> > > I suspect that this puts you in a small minority, though I could be
> > > wrong about that. =A0I also suspect that "logical meaning only" peopl=
e
> > > are apt to be more readily found in technical fields than elsewhere.
>
> > Actually, it is quite US centric of you to use ugly phrases such as
> > "you are coming across as", which imply that the group knows the
> > person better than he knows himself.
>
> Oh? =A0In my usage, "you are coming across as" means "you are being
> perceived as" -- and really, isn't that something about which
> the perceivers (the group) *do* know more than the perceived
> (the person)? =A0Does it mean something else in your usage?

What is group knowledge? Is it something superior in all cases, or
even in most cases, than the knowledge of an individual? And can it be
greater than the sum of its parts? Can a group composed of inferior
knowers know more than a good knower? Is what they produce even
knowledge, or more like a text such as wikipedia? And isn't their
knowledge/text in large measure itself measured by its fecundity, eg.,
its production of new knowers who as such are individuals? And isn't
it the case that while you folks might have "the tongues of men and
angels" on your hard drives, most of you are bone stupid and getting
more so?



>
> You might notice also that I said "*to me* [emphasis added] you
> are coming across as", so indeed it would seem to me that I'm
> making claims only about my own perceptions rather than those of
> some nebulous group, and surely I do know more about those?

I think you've lost touch with your ability to have a genuine
perception because education and socialization, for example the
dissertation review process, makes us mistrust genuine perception. I
think you use crude if explicit markers to judge texts.

>
> Is my intended meaning clearer? =A0Would it have been less offensive
> if phrased another way? =A0if so, perhaps you can suggest another
> wording that doesn't involve phrases you find ugly.

You are metaphorically a nurse in a torture chamber. Your question is
how you can continue to stay within parameters you've normed, not how
you can change.

>
> > It's a way of criticising a
> > person, and evading the matter he raises which is overused in
> > corporations in the US.
>
> > It's a lazy way of justifying sloppy thinking and self-centered
> > hermeneutics, at worse.
>
> > I see you are still quite the female enabler of male bullying. You
> > pour honey on people merely to attract the fire ants.
>
> > That's a metaphor, my dear. I teach English.
>
> And apparently you're still being patronizing. =A0

Does that mean "speaking or writing as if I were not a member of a
predefined class"? It seems to me, dear heart, that you've learned to
classify incoming texts according to broad and crude rules whose
crudity is masked by their high level. You're here to supplement the
bonehead errors of technicians in English while acknowledging their
"technical skills", evidence for which diminishes each year.

Therefore, you are prepared to see bonehead English, and girlie
writing, the latter characterized by your accurate orthography and
grammar. When I put the boot in, you're at a loss and ready to Call
Security, since like the Savage in Brave New World, I don't fit the
categories.


>
> (So much for my attempt to be on my best behavior in this thread.
> Sigh.)
>
> [ snip ]
>
> --
> B. L. Massingill
> ObDisclaimer: =A0I don't speak for my employers; they return the favor.

On Aug 3, 8:11=A0am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> (Maybe if I put the "OT" in parentheses rather than brackets it
> will survive better. =A0It appears that GG's posting interface
> strips off tags in brackets. =A0Anyone know why that might have
> seemed like a good idea??)
>
> In article <d04cc085-ca7d-4331-83ec-9f8f15f53...@z34g2000pro.googlegroups=
..com>,
>
> spinoza1111=A0<spinoza1...@yahoo.com> wrote:
> > On Jul 29, 9:16 pm, c...@tiac.net (Richard Harter) wrote:
> > > On Wed, 28 Jul 2010 21:27:45 -0700 (PDT),spinoza1111
>
> > > <spinoza1...@yahoo.com> wrote:
> > > >On Jul 25, 3:29=3DA0am, Seebs <usenet-nos...@seebs.net> wrote:
>
> [ snip ]
>
> > I'm not a stalker. Seebach unleashed a cybernetic mob on Herb Schildt
> > a number of years ago in order to advance himself in a career for
> > which Seebach is just not qualified, and I examined Seebach's attack
> > to find it to be garbage. My article about this matter was accepted
> > for publication in the competently moderated and prestigious group
> > comp.risks. The moderator was then spammed by the sort of cybernetic
> > mob Seebach had marshaled against Schildt and printed an apology for
> > accepting my article,
>
> Why? =A0If he was right to accept your article, why not print(?)
> a defense instead? =A0It seems to me that you're contradicting
> yourself here -- the moderation is competent, and yet the moderator
> succumbed to pressure?

Not a contradiction, an indication of the pressures Peter is under. I
dropped the matter after exchanging email in private with Peter
because I respect him and his time commitment. He has always treated
me with a decency and respect I don't see many people showing here.

>
> > but then accepted a second article on an
> > unrelated topic (the California payroll system crisis).
>
> Yes, I noticed that one, and .... =A0You know, it's possible that my
> reaction was influenced more than it should have been by the name
> of the author, but aside from drawing attention to an interesting
> item in the mainstream press, the post seemed to me to be, hm,
> long on speculation and short on content appropriate to the venue.

Peter welcomes speculation from experienced people in the field for
the speculation is a guide to further research. I WROTE a sequential
file payroll system in the 1970s and felt my speculations were for
this reason valuable, and he agreed. I saw managers claim that
"because" mainframe files were on disk, this meant that the programs
accessed records randomly when the actual software consisted of IBM
1401 code reading records sequentially under 360 emulation.


>
> My two cents' worth. =A0I notice the next two issues of the digest
> have contained some responses that -- eh, anyone who reads your
> post should probably read those too. =A0Just sayin'.

The responses are further speculation by people who were probably
managers and actually believed that because it's on disk it's accessed
randomly in all cases. There was just as much managerial bullshit in
the 1970s as there is today.

I'm saying the California IT manager doesn't know any more than I do
about what's going on in the guts of the software, and he's quoting an
enormous cost to be able to pay consultants (who won't be affected by
the pay cut) to come in, read code, and find out. It's speculative,
but also a key question. Most programmers spend quite a lot of time in
reading code to find out what's going on.

Furthermore, a payroll system lends itself naturally to sequential
processing since everyone back in the 1960s needed to be cut a check
at the same time. It would have been less and not more efficient to
process records randomly, since this would have been disk read head
motion all over creation for each employee. The optimal processing was
to do what's called a "join" based on the key, and most programmers
then and now did not and do not know how to do this.

To implement Schwarzenegger's diktat, we have to know where gross pay
"is" in this calculation, and it's dollars to donuts that it is in
several places. It's probably in different files for different classes
of employees. Worse, there may be software hacks to CHANGE gross pay
inside the gross to net calculation, not inserted fraudulently, but in
a scenario where the 1960s programmer was under pressure to change
gross pay for a set of employees defined by a rule.

It was in fact on Risks that I pointed out in 2003 that even in the
case of modern data base systems, the user perceives the system as an
escape from the Turing machine, with its unpredictably "halting
problem" and the consequent problem that we don't know what software
will do, to a flat and "simple" world of pure data, which CEOs think
they can handle. The joker in modern data base, as I pointed out in my
2003 Risks post on the Bush administration's TIA program, is that
business rules and stored procedures can be used by either lazy or
overpressured programmers to change the meaning of data fields such as
"gross pay" in the same secret way as was done inside Cobol or
assembler code of old.

You wish to label this "speculation", go ahead. I call it imagination.

>
> [ snip ]
>
> --
> B. L. Massingill
> ObDisclaimer: =A0I don't speak for my employers; they return the favor.

In article <dbc847da-0b30-4497-81ed-045652df2c72@t5g2000prd.googlegroups.com>,
spinoza1111  <spinoza1111@yahoo.com> wrote:
> On Aug 3, 8:14 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > In article <0356c8f5-eb5a-4c75-88d8-1e109f23a...@z30g2000prg.googlegroups.com>,
> >
> > spinoza1111 <spinoza1...@yahoo.com> wrote:
> > > On Aug 1, 4:13 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > > > In article <ee0d5533-2ac2-46fb-9be7-6c341904a...@y11g2000yqm.googlegroups.com>,
> > > > Shao Miller  <sha0.mil...@gmail.com> wrote:

[ snip ]

> > > > "Cultural differences" is a possibility.  I'm writing from the
> > > > US, which is where I grew up and currently reside.  I don't think
> > > > I'm much more provincial and US-centric than most people in this
> > > > country, but admittedly that's a low bar.
> >
> > > > To me you're coming across as someone who considers only the logical
> > > > meaning of words and not their potential emotional impact on readers.
> > > > I suspect that this puts you in a small minority, though I could be
> > > > wrong about that.  I also suspect that "logical meaning only" people
> > > > are apt to be more readily found in technical fields than elsewhere.
> >
> > > Actually, it is quite US centric of you to use ugly phrases such as
> > > "you are coming across as", which imply that the group knows the
> > > person better than he knows himself.
> >
> > Oh?  In my usage, "you are coming across as" means "you are being
> > perceived as" -- and really, isn't that something about which
> > the perceivers (the group) *do* know more than the perceived
> > (the person)?  Does it mean something else in your usage?
> 
> What is group knowledge? Is it something superior in all cases, or
> even in most cases, than the knowledge of an individual? And can it be
> greater than the sum of its parts? Can a group composed of inferior
> knowers know more than a good knower? Is what they produce even
> knowledge, or more like a text such as wikipedia? And isn't their
> knowledge/text in large measure itself measured by its fecundity, eg.,
> its production of new knowers who as such are individuals? And isn't
> it the case that while you folks might have "the tongues of men and
> angels" on your hard drives, most of you are bone stupid and getting
> more so?

Are there answers to my questions in that paragraph somewhere?  

> > You might notice also that I said "*to me* [emphasis added] you
> > are coming across as", so indeed it would seem to me that I'm
> > making claims only about my own perceptions rather than those of
> > some nebulous group, and surely I do know more about those?
> 
> I think you've lost touch with your ability to have a genuine
> perception because education and socialization, for example the
> dissertation review process, makes us mistrust genuine perception. I
> think you use crude if explicit markers to judge texts.

I have no idea what you mean by the first sentence, but at least
you have the courtesy to preface it with "I think".  

The second sentence -- eh, in some ways it's a fair cop, though
I'd claim that I'm aware that I assign more weight to trivia than
maybe I should and try to account for that in forming overall
opinions.

> > Is my intended meaning clearer?  Would it have been less offensive
> > if phrased another way?  if so, perhaps you can suggest another
> > wording that doesn't involve phrases you find ugly.
> 
> You are metaphorically a nurse in a torture chamber. Your question is
> how you can continue to stay within parameters you've normed, not how
> you can change.

So what you found ugly was *what* I said, rather than *how* I said
it?  That wasn't clear from "ugly phrase".

I'm mildly curious about whether there is some variant of English
in which all of Shao's remarks would be interpreted as he apparently
intended them -- one in which neither "claims" nor "invented" have
the negative connotations they have most of the people who have
commented here.  

[ snip ]

> > > That's a metaphor, my dear. I teach English.
> >
> > And apparently you're still being patronizing.  
> 
> Does that mean "speaking or writing as if I were not a member of a
> predefined class"? 

No.  (That is a meaning of "patronizing" of which I am unaware.)

It means addressing me as "my dear", and "dear heart", which
I perceive as being talked down to.  Perhaps those terms also have
some meaning in your usage that's different from what they in context
have in mine.

> It seems to me, dear heart, that you've learned to
> classify incoming texts according to broad and crude rules whose
> crudity is masked by their high level. 

Point addressed above.  

[ snip ]

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

In article <8d8924b1-5475-49ce-a381-81e7712fce2e@w15g2000pro.googlegroups.com>,
spinoza1111  <spinoza1111@yahoo.com> wrote:
> On Aug 3, 8:11 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > (Maybe if I put the "OT" in parentheses rather than brackets it
> > will survive better.  It appears that GG's posting interface
> > strips off tags in brackets.  Anyone know why that might have
> > seemed like a good idea??)
> >
> > In article <d04cc085-ca7d-4331-83ec-9f8f15f53...@z34g2000pro.googlegroups.com>,
> >
> > spinoza1111 <spinoza1...@yahoo.com> wrote:
> > > On Jul 29, 9:16 pm, c...@tiac.net (Richard Harter) wrote:
> > > > On Wed, 28 Jul 2010 21:27:45 -0700 (PDT),spinoza1111
> >
> > > > <spinoza1...@yahoo.com> wrote:
> > > > >On Jul 25, 3:29=A0am, Seebs <usenet-nos...@seebs.net> wrote:
> >
> > [ snip ]
> >
> > > I'm not a stalker. Seebach unleashed a cybernetic mob on Herb Schildt
> > > a number of years ago in order to advance himself in a career for
> > > which Seebach is just not qualified, and I examined Seebach's attack
> > > to find it to be garbage. My article about this matter was accepted
> > > for publication in the competently moderated and prestigious group
> > > comp.risks. The moderator was then spammed by the sort of cybernetic
> > > mob Seebach had marshaled against Schildt and printed an apology for
> > > accepting my article,
> >
> > Why?  If he was right to accept your article, why not print(?)
> > a defense instead?  It seems to me that you're contradicting
> > yourself here -- the moderation is competent, and yet the moderator
> > succumbed to pressure?
> 
> Not a contradiction, an indication of the pressures Peter is under. I
> dropped the matter after exchanging email in private with Peter
> because I respect him and his time commitment. He has always treated
> me with a decency and respect I don't see many people showing here.

His experience with you may be different from that of those who
post here, and that may be a factor.

> > > but then accepted a second article on an
> > > unrelated topic (the California payroll system crisis).
> >
> > Yes, I noticed that one, and ....  You know, it's possible that my
> > reaction was influenced more than it should have been by the name
> > of the author, but aside from drawing attention to an interesting
> > item in the mainstream press, the post seemed to me to be, hm,
> > long on speculation and short on content appropriate to the venue.
> 
> Peter welcomes speculation from experienced people in the field for
> the speculation is a guide to further research. I WROTE a sequential
> file payroll system in the 1970s and felt my speculations were for
> this reason valuable, and he agreed. 

Was there any suggestion, in the e-mail exchanged with PGN, that
you explicitly mention this experience in your post?  I think it
might have helped me assess your remarks more accurately, and indeed
reading through the post one more time, I think maybe I *was* unduly
harsh.

The one point where I'm still confused, though, is why you claim
NP completeness for an operation that it seems to me is no worse
than order-N-squared, with N being the number of employees.  (NP
completeness might be involved if one needed to consider all subsets
of the set of employees, but I'm not thinking of why that would be
necessary if the goal is to process many "change this employee's
salary" requests, even if only sequential reading of the data is
possible.)

> I saw managers claim that
> "because" mainframe files were on disk, this meant that the programs
> accessed records randomly when the actual software consisted of IBM
> 1401 code reading records sequentially under 360 emulation.
> 
> 
> >
> > My two cents' worth.  I notice the next two issues of the digest
> > have contained some responses that -- eh, anyone who reads your
> > post should probably read those too.  Just sayin'.
> 
> The responses are further speculation by people who were probably
> managers and actually believed that because it's on disk it's accessed
> randomly in all cases. There was just as much managerial bullshit in
> the 1970s as there is today.

If what you suspect about the background of the responders is true,
why were *their* posts accepted?  I've looked over those responses
again, by the way, and everyone making a point about the underlying
technology seems to me to have relevant experience.

> I'm saying the California IT manager doesn't know any more than I do
> about what's going on in the guts of the software, and he's quoting an
> enormous cost to be able to pay consultants (who won't be affected by
> the pay cut) to come in, read code, and find out. It's speculative,
> but also a key question. Most programmers spend quite a lot of time in
> reading code to find out what's going on.
> 
> Furthermore, a payroll system lends itself naturally to sequential
> processing since everyone back in the 1960s needed to be cut a check
> at the same time. It would have been less and not more efficient to
> process records randomly, since this would have been disk read head
> motion all over creation for each employee. The optimal processing was
> to do what's called a "join" based on the key, and most programmers
> then and now did not and do not know how to do this.
> 
> To implement Schwarzenegger's diktat, we have to know where gross pay
> "is" in this calculation, and it's dollars to donuts that it is in
> several places. It's probably in different files for different classes
> of employees. Worse, there may be software hacks to CHANGE gross pay
> inside the gross to net calculation, not inserted fraudulently, but in
> a scenario where the 1960s programmer was under pressure to change
> gross pay for a set of employees defined by a rule.
> 
> It was in fact on Risks that I pointed out in 2003 that even in the
> case of modern data base systems, the user perceives the system as an
> escape from the Turing machine, with its unpredictably "halting
> problem" and the consequent problem that we don't know what software
> will do, to a flat and "simple" world of pure data, which CEOs think
> they can handle. The joker in modern data base, as I pointed out in my
> 2003 Risks post on the Bush administration's TIA program, is that
> business rules and stored procedures can be used by either lazy or
> overpressured programmers to change the meaning of data fields such as
> "gross pay" in the same secret way as was done inside Cobol or
> assembler code of old.
> 
> You wish to label this "speculation", go ahead. I call it imagination.

Where to draw the line between informed speculation (which is,
and IMO should be, welcome in comp.risks) and wild guesses (which
IMO should not be) is probably to some extent a matter of opinion.
In this case it appears that I may have initially drawn it in
the wrong place, which I regret.

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

blmblm@myrealbox.com <blmblm@myrealbox.com> writes:
[...]
> Where to draw the line between informed speculation (which is,
> and IMO should be, welcome in comp.risks) and wild guesses (which
> IMO should not be) is probably to some extent a matter of opinion.
> In this case it appears that I may have initially drawn it in
> the wrong place, which I regret.

And I suggest, yet again, that "the wrong place" is comp.lang.c.

Yes, I see the "(OT)" in the subject, but ...

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

On Aug 2, 8:07=A0pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <14700fda-3ca2-4d27-a151-72607d3dd...@u26g2000yqu.googlegroups=
..com>,
> Shao Miller =A0<sha0.mil...@gmail.com> wrote:
> > On Jul 31, 4:13 pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > > Sure, I understood why you said "claims to have" rather than "has" --
> > > I do that myself when I don't really have any basis for knowing
> > > about the truth of the claim. =A0But I'm aware that for some people
> > > "claims to have" is not just a statement of fact, but one that casts
> > > doubt on the claim. =A0So I try to make it clear that I'm not trying
> > > to be insulting. =A0People [*] aren't always logical! =A0
>
> > > [*] There could be exceptions. =A0I'm not sure I've ever met one,
> > > but with, what, over 6 billion people on the planet, who can say ...
>
> > I agree. =A0I believe that people associating a claim of a claim with a
> > dispute for the latter claim will find their doubt-casting. =A0
>
> I don't understand what you mean by that sentence, but maybe it's
> not very important.
>
If I say "So-and-so claims such-and-such," that very statement is a
claim just as much as so-and-so's claim of such-and-such.

If one perceives a negative connotation, I find it likely that it is
due to their conditioning; sometimes cultural, sometimes personal.
Experiences cause conditioning.  A connotation isn't explicit, so
where does it come from?: A conditioned voice in the reader's head.
It says (very quickly), "I recognize that word in this context.  It
implies that there is doubt about the truth of what so-and-so stated."

I'd rather not drop the plain English "claims to have" from my typing
because some people associate such with doubt-casting, but I have
enough respect for others to do so. :)

> > "...who are you calling..." is another example of a perceived
> > attack. :S =A0
>
> Meaning "an example of perceiving an attack where none was meant"?
>
No, I didn't mean that.  You are correct; none was meant.  But the
intention is not accessible to you, it belongs to the author and only
the author knows the truth of their intent.  A point that might or
might not be worth taking away is that if we have some overlap in our
frames of reference, we can hopefully communicate more effectively.
"We are typing to one another" !=3D "Someone is calling someone else
wordy or a liar." :)  My impression from your posts is that you agree.

blmblm@myrealbox.com <blmblm@myrealbox.com> writes:
[103 lines deleted]

I believe that the e-mail address under which spinoza1111 posts
works.  If you want to have a debate with him, I suggest you do
so by e-mail.  Even with "(OT)" in the subject, I can think of no
reasonable justification for doing so in this newsgroup.

*Please* stop feeding the troll.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

On Aug 2, 8:08=A0pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <e743861c-57c3-4340-9965-47a89948a...@w30g2000yqw.googlegroups=
..com>,
> Shao Miller =A0<sha0.mil...@gmail.com> wrote:
>
> > On Jul 31, 5:53 pm, Seebs <usenet-nos...@seebs.net> wrote:
> > > On 2010-07-31, blmblm =A0myrealbox.com <blm...@myrealbox.com> wrote:
>
> > > > To me you're coming across as someone who considers only the logica=
l
> > > > meaning of words and not their potential emotional impact on reader=
s.
> > > > I suspect that this puts you in a small minority, though I could be
> > > > wrong about that. =A0I also suspect that "logical meaning only" peo=
ple
> > > > are apt to be more readily found in technical fields than elsewhere=
..
>
> > > This is not implausible. =A0Ironically, it took me years of study to
> > > start picking up connotations.
>
> > Thank for your acknowledging that fluency in English is not sufficient
> > cause for awareness of the negative connotations you perceive. =A0I
> > agree.
>
> I think, though, that Seebs's remark about how it took him a while
> may have less to do with the inherent difficulty of understanding
> about connotations than with the fact that he's -- well, he's
> said in other posts that he's something of an outlier on some
> measures related to social skills. =A0I'll let him explain further
> if he wants to.
>

> > > While it's true that connotations are often cultural, I am not aware
> > > of any culture in which accusing someone of having invented something
> > > when they cite to a text as showing it does not constitute an
> > > accusation of dishonesty. =A0I have spoken with English-speakers from
> > > many countries, and in this case, the connotation is not so much
> > > cultural as a question of Gricean maxims.
> > It's not an accusation. =A0It's a claim that there is no supporting
> > reference to the text given. =A0
>
> But that also *might* be an accusation, of a sort -- if you
> mean that no supporting evidence *exists*, rather than that no
> supporting evidence *has been presented*. =A0It's not clear to me
> which of these meanings is intended, though admittedly the latter
> might be somewhat more probable.
>
The original text goes:
---
Where I might say "invented" below, I additionally mean, "or have not
cited a reference which supports."
---
You might have missed a post.  It was apparently July 25th, 2010 at
5:42 pm, whatever that means.

> In any case, I agree with Seebs that in context "invented" is
> difficult to interpret as anything *but* an insult.
>
Well read what it says again, if you'd enjoy.  Read the
aforementioned, possibly-missed post, if you'd enjoy.

> How did we get into *this* mess .... =A0You wrote in another post
> the following:
>
> >>You have invented the requirement for the pointer operand to "point to
> >>an object". =A0Consider a function pointer. =A0You have invented
> >>supposedly undefined behaviour. =A0In this Method #1, you have not
> >>convinced me, I'm sorry to say. =A0I was hopeful. =A0It might even be o=
f
> >>no consequence to you whether I've been convinced or not. =A0That's
> >>fine.
>
> >>Where I might say "invented" below, I additionally mean, "or have not
> >>cited a reference which supports."
>
> That second paragraph -- I'm guessing that was your attempt
> to clarify your meaning, but the use of "below" introduces at
> least some ambiguity about whether it applies to the preceding
> paragraph, and I'm just not sure what "additionally" means here.
> (I'd have left it out.)
>
In the aforementioned, possibly-missed post, I typed:
---
I had hoped that that was clear when I added to what I meant by
"invented."  When I first wrote "invented" and thought about it, I
thought, "that's too harsh."  Hopefully that can put to rest the
argument regarding familiarity with English speakers' use of English.
I added the additional meaning to try to help to clarify what was
meant.  I did not scroll up and type it out as high as I meant to,
before the first use of "invented."  It appears that even the
additional meaning was not enough to clarify.
---
Now perhaps you can see why it's important to be tolerant.  A trivial
mistake leads to an ambiguity.  It's really not easy to type and
review inside the 11-row box that Google gives for posting via a web
page interface.

Invented.  Made up.  Prove it.  How so?  I don't see it.  Oh yeah?
Where does that come from?

Look at Peter's original post:
---
On 2010-07-23, Shao Miller <sha0.mil...@gmail.com>  wrote:

> We agreed that it's possible that that text might be imprecise, and
> might need to be addressed, did we not?  But it's also possible that
> it's precise, and there is no undefined behaviour until casting to
> '(void)'.

> Would you agree?

No.  It is adequately precise, adequately clear, and the undefined
behavior
is unambiguous.

-s
---
Fine.  He doesn't agree.  So I probe:
---
On Jul 23, 2:02 pm, Seebs <usenet-nos...@seebs.net>  wrote:

> No.  It is adequately precise, adequately clear, and the undefined behavi=
or
> is unambiguous.

Thank you for your opinion.  I would have also appreciated some
reasoning, in order to help to convince myself of this.  The opinion
is appreciated regardless of the lack of reasoning.  Poll-wise,
dereferencing a null pointer is undefined behaviour during
evaluation.  Reason-wise, it's still incomplete, for me.
---
Then he provides reasoning.  I perceive some statements that lack
accessible substance from what's been presented in the discussion thus
far.  So "invented" seemed pretty appropriate to me.  How else could
it be considered shared reasoning if all parties cannot access the
substance?  The term might have been harsh, so I attempted to clarify
within the parentheses.  Then he says "invented" is an insult and he
also chooses to ignore my direct posts ever after.  I apologize, to no
avail.  Others offer agreement with the usage being insulting.  Fine.
An experience in what is and what is not civil discussion by the
beliefs of some people, while trying to discuss C.

> How would I reword ....
>
> The first sentence could read "You state/imply a requirement ...."
> And then you could go on to ask whether he can cite a reference
> for this claim.
>
Right.  Fine.

On Aug 2, 10:46=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-08-03, blmblm =A0myrealbox.com <blm...@myrealbox.com> wrote:
> I wrote:
> >> It's not an accusation. =A0It's a claim that there is no supporting
> >> reference to the text given. =A0
> > But that also *might* be an accusation, of a sort -- if you
> > mean that no supporting evidence *exists*, rather than that no
> > supporting evidence *has been presented*. =A0It's not clear to me
> > which of these meanings is intended, though admittedly the latter
> > might be somewhat more probable.
>
> "Invented" implies that the supporting evidence does not *exist*. =A0If i=
t
> were extant, but unpresented, you wouldn't be inventing it.
>
Existence versus presentation, you say.  Well then understand what
happens when reality is bounded by what's shared.  Presentation
defines what exists.  Your bounds were not my expected bounds.  Very
simple.  That doesn't mean I'm calling you a liar, it means "it's not
present."

>
> And for what it's worth, I did, as I recall, point to the statements that
> the lack of a definition shows undefined behavior, which is the point tha=
t
> was apparently missing. =A0If we are told that:
>
> * If A, then the result is X.
> * If B, then the result is Y.
>
> this means that, if !(A||B), the behavior is undefined, because no defini=
tion
> was provided, and in the absence of a definition, things are undefined.
>
You did not point to statements in the C Standard draft regarding this
(which is, of course, 4,p2) but you did make those statements.  I
never disputed those statements.  What I did claim was that it was
_defined_ by the C Standard draft, and I offered how.

That's fine.

On Aug 2, 5:14=A0pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <0356c8f5-eb5a-4c75-88d8-1e109f23a...@z30g2000prg.googlegroups=
..com>,
> > That's a metaphor, my dear. I teach English.
>
> And apparently you're still being patronizing. =A0
>
> (So much for my attempt to be on my best behavior in this thread.
> Sigh.)

Stop the presses! who knew spinoza would act like a jackass yet again?

Well at least you've confined Cirque du B.L. to just this thread.

On Aug 4, 7:17=A0pm, Keith Thompson <ks...@mib.org> wrote:
> ...
> I can think of no
> reasonable justification for doing so in this newsgroup.
> ...
Keith, I'm afraid that I have no justification for my back-and-forth
regarding "claims to have" and "invented" being civil/uncivil.  Thanks
for bringing up "doing so in this newsgroup."  Sorry.

And now, back to C... :)

On Aug 5, 7:17=A0am, Keith Thompson <ks...@mib.org> wrote:
> blm...@myrealbox.com <blm...@myrealbox.com> writes:
>
> [103 lines deleted]
>
> I believe that the e-mail address under whichspinoza1111posts
> works. =A0If you want to have a debate with him, I suggest you do
> so by e-mail. =A0Even with "(OT)" in the subject, I can think of no
> reasonable justification for doing so in this newsgroup.
>
> *Please* stop feeding the troll.

"Please don't talk to the Jew"
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org =A0<http://www.ghoti.net/~=
kst>
> Nokia
> "We must do something. =A0This is something. =A0Therefore, we must do thi=
s."
> =A0 =A0 -- Antony Jay and Jonathan Lynn, "Yes Minister"

In article <203a2e7e-69c1-4ae2-99b9-6b25607fd56f@i18g2000pro.googlegroups.com>,
spinoza1111  <spinoza1111@yahoo.com> wrote:
>On Aug 5, 7:17�am, Keith Thompson <ks...@mib.org> wrote:
>> blm...@myrealbox.com <blm...@myrealbox.com> writes:
>>
>> [103 lines deleted]
>>
>> I believe that the e-mail address under whichspinoza1111posts
>> works. �If you want to have a debate with him, I suggest you do
>> so by e-mail. �Even with "(OT)" in the subject, I can think of no
>> reasonable justification for doing so in this newsgroup.
>>
>> *Please* stop feeding the troll.
>
>"Please don't talk to the Jew"

Agreed.  It really is astounding to see Kiki argue so passionately
against people using this newsgroup as they choose - and to talk to whom
they choose.

You really have to ask why?  What is it to him???  Seriously, why should
he care?

(Especially now that Kiki openly [and repeatedly] claims to be using a
killfile.  At least in the olden days, when Kiki claimed that using a
killfile was a moral failing - and thus, of course, that he did not use
one - there was a glimmer of sense in his "protect the newsgroup"
stance.)

Quite seriously, I would really like to see Kiki's defense to this.

-- 
"We should always be disposed to believe that which appears to us to be
white is really black, if the hierarchy  of the church so decides." 

    - Saint Ignatius Loyola (1491-1556) Founder of the Jesuit Order -

On Aug 5, 4:51=A0am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <8d8924b1-5475-49ce-a381-81e7712fc...@w15g2000pro.googlegroups=
..com>,
>
>
>
>
>
> spinoza1111=A0<spinoza1...@yahoo.com> wrote:
> > On Aug 3, 8:11 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > > (Maybe if I put the "OT" in parentheses rather than brackets it
> > > will survive better. =A0It appears that GG's posting interface
> > > strips off tags in brackets. =A0Anyone know why that might have
> > > seemed like a good idea??)
>
> > > In article <d04cc085-ca7d-4331-83ec-9f8f15f53...@z34g2000pro.googlegr=
oups.com>,
>
> > >spinoza1111<spinoza1...@yahoo.com> wrote:
> > > > On Jul 29, 9:16 pm, c...@tiac.net (Richard Harter) wrote:
> > > > > On Wed, 28 Jul 2010 21:27:45 -0700 (PDT),spinoza1111
>
> > > > > <spinoza1...@yahoo.com> wrote:
> > > > > >On Jul 25, 3:29=3DA0am, Seebs <usenet-nos...@seebs.net> wrote:
>
> > > [ snip ]
>
> > > > I'm not a stalker. Seebach unleashed a cybernetic mob on Herb Schil=
dt
> > > > a number of years ago in order to advance himself in a career for
> > > > which Seebach is just not qualified, and I examined Seebach's attac=
k
> > > > to find it to be garbage. My article about this matter was accepted
> > > > for publication in the competently moderated and prestigious group
> > > > comp.risks. The moderator was then spammed by the sort of cyberneti=
c
> > > > mob Seebach had marshaled against Schildt and printed an apology fo=
r
> > > > accepting my article,
>
> > > Why? =A0If he was right to accept your article, why not print(?)
> > > a defense instead? =A0It seems to me that you're contradicting
> > > yourself here -- the moderation is competent, and yet the moderator
> > > succumbed to pressure?
>
> > Not a contradiction, an indication of the pressures Peter is under. I
> > dropped the matter after exchanging email in private with Peter
> > because I respect him and his time commitment. He has always treated
> > me with a decency and respect I don't see many people showing here.
>
> His experience with you may be different from that of those who
> post here, and that may be a factor.

He is more intelligent, more qualified, and above all a better person
than nearly anyone here, and if we may consider that there is a
collective persona in comp.risks, he is, as Hamlet said, "Hyperion to
a Satyr" with respect to that monster.
>
> > > > but then accepted a second article on an
> > > > unrelated topic (the California payroll system crisis).
>
> > > Yes, I noticed that one, and .... =A0You know, it's possible that my
> > > reaction was influenced more than it should have been by the name
> > > of the author, but aside from drawing attention to an interesting
> > > item in the mainstream press, the post seemed to me to be, hm,
> > > long on speculation and short on content appropriate to the venue.
>
> > Peter welcomes speculation from experienced people in the field for
> > the speculation is a guide to further research. I WROTE a sequential
> > file payroll system in the 1970s and felt my speculations were for
> > this reason valuable, and he agreed.
>
> Was there any suggestion, in the e-mail exchanged with PGN, that
> you explicitly mention this experience in your post? =A0I think it
> might have helped me assess your remarks more accurately, and indeed
> reading through the post one more time, I think maybe I *was* unduly
> harsh.

I don't believe you're here to judge other people. You lack standing
and qualifications.

Peter was a source for my book, "Build Your Own .Net Language and
Compiler" (Apress 2004), and he read the review copy, it appears from
his email thank you note.

This book described my experience in mainframe platforms.


>
> The one point where I'm still confused, though, is why you claim
> NP completeness for an operation that it seems to me is no worse

Actually, I never made that claim. However, matching two sets using
linear pairwise search is indeed NP complete.

But that's not what minimally competent programmer would do when using
DASD in the old days while processing a payroll as a "batch", which as
I said would be necessary given accounting, not data processing,
constraints. He would use "employee ID" as a key to randomly access
the "employee master record". But this, as I said, would cause read
head motion for each record in the batch, and this is much slower than
sequentially proceeding, with minimal head motion, through two sorted
files. Paradoxically, when using batch-oriented payroll accounting,
you needed to use DASD as if it were sequential.


> than order-N-squared, with N being the number of employees. =A0(NP
> completeness might be involved if one needed to consider all subsets
> of the set of employees, but I'm not thinking of why that would be
> necessary if the goal is to process many "change this employee's
> salary" requests, even if only sequential reading of the data is
> possible.)

The formula would have nothing to do with this. For a random DASD
access for each payroll "ticket", your time formula is N*A where N is
the size of the incoming ticket or hours worked record and A is the
average seek time.



>
> > I saw managers claim that
> > "because" mainframe files were on disk, this meant that the programs
> > accessed records randomly when the actual software consisted of IBM
> > 1401 code reading records sequentially under 360 emulation.
>
> > > My two cents' worth. =A0I notice the next two issues of the digest
> > > have contained some responses that -- eh, anyone who reads your
> > > post should probably read those too. =A0Just sayin'.
>
> > The responses are further speculation by people who were probably
> > managers and actually believed that because it's on disk it's accessed
> > randomly in all cases. There was just as much managerial bullshit in
> > the 1970s as there is today.
>
> If what you suspect about the background of the responders is true,
> why were *their* posts accepted? =A0I've looked over those responses
> again, by the way, and everyone making a point about the underlying
> technology seems to me to have relevant experience.

Because unlike me, Peter Neumann believes that managers know their
jobs.

>
>
>
>
>
> > I'm saying the California IT manager doesn't know any more than I do
> > about what's going on in the guts of the software, and he's quoting an
> > enormous cost to be able to pay consultants (who won't be affected by
> > the pay cut) to come in, read code, and find out. It's speculative,
> > but also a key question. Most programmers spend quite a lot of time in
> > reading code to find out what's going on.
>
> > Furthermore, a payroll system lends itself naturally to sequential
> > processing since everyone back in the 1960s needed to be cut a check
> > at the same time. It would have been less and not more efficient to
> > process records randomly, since this would have been disk read head
> > motion all over creation for each employee. The optimal processing was
> > to do what's called a "join" based on the key, and most programmers
> > then and now did not and do not know how to do this.
>
> > To implement Schwarzenegger's diktat, we have to know where gross pay
> > "is" in this calculation, and it's dollars to donuts that it is in
> > several places. It's probably in different files for different classes
> > of employees. Worse, there may be software hacks to CHANGE gross pay
> > inside the gross to net calculation, not inserted fraudulently, but in
> > a scenario where the 1960s programmer was under pressure to change
> > gross pay for a set of employees defined by a rule.
>
> > It was in fact on Risks that I pointed out in 2003 that even in the
> > case of modern data base systems, the user perceives the system as an
> > escape from the Turing machine, with its unpredictably "halting
> > problem" and the consequent problem that we don't know what software
> > will do, to a flat and "simple" world of pure data, which CEOs think
> > they can handle. The joker in modern data base, as I pointed out in my
> > 2003 Risks post on the Bush administration's TIA program, is that
> > business rules and stored procedures can be used by either lazy or
> > overpressured programmers to change the meaning of data fields such as
> > "gross pay" in the same secret way as was done inside Cobol or
> > assembler code of old.
>
> > You wish to label this "speculation", go ahead. I call it imagination.
>
> Where to draw the line between informed speculation (which is,
> and IMO should be, welcome in comp.risks) and wild guesses (which
> IMO should not be) is probably to some extent a matter of opinion.
> In this case it appears that I may have initially drawn it in
> the wrong place, which I regret.

You've painted yourself using corporatese and unexamined phrases into
a logical corner.

Read George Orwell's essay "Politics and the English Language". "Never
use a metaphor, simile, or other figure of speech which you are used
to seeing in print." "A matter of opinion" is a received, hackneyed
figure of speech used by people who haven't disambiguated opinion from
status. It's a chunk of words that stops thought.

You see, you've unintentionally said that "where to draw the line
between informed speculation and wild guesses [opinion] is a matter of
opinion". This is an infinite regress.

It's simply untrue that corporations can any way through
administrative procedures identify "mere opinion". You can safely
predict that "scientists" at BP will now say that the oil is "gone"
from the Gulf of Mexico despite the fact that this "informed,
objective viewpoint" is a physical impossibility in physical law
(conservation of matter) and a shocking offense to Gulf fishermen who
have lost their livelihoods. I worked at Amoco, now part of BP, in OS
development and realized that Job One was lying to the oil boys (who
were vicious, drunken thugs) about status.

Absent a kind of maturity which is a termination offense in many
corporations, it is impossible to distinguish people and the quality
of their opinions: there are no individuals, just in duh viduals as we
see here.

It's not my opinion that data processing managers did command
programmers to use the key to look up each employee master when
processing large sequential files. This is what they did in my lived
experience because, shortly after the "structured programming"
innovation of the early 1970s, they insisted on dominating, usually
boorishly, structured walkthroughs despite the fact that this was
discouraged in the literature, and nearly all of them were instances
of the famous Peter Principle: they'd been made manager because they
were incompetent programmmers.

To them, the (rather simple) subtleties and gotchas of a properly
coded and walkable-throughable sequential match were "too complicated"
and ergo "inefficient" because they did not understand it. They would
force programmers to do a random seek.

Nor am I generalizing from insufficient data points. I'm a consultant
whose worked worldwide. This is what happened in reality. It's not
"opinion" at all.

>
> --
> B. L. Massingill
> ObDisclaimer: =A0I don't speak for my employers; they return the favor.

On Aug 5, 8:47=A0pm, gaze...@shell.xmission.com (Kenny McCormack) wrote:
> In article <203a2e7e-69c1-4ae2-99b9-6b25607fd...@i18g2000pro.googlegroups=
..com>,
>
> spinoza1111=A0<spinoza1...@yahoo.com> wrote:
> >On Aug 5, 7:17=A0am, Keith Thompson <ks...@mib.org> wrote:
> >> blm...@myrealbox.com <blm...@myrealbox.com> writes:
>
> >> [103 lines deleted]
>
> >> I believe that the e-mail address under whichspinoza1111posts
> >> works. =A0If you want to have a debate with him, I suggest you do
> >> so by e-mail. =A0Even with "(OT)" in the subject, I can think of no
> >> reasonable justification for doing so in this newsgroup.
>
> >> *Please* stop feeding the troll.
>
> >"Please don't talk to the Jew"
>
> Agreed. =A0It really is astounding to see Kiki argue so passionately
> against people using this newsgroup as they choose - and to talk to whom
> they choose.
>
> You really have to ask why? =A0What is it to him??? =A0Seriously, why sho=
uld
> he care?

For Hecuba?
What's Hecuba to him, or he to Hecuba,
That he should weepe for her?

(Shakespeare, Hamlet)

I think, egocentrically perhaps, that Kiki and Seebach (who's admitted
that he labours to understand and can't code worth dick) are enraged
by the way I waltz in here and either understand, or act as if I
understand, their holy mysteries of the Temple of Doom. I learned
computing as an elaborate draft dodging scheme (that got out of hand)
while preserving other talents including the ability to construct and
understand complex sentences over a low upper bound of complexity, the
ability to draw the human figure, and the ability, which I still have,
to run long distance.

This bothers people who in fact labour to understand simple concepts,
learn them in one formulaic way, and are enraged if someone talks of
them either in a different way or in a gay or amusing way.


>
> (Especially now that Kiki openly [and repeatedly] claims to be using a
> killfile. =A0At least in the olden days, when Kiki claimed that using a
> killfile was a moral failing - and thus, of course, that he did not use
> one - there was a glimmer of sense in his "protect the newsgroup"
> stance.)
>
> Quite seriously, I would really like to see Kiki's defense to this.

I think he's full of hate, and I'm sick of him.

>
> --
> "We should always be disposed to believe that which appears to us to be
> white is really black, if the hierarchy =A0of the church so decides."
>
> =A0 =A0 - Saint Ignatius Loyola (1491-1556) Founder of the Jesuit Order -

On Aug 5, 4:50=A0am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <dbc847da-0b30-4497-81ed-045652df2...@t5g2000prd.googlegroups.=
com>,
>
> spinoza1111=A0<spinoza1...@yahoo.com> wrote:
> > On Aug 3, 8:14 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > > In article <0356c8f5-eb5a-4c75-88d8-1e109f23a...@z30g2000prg.googlegr=
oups.com>,
>
> > >spinoza1111<spinoza1...@yahoo.com> wrote:
> > > > On Aug 1, 4:13 am, blm...@myrealbox.com <blm...@myrealbox.com> wrot=
e:
> > > > > In article <ee0d5533-2ac2-46fb-9be7-6c341904a...@y11g2000yqm.goog=
legroups.com>,
> > > > > Shao Miller =A0<sha0.mil...@gmail.com> wrote:
>
> [ snip ]
>
>
>
>
>
> > > > > "Cultural differences" is a possibility. =A0I'm writing from the
> > > > > US, which is where I grew up and currently reside. =A0I don't thi=
nk
> > > > > I'm much more provincial and US-centric than most people in this
> > > > > country, but admittedly that's a low bar.
>
> > > > > To me you're coming across as someone who considers only the logi=
cal
> > > > > meaning of words and not their potential emotional impact on read=
ers.
> > > > > I suspect that this puts you in a small minority, though I could =
be
> > > > > wrong about that. =A0I also suspect that "logical meaning only" p=
eople
> > > > > are apt to be more readily found in technical fields than elsewhe=
re.
>
> > > > Actually, it is quite US centric of you to use ugly phrases such as
> > > > "you are coming across as", which imply that the group knows the
> > > > person better than he knows himself.
>
> > > Oh? =A0In my usage, "you are coming across as" means "you are being
> > > perceived as" -- and really, isn't that something about which
> > > the perceivers (the group) *do* know more than the perceived
> > > (the person)? =A0Does it mean something else in your usage?
>
> > What is group knowledge? Is it something superior in all cases, or
> > even in most cases, than the knowledge of an individual? And can it be
> > greater than the sum of its parts? Can a group composed of inferior
> > knowers know more than a good knower? Is what they produce even
> > knowledge, or more like a text such as wikipedia? And isn't their
> > knowledge/text in large measure itself measured by its fecundity, eg.,
> > its production of new knowers who as such are individuals? And isn't
> > it the case that while you folks might have "the tongues of men and
> > angels" on your hard drives, most of you are bone stupid and getting
> > more so?
>
> Are there answers to my questions in that paragraph somewhere? =A0

No. I want YOU to start THINKING for a change.

>
> > > You might notice also that I said "*to me* [emphasis added] you
> > > are coming across as", so indeed it would seem to me that I'm
> > > making claims only about my own perceptions rather than those of
> > > some nebulous group, and surely I do know more about those?
>
> > I think you've lost touch with your ability to have a genuine
> > perception because education and socialization, for example the
> > dissertation review process, makes us mistrust genuine perception. I
> > think you use crude if explicit markers to judge texts.
>
> I have no idea what you mean by the first sentence, but at least
> you have the courtesy to preface it with "I think". =A0

You may supply that prefix to all my paragraphs. I think, therefore I
am.
>
> The second sentence -- eh, in some ways it's a fair cop, though
> I'd claim that I'm aware that I assign more weight to trivia than
> maybe I should and try to account for that in forming overall
> opinions.

I think you may find this habit hard to break. Doing so has become
embedded within bureaucratic structures because thinking is considered
waste motion.

>
> > > Is my intended meaning clearer? =A0Would it have been less offensive
> > > if phrased another way? =A0if so, perhaps you can suggest another
> > > wording that doesn't involve phrases you find ugly.
>
> > You are metaphorically a nurse in a torture chamber. Your question is
> > how you can continue to stay within parameters you've normed, not how
> > you can change.
>
> So what you found ugly was *what* I said, rather than *how* I said
> it? =A0That wasn't clear from "ugly phrase".
>
> I'm mildly curious about whether there is some variant of English
> in which all of Shao's remarks would be interpreted as he apparently
> intended them -- one in which neither "claims" nor "invented" have
> the negative connotations they have most of the people who have
> commented here. =A0

Like the Obama administration, you consistently try to split the
difference and deny that there is real conflict. By so doing, Obama
enabled Glenn Beck in the same way the co-alcoholic denies the reality
of say her husband's drinking by continuing to pretend "we're a
family".

You end up supporting the psychotic "regulars" because you have no
distinct POV and you blame their victims for somehow not adjusting the
cut of their jib. We want people like Seebach, Kiki and Heathfield to
bug out, because they're bullies and not competent.


>
> [ snip ]
>
> > > > That's a metaphor, my dear. I teach English.
>
> > > And apparently you're still being patronizing. =A0
>
> > Does that mean "speaking or writing as if I were not a member of a
> > predefined class"?
>
> No. =A0(That is a meaning of "patronizing" of which I am unaware.)
>
> It means addressing me as "my dear", and "dear heart", which
> I perceive as being talked down to. =A0Perhaps those terms also have
> some meaning in your usage that's different from what they in context
> have in mine.

They do, in fact. Feminism, which started out as a humanism and which
did so much good, ALSO evolved into a modern mythos (by which I mean a
structured collection of urban legends, tics, and bullshit).

This mythos excludes a hermeneutic which would reflect what is, in
fact, the case.

That I know full well that men of my father's generation would use
these phrases (as in that TV series Mad Men) to enforce their
financial power and control. Back in the day, they were the bread
winners, and if the little lady looked cross-eyed at them they took a
mistress or a flat in the city, and that was that.

News flash, dear heart. Things have changed, haven't they.

While knowing this, I use the phrases self-mockingly, ironically in
order to lighten the mood of this newsgroup, which overall mood is
somewhat to the east of East Hell.

And where is it written that they do not preserve their basic
connotation of "friend or potential friend, with whom there might be,
if not friendship, a modus vivendi".

It's not about sex. Catherine MacKinnon wrote that, and I think she's
a rip snorting feminist.

It is about power, sez that gal, and here we have, or should have, no
power over each other.

Finally, I'm not going to stop when YOU say NOTHING to fucking Kiki
when he uses language in which "troll" might as well be "Jew", my
dear. Your type in corporations makes a specialty of never speaking
truth to power, only "counseling" the victims in ways to Succeed with
a lot of New Age English major mumbo jumbo.

My boss at princeton called me cutie because I am cute, especially
when she'd see me go out for a run. You think I'd try to nail her for
"sexual harassment"? Not on your life, because she stood up for me and
assigned me to help Nash.
>
> > It seems to me, dear heart, that you've learned to
> > classify incoming texts according to broad and crude rules whose
> > crudity is masked by their high level.
>
> Point addressed above. =A0
>
> [ snip ]
>
> --
> B. L. Massingill
> ObDisclaimer: =A0I don't speak for my employers; they return the favor.

On Aug 5, 3:47=A0pm, gaze...@shell.xmission.com (Kenny McCormack) wrote:
>
> Quite seriously, I would really like to see Kiki's defense to this.
>
Well I wouldn't. Why should I care who Richard Heathfield chooses to
read?

On Thu, 5 Aug 2010 07:28:33 -0700 (PDT), spinoza1111
<spinoza1111@yahoo.com> wrote:

>I think, egocentrically perhaps, that Kiki and Seebach (who's admitted
>that he labours to understand and can't code worth dick)

>> Quite seriously, I would really like to see Kiki's defense to this.

>I think he's full of hate, and I'm sick of him.

Some people think a troll is anyone saying anything they don't like, or
posting off topic.  Though I don't agree, I have encountered trolls.

Criticism is one thing.  But when it's mean and personal, it's trolling.

Have a nice day.


-- 
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
 

On Aug 6, 12:55=A0am, John Kelly <j...@isp2dial.com> wrote:
> On Thu, 5 Aug 2010 07:28:33 -0700 (PDT),spinoza1111
>
> <spinoza1...@yahoo.com> wrote:
> >I think, egocentrically perhaps, that Kiki and Seebach (who's admitted
> >that he labours to understand and can't code worth dick)
> >> Quite seriously, I would really like to see Kiki's defense to this.
> >I think he's full of hate, and I'm sick of him.
>
> Some people think a troll is anyone saying anything they don't like, or
> posting off topic. =A0Though I don't agree, I have encountered trolls.
>
> Criticism is one thing. =A0But when it's mean and personal, it's trolling=
..

Whoa. Trying to get at the truth using adequate complexity is "mean
and personal" only to the ignorant, or people who don't like the
truth. blm is probably a wonderful person. The problem is that I know
too many wonderful people who were socialized to enable bullying and
were used by the bullies and tossed aside.

I refuse to accept accusations of "meanness" given the way people can
say foul things here and use "troll" isomorphic to Jew and get away
with it, as long as they neither apologize nor explain.

>
> Have a nice day.
>
> --
> Web mail, POP3, and SMTPhttp://www.beewyz.com/freeaccounts.php

On Thu, 5 Aug 2010 19:14:07 -0700 (PDT), spinoza1111
<spinoza1111@yahoo.com> wrote:

>On Aug 6, 12:55�am, John Kelly <j...@isp2dial.com> wrote:

>> Criticism is one thing. �But when it's mean and personal, it's trolling.
>
>Whoa. Trying to get at the truth using adequate complexity is "mean
>and personal" only to the ignorant, or people who don't like the
>truth. blm is probably a wonderful person. The problem is that I know
>too many wonderful people who were socialized to enable bullying and
>were used by the bullies and tossed aside.

>I refuse to accept accusations of "meanness" given the way people can
>say foul things here and use "troll" isomorphic to Jew and get away
>with it, as long as they neither apologize nor explain.

But why get personal with these people.  It's just a big waste of time.
You can't reform the incorrigible.  And you can't defeat them online.


-- 
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
 

On Aug 6, 1:06=A0pm, John Kelly <j...@isp2dial.com> wrote:
> On Thu, 5 Aug 2010 19:14:07 -0700 (PDT),spinoza1111
>
> <spinoza1...@yahoo.com> wrote:
> >On Aug 6, 12:55=A0am, John Kelly <j...@isp2dial.com> wrote:
> >> Criticism is one thing. =A0But when it's mean and personal, it's troll=
ing.
>
> >Whoa. Trying to get at the truth using adequate complexity is "mean
> >and personal" only to the ignorant, or people who don't like the
> >truth. blm is probably a wonderful person. The problem is that I know
> >too many wonderful people who were socialized to enable bullying and
> >were used by the bullies and tossed aside.
> >I refuse to accept accusations of "meanness" given the way people can
> >say foul things here and use "troll" isomorphic to Jew and get away
> >with it, as long as they neither apologize nor explain.
>
> But why get personal with these people. =A0It's just a big waste of time.
> You can't reform the incorrigible. =A0And you can't defeat them online.

That's what they say. I am beginning to see this attitude in the large
as a form of what I've called "codependence" or "enabling".

You CAN defeat them online. If you are a literate person, you know
what constitutes a valid and well-written article, but you also know
that most people, especially software people, aren't very literate.
You know their judgements are crap. You know you've won.


>
> --
> Web mail, POP3, and SMTPhttp://www.beewyz.com/freeaccounts.php

On Aug 6, 1:06=A0pm, John Kelly <j...@isp2dial.com> wrote:
> On Thu, 5 Aug 2010 19:14:07 -0700 (PDT),spinoza1111
>
> <spinoza1...@yahoo.com> wrote:
> >On Aug 6, 12:55=A0am, John Kelly <j...@isp2dial.com> wrote:
> >> Criticism is one thing. =A0But when it's mean and personal, it's troll=
ing.
>
> >Whoa. Trying to get at the truth using adequate complexity is "mean
> >and personal" only to the ignorant, or people who don't like the
> >truth. blm is probably a wonderful person. The problem is that I know
> >too many wonderful people who were socialized to enable bullying and
> >were used by the bullies and tossed aside.
> >I refuse to accept accusations of "meanness" given the way people can
> >say foul things here and use "troll" isomorphic to Jew and get away
> >with it, as long as they neither apologize nor explain.
>
> But why get personal with these people. =A0It's just a big waste of time.
> You can't reform the incorrigible. =A0And you can't defeat them online.

They get very personal with one when they greet your contributions, as
Kiki does to some people (myself included) by saying "please ignore
the troll". I cannot imagine being so desensitized, so dehumanized
that you'd take it lying down if you walked into a conference room or
social affair and someone said that.

It would make a big difference here if enough people started to
confront Heathfield, Kiki and Seebach on their behavior, but ever
since the 1970s, at least, people have become sufficiently dehumanized
by hyper-individualism to figure that it's a loser's game to be
"altruistic".

The result? These discussion groups are worthless for their intended
purpose.


>
> --
> Web mail, POP3, and SMTPhttp://www.beewyz.com/freeaccounts.php

On 5 Aug, 17:55, John Kelly <j...@isp2dial.com> wrote:
> On Thu, 5 Aug 2010 07:28:33 -0700 (PDT), spinoza1111
> <spinoza1...@yahoo.com> wrote:

<snip stuff>

<snip more stuff>

> Some people think a troll is anyone saying anything they don't like, or
> posting off topic. =A0Though I don't agree, I have encountered trolls.
>
> Criticism is one thing. =A0But when it's mean and personal, it's trolling=
..
>
> Have a nice day.

when he spouts nonsense to get attention, that's trolling. It's up to
you of course but I don't think you have much to gain my encouraging
him.  And pretty much any response is encouragment (including this
one!).

Although kenny & spinoza pretend not to understand most kill files
block a poster not the responses to that poster. So some people have
reason to be irritated by responses to known trolls. If it weren't for
the reponses they'd remain blissfully unaware of their existence. Oh
joy.



--

No word matters.
But man forgets reality and remembers words.
The more words he remembers, the cleverer do his fellows esteem him.
      "Lord of Light" Roger Zelazny

On 2010-08-06, John Kelly <jak@isp2dial.com> wrote:
> But why get personal with these people.  It's just a big waste of time.
> You can't reform the incorrigible.  And you can't defeat them online.

There is a certain amount of irony to be had here, were you to look at
the last ten or twenty years of Usenet postings by Edward Nilges.  :)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

In article <ug5n56dvp6470eo66fajv91f1os3sfs0r3@4ax.com>,
John Kelly  <jak@isp2dial.com> wrote:
....
>But why get personal with these people.  It's just a big waste of time.
>You can't reform the incorrigible.  And you can't defeat them online.

The short answer is: Why ask why?  I.e., you'll never get anywhere
trying to figure out why people bother posting to online fora; we each
have our own reasons and (presumably) these reasons are sufficient for
(each of) us.

The longer answer is that none of the combatants are fighting with each
other - they are fighting for the "hearts and minds" of the spectators -
the "people at home".  This form of battle is often referred to as
"talking around people".  That is, Kiki and his friends never actually
engage with us, nor we with them.  Each side is really talking to their
own supporters - talking around the nominal "target".

My own view is that you don't bother arguing with nutjobs (like Kiki and
friends in this ng and the various political nutjobs in the politics
groups) - rather, what you do do is to discuss with other sensible
people, how the nutjobs became such nutjobs.  As I like to put it, you
don't discuss the maze with the rats.

-- 
Faced with the choice between changing one's mind and proving that there is
no need to do so, almost everyone gets busy on the proof. 

    - John Kenneth Galbraith -

On Aug 6, 3:04=A0pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 5 Aug, 17:55, John Kelly <j...@isp2dial.com> wrote:
>
> > On Thu, 5 Aug 2010 07:28:33 -0700 (PDT),spinoza1111
> > <spinoza1...@yahoo.com> wrote:
>
> <snip stuff>
>
> <snip more stuff>
>
> > Some people think a troll is anyone saying anything they don't like, or
> > posting off topic. =A0Though I don't agree, I have encountered trolls.
>
> > Criticism is one thing. =A0But when it's mean and personal, it's trolli=
ng.
>
> > Have a nice day.
>
> when he spouts nonsense to get attention, that's trolling. It's up to

Is it nonsense, or just things you don't understand?


> you of course but I don't think you have much to gain my encouraging
> him. =A0And pretty much any response is encouragment (including this
> one!).
>
> Although kenny & spinoza pretend not to understand most kill files
> block a poster not the responses to that poster. So some people have
> reason to be irritated by responses to known trolls. If it weren't for

"So some people have reason to be irritated by responses to Jews."
Your daemonization of "trolls" (and your utter failure to understand
the meaning of the word) is a miniature working model of Fascism,
which shows that you are probably the sort of person who under stress
joins Fascist causes.

You utterly fail to understand the meaning of the word. The Wikipedia
definition is an older usage, where on a local area network a person
would deliberately spoof and tease insincerely was a "troll". But
Kenny and I are both sincere about our dislike of the behavior of the
regulars.

In his recent book "You Are Not a Gadget", Jaron Lanier reserves the
word for abusive posters who are anonymous and neither Kenny nor I are
anonymous. Quite the opposite, in my case, I have repeatedly (starting
at Princeton University) put my reputation on the line.

> the reponses they'd remain blissfully unaware of their existence. Oh
> joy.
>
> --
>
> No word matters.
> But man forgets reality and remembers words.
> The more words he remembers, the cleverer do his fellows esteem him.
> =A0 =A0 =A0 "Lord of Light" Roger Zelazny

On Aug 6, 3:46=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-08-06, John Kelly <j...@isp2dial.com> wrote:
>
> > But why get personal with these people. =A0It's just a big waste of tim=
e.
> > You can't reform the incorrigible. =A0And you can't defeat them online.
>
> There is a certain amount of irony to be had here, were you to look at
> the last ten or twenty years of Usenet postings by Edward Nilges. =A0:)

I have complained to Apress concerning your demonization of a person
who happens to also be an author for that company. It is
unprofessional to do this, just as it was unprofessional of you to
build a computing career NOT by taking any classes in computer
science, but by publishing a juvenile attack on a computing author.

But, you make me glad to be a polymath. I don't have to work with
people like you ever again.

You've made a fool out of yourself with your excuses for bad code,
coupled with your attacks on others' "bad code", for almost as long,
and you too are getting old.

Foole.
If thou wert my Foole Nunckle, Il'd haue thee beaten for being old
before thy time.

Lear.
How's that?

Foole.
Thou shouldst not haue bin old, till thou hadst bin wise.

Shakespeare, King Lear

>
> -s
> --
> Copyright 2010, all wrongs reversed. =A0Peter Seebach / usenet-nos...@see=
bs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny picturesht=
tp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On Aug 5, 10:18=A0pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
> whose worked worldwide. This is what happened in reality. It's not

who's worked worldwide. Homeric nod.

In article <lnsk2uklxq.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
> blmblm@myrealbox.com <blmblm@myrealbox.com> writes:
> [103 lines deleted]
> 
> I believe that the e-mail address under which spinoza1111 posts
> works.  If you want to have a debate with him, I suggest you do
> so by e-mail.  Even with "(OT)" in the subject, I can think of no
> reasonable justification for doing so in this newsgroup.
> 
> *Please* stop feeding the troll.
> 

Didn't we have a similar exchange a while back ....

Some of us are slow learners, I guess.  Or maybe it's like quitting
smoking, which (as I understand it) for some people only happens
after repeated attempts.

As for taking the discussion to e-mail -- well, no, that's not
something I really want to do, for a variety of reasons, not all
of which I want to explain here.  But one of them is some sense
that the discussion started as a public debate and should finish
that way.  

But my, what a lot of "I really want to reply to this!" stuff 
there's been in recent posts.  I guess it's good that I have 
less time these days for Usenet.

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

On Aug 6, 11:48=A0am, gaze...@shell.xmission.com (Kenny McCormack)
wrote:
>
> My own view is that you don't bother arguing with nutjobs (like Kiki and
> friends in this ng and the various political nutjobs in the politics
> groups) - rather, what you do do is to discuss with other sensible
> people, how the nutjobs became such nutjobs. =A0As I like to put it, you
> don't discuss the maze with the rats.
>
Ah this is the "sociobiology study group" move.

What happened was that some academics in American universities thought
that they could explain human social behaviour by applying the same
Darwinian analyis to it as to other species' behaviour. There are pros
and cons to this position. One of the effects is that it tends to
produce analyses that are very sympathetic to the right.

Some left wing academics didn't like this implication. So they formed
the "sociobiology study group". However they didn't actally study
sociobiology. The studied the sociobiologists, describing their
political inclinations, some remarks they made which could be
construed as "racist", and so on.

Totally illegitmate. Studying sociobiology mean admitting that in some
respects sociobiologists have a strong case. If human social behaviour
isn't Darwinian, what is it? Are you arguing that humans have souls
(the sociobiology study group never tried that particular angle).
Studying the sociobiologists is a very sophisticated form of the ad
hominem fallacy - don't actually show that sociobilogy is wrong, just
try to discredit it.

In article <57bf02b5-471b-460e-938a-d5db62e73eaf@i28g2000yqa.googlegroups.com>,
Shao Miller  <sha0.miller@gmail.com> wrote:
> On Aug 2, 8:07 pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > In article <14700fda-3ca2-4d27-a151-72607d3dd...@u26g2000yqu.googlegroups.com>,
> > Shao Miller  <sha0.mil...@gmail.com> wrote:
> > > On Jul 31, 4:13 pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:

[ snip ]

> > > I agree.  I believe that people associating a claim of a claim with a
> > > dispute for the latter claim will find their doubt-casting.  
> >
> > I don't understand what you mean by that sentence, but maybe it's
> > not very important.
> >
> If I say "So-and-so claims such-and-such," that very statement is a
> claim just as much as so-and-so's claim of such-and-such.

Oh.  Sounds a bit recursive ....

> If one perceives a negative connotation, I find it likely that it is
> due to their conditioning; sometimes cultural, sometimes personal.
> Experiences cause conditioning.  A connotation isn't explicit, so
> where does it come from?: A conditioned voice in the reader's head.
> It says (very quickly), "I recognize that word in this context.  It
> implies that there is doubt about the truth of what so-and-so stated."
> 
> I'd rather not drop the plain English "claims to have" from my typing
> because some people associate such with doubt-casting, but I have
> enough respect for others to do so. :)

Well, whatever.  To me it still sounds like you somehow think
that only the, hm, "denotative meanings" [*] of words count, as
opposed to their "connotative meanings", and that seems strange
to me, and if you do think that I don't agree, but I don't think
anything good will come of further discussion here.

[*] Terms that I, um, invented.  No idea whether a linguist would
recognize them as valid, but maybe my meaning is clear enough.

I'm mildly curious about whether there are others for whom "claims
to be" has no negative connotations.  That might be a question for
alt.usage.english, another group I sort of follow, hm, ....
  
> > > "...who are you calling..." is another example of a perceived
> > > attack. :S  
> >
> > Meaning "an example of perceiving an attack where none was meant"?
> >
> No, I didn't mean that.  You are correct; none was meant.  But the
> intention is not accessible to you, it belongs to the author and only
> the author knows the truth of their intent.  A point that might or
> might not be worth taking away is that if we have some overlap in our
> frames of reference, we can hopefully communicate more effectively.
> "We are typing to one another" != "Someone is calling someone else
> wordy or a liar." :)  My impression from your posts is that you agree.

Well, I do agree that no one but the writer can really claim to
know exactly what he or she meant.  I also agree that more overlap
in frames of reference improves the odds of clear communication,
and that it's good when people can recognize the limitations of
a text-only medium and try to avoid misunderstandings.

Sometimes we even learn from each other, such that the frames of
reference overlap more.  Maybe that has happened a bit here.

Of course, sometimes when people are typing at each other, one
of them *IS* calling the other one wordy or a liar.  But maybe
a level-headed person tries to keep in mind that words can have
different interpretations ....

One thing that can help a great deal is to recognize situations
in which replying to a post right away is *not* a good idea, and
set it aside for later.  But the temptation to reply in anger is
sometimes strong, and I suppose depending on tools it might be
difficult to set something aside for later.  My two cents' worth!

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

In article <f9e5b9b9-e80f-46a1-bc68-cd86d506d7fb@f42g2000yqn.googlegroups.com>,
Shao Miller  <sha0.miller@gmail.com> wrote:
> On Aug 2, 8:08 pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > In article <e743861c-57c3-4340-9965-47a89948a...@w30g2000yqw.googlegroups.com>,
> > Shao Miller  <sha0.mil...@gmail.com> wrote:
> >
> > > On Jul 31, 5:53 pm, Seebs <usenet-nos...@seebs.net> wrote:
> > > > On 2010-07-31, blmblm  myrealbox.com <blm...@myrealbox.com> wrote:

[ snip ]

> You might have missed a post.  

More than possible!  I've tried to at least skim all the posts 
in this thread, but there have been a lot of them ....

> It was apparently July 25th, 2010 at
> 5:42 pm, whatever that means.

Message ID is probably a more-unambiguous identifier, and one
that at least on good days you can use to find a message in
Google's archives (from the "advanced search" page).  But if
I look in my saved copies of posts for something by you with
a time of something:42 [*], I find the post I think you mean,
the one with message ID

<fb3b6110-f3dc-4115-a366-61eb8932aff9@k19g2000yqc.googlegroups.com>

[*] "25 Jul 2010 14:42:29 -0700 (PDT)" is what it shows.  Not
sure I completely understand how to interpret that.

> > In any case, I agree with Seebs that in context "invented" is
> > difficult to interpret as anything *but* an insult.
> >
> Well read what it says again, if you'd enjoy.  Read the
> aforementioned, possibly-missed post, if you'd enjoy.

"If you'd enjoy" .... hm, unfamiliar idiom, where I'd write 
"if you like" .... but I digress.

Anyway, yeah, okay, I think I'm not interested in pursuing this
discussion further -- it seems to be getting into pointless
wrangling about who said what and who's responsible for the
apparent miscommunication.  Looking back over some posts, I
think you've tried to clear things up, and I think the other
parties could have made a bit more effort to meet you halfway,
but -- whatever.

[ snip ]

> It's really not easy to type and
> review inside the 11-row box that Google gives for posting via a web
> page interface.

*11-ROW BOX*!!??  Good heavens, it (the interface) may be even
worse than I'd have thought.  You know, much as I appreciate
having someone provide for free an archive of Usenet posts,
the posting interface seems to leave a lot to be desired.

But that's a whole other rant ....

[ snip ]

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

On 2010-08-06, blmblm  myrealbox.com <blmblm@myrealbox.com> wrote:
> In article <lnsk2uklxq.fsf@nuthaus.mib.org>,
> Keith Thompson  <kst-u@mib.org> wrote:
>> *Please* stop feeding the troll.

> But my, what a lot of "I really want to reply to this!" stuff 
> there's been in recent posts.

No one disputes that he is an *effective* troll.  He has a truly
astounding grasp of how to get something *almost* totally wrong, with
just enough hints of logical connectivity to make it look as though
there is some point in argumentation.

Seriously, just plonk him and move on.  It's not going to get anywhere;
people have been trying to argue with the guy for ten or twenty years,
and it's gotten nowhere.  The more you argue, the more he has to believe
crazy stuff not to feel like he's lost a point, so all it does is make
him even more extreme.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On 6 Aug, 15:18, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <f9e5b9b9-e80f-46a1-bc68-cd86d506d...@f42g2000yqn.googlegroups=
..com>,
> Shao Miller =A0<sha0.mil...@gmail.com> wrote:

<snip>

> > It's really not easy to type and
> > review inside the 11-row box that Google gives for posting via a web
> > page interface.
>
> *11-ROW BOX*!!?? =A0Good heavens, it (the interface) may be even
> worse than I'd have thought. =A0You know, much as I appreciate
> having someone provide for free an archive of Usenet posts,
> the posting interface seems to leave a lot to be desired.
>
> But that's a whole other rant ....
1
2
3
4
5
6
7
8
9
10
11

yup that's the default size. But if you resize the window...
....you get 31 lines. Not massive but quite adequate to compose a
usenet post in.

I use explorer and if I move the cursor into the area just below the
text window the cursor changes to a four-way arrow. Hold down the
right mouse button and drag the window downwards.

DON'T resize the pane holding the tree view it seems to eat your
machine.

On 6 Aug, 15:16, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <57bf02b5-471b-460e-938a-d5db62e73...@i28g2000yqa.googlegroups=
..com>,
> Shao Miller =A0<sha0.mil...@gmail.com> wrote:
> > On Aug 2, 8:07 pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > > In article <14700fda-3ca2-4d27-a151-72607d3dd...@u26g2000yqu.googlegr=
oups.com>,
> > > Shao Miller =A0<sha0.mil...@gmail.com> wrote:
> > > > On Jul 31, 4:13 pm, blm...@myrealbox.com <blm...@myrealbox.com> wro=
te:

> > > > I agree. =A0I believe that people associating a claim of a claim wi=
th a
> > > > dispute for the latter claim will find their doubt-casting. =A0
>
> > > I don't understand what you mean by that sentence, but maybe it's
> > > not very important.
>
> > If I say "So-and-so claims such-and-such," that very statement is a
> > claim just as much as so-and-so's claim of such-and-such.

are you (Shao Miller) a native english speaker? I believe Seebs is
American, I'm English. Both of us find "X claims that..." to be
mildly.... if not rude... it indicates a doubt about the speaker's
veracity. Why not "X says that...". The very fact that you didn't use
the more neutral term is an implicit... slight. (I'm trying to pick my
words carefully!)

> Oh. =A0Sounds a bit recursive ....
>
> > If one perceives a negative connotation, I find it likely that it is
> > due to their conditioning; sometimes cultural, sometimes personal.

again if you're a native english speaker then this is a reasonable
view to hold (though I'd say it was you that had the odd cultural
backgound!), if you aren't then I'll say you had a tin ear for
english.

> > Experiences cause conditioning. =A0A connotation isn't explicit, so
> > where does it come from?: A conditioned voice in the reader's head.
> > It says (very quickly), "I recognize that word in this context. =A0It
> > implies that there is doubt about the truth of what so-and-so stated."

english has a lot of words that almost mean the same thing. There's a
reason they /almost/ mean the same thing.


> > I'd rather not drop the plain English "claims to have" from my typing
> > because some people associate such with doubt-casting, but I have
> > enough respect for others to do so. :)

I think you'd be better rethinking that, unless your local version of
english uses it heavily

> Well, whatever. =A0To me it still sounds like you somehow think
> that only the, hm, "denotative meanings" [*] of words count, as
> opposed to their "connotative meanings", and that seems strange
> to me, and if you do think that I don't agree, but I don't think
> anything good will come of further discussion here.
>
> [*] Terms that I, um, invented. =A0No idea whether a linguist would
> recognize them as valid, but maybe my meaning is clear enough.
>
> I'm mildly curious about whether there are others for whom "claims
> to be" has no negative connotations. =A0That might be a question for
> alt.usage.english, another group I sort of follow, hm, ....

"claims" definitely implies doubt to me. Words don't just have a
simple meaning the also carry around a "cloud" of implicit meanings.

If someone uses the term "evolutionist" they don't just mean "a
biologist who studies evolutionary biology" they tend to mean "person
who foolishly believes in the myth of evolution" "an atheist" and
probably a deluded or wicked person. I also conclude that the speaker
likely holds opinions about the bible that are in the main only held
in the United States.

[PLEASE don't use this example as the trigger to a political/religious
debate]

> > > > "...who are you calling..." is another example of a perceived
> > > > attack. :S =A0
>
> > > Meaning "an example of perceiving an attack where none was meant"?
>
> > No, I didn't mean that. =A0You are correct; none was meant. =A0But the
> > intention is not accessible to you, it belongs to the author and only
> > the author knows the truth of their intent. =A0A point that might or
> > might not be worth taking away is that if we have some overlap in our
> > frames of reference, we can hopefully communicate more effectively.
> > "We are typing to one another" !=3D "Someone is calling someone else
> > wordy or a liar." :) =A0My impression from your posts is that you agree=
..
>
> Well, I do agree that no one but the writer can really claim to
> know exactly what he or she meant. =A0I also agree that more overlap
> in frames of reference improves the odds of clear communication,
> and that it's good when people can recognize the limitations of
> a text-only medium and try to avoid misunderstandings.
>
> Sometimes we even learn from each other, such that the frames of
> reference overlap more. =A0Maybe that has happened a bit here.
>
> Of course, sometimes when people are typing at each other, one
> of them *IS* calling the other one wordy or a liar. =A0But maybe
> a level-headed person tries to keep in mind that words can have
> different interpretations ....
>
> One thing that can help a great deal is to recognize situations
> in which replying to a post right away is *not* a good idea, and
> set it aside for later. =A0But the temptation to reply in anger is
> sometimes strong, and I suppose depending on tools it might be
> difficult to set something aside for later. =A0My two cents' worth!

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
<snip>
> are you (Shao Miller) a native english speaker? I believe Seebs is
> American, I'm English. Both of us find "X claims that..." to be
> mildly.... if not rude... it indicates a doubt about the speaker's
> veracity.

TI don't think that's quite right.  There is no slight at all if the
domain of discourse is one of opinion to start with.  "Nick claims that
red ties are better than blue ones" is not at all rude, but "Nick claims
he knows C" is more than slightly rude.

<snip>
-- 
Ben.

On 2010-08-06, blmblm  myrealbox.com <blmblm@myrealbox.com> wrote:
> In article <57bf02b5-471b-460e-938a-d5db62e73eaf@i28g2000yqa.googlegroups.com>,
> Shao Miller  <sha0.miller@gmail.com> wrote:
>> If one perceives a negative connotation, I find it likely that it is
>> due to their conditioning; sometimes cultural, sometimes personal.

And this, Shao, is why I told you about Gricean Maxims, so you could
understand how many connotations are NOT related to any conditioning
at all.  And that you still haven't done it is why you're still plonked;
I didn't plonk you for being wrong, but for being unwilling to learn.

>> Experiences cause conditioning.  A connotation isn't explicit, so
>> where does it come from?: A conditioned voice in the reader's head.
>> It says (very quickly), "I recognize that word in this context.  It
>> implies that there is doubt about the truth of what so-and-so stated."

This is not, in fact, how it works.

But more importantly:  *EVEN IF THIS WERE SO*, it would still mean you'd
need to be aware of that meaning.  If your goal is to communicate with
other people, you MUST take into account how they will understand you.

Dragging this back on topic:  This is the same as the problem we had
originally with all this stuff about null pointers.  You have to understand
what the compiler understands your code to mean; it doesn't matter whether
you agree with it, for the most part.  If you want to communicate, you
have to pay attention to how messages are interpreted, not just how you
intended them.

> Well, whatever.  To me it still sounds like you somehow think
> that only the, hm, "denotative meanings" [*] of words count, as
> opposed to their "connotative meanings", and that seems strange
> to me, and if you do think that I don't agree, but I don't think
> anything good will come of further discussion here.

Sounds a little aspieish around the edges, I know it took me a long time
to accept that I had to care what other people understood me to be saying
rather than only what I meant by it.

> Well, I do agree that no one but the writer can really claim to
> know exactly what he or she meant.

Certainly true.

But sometimes, what you said and what you meant are different.  If I am
trying to express my belief that someone is kind towards children in an
unfamiliar language, and I end up using a phrase that has the connotation
of "pedophilia" rather than something else, then it may matter a great
deal more what the average reader is likely to understand than it does
what I thought I was saying.

In English, saying that someone "invented" something is an assertion that
it was not present to begin with; not only that they didn't present the
citation, but that they had no citation to begin with.  If they did have
a citation, it wasn't an invention.

While my belief about whether Shao is a nice person or a jerk might be
affected by information about his intent, that doesn't change the actual
meaning of what he said.

I dunno.  Shao's coming across to me as in some ways a very familiar sort,
and I was probably just as stubborn about intent as opposed to how other
people understand things, sometime back in the distant past.  What fixed it
for me was studying a mix of linguistics and psychology.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On 2010-08-06, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
><snip>
>> are you (Shao Miller) a native english speaker? I believe Seebs is
>> American, I'm English. Both of us find "X claims that..." to be
>> mildly.... if not rude... it indicates a doubt about the speaker's
>> veracity.

> TI don't think that's quite right.  There is no slight at all if the
> domain of discourse is one of opinion to start with.  "Nick claims that
> red ties are better than blue ones" is not at all rude, but "Nick claims
> he knows C" is more than slightly rude.

This, by the way, is NOT (so far as I know) a cultural thing, or even
particularly specific to English.  It's a result of Gricean Maxims in
operation.

Basically, to oversimplify horribly:  People engage in language activities
with intent to communicate.  There is, thus, a consistent underlying
assumption which people generally apply to ALL written or spoken
communication:

If something is stated, it is stated with intent to communicate.

This is why "damning with faint praise" works.  Consider, in C:TCN4E,
my statement about the intro to Chapter 7:  "I found no errors on this page."
Normally, when discussing a technical book, you would expect to find errors,
but you would expect to find few enough that failure to mention a page would
be interpreted as not having found any errors there.  When I explicitly
identify a page on which I found no errors, I am *implicitly* stating that
this is atypical -- that most pages have errors.

Now let's look at the word "claim".  The word "claim" is different from
other words that are near-synonyms in that it is specifically used to
disclaim agreement with the statement being referred to; it is used
specifically to highlight who has advanced a given position or belief.
When talking about opinions, that's pretty much normal, and carries no
special weight.  When talking about fairly verifiable facts, though, using
"claim" is understood to imply distancing the speaker from the claimant,
and does indeed imply that the claim is perhaps untrue.  If you have
any emphasis on the word, it becomes a fairly unambiguous assertion of
disagreement.

Consider the sentence:

Nick claims to be English.

This sentence carries with it the implication that, if I had not said
this, you would not know or believe it.  Thus, you don't know who it
is that claimed to be English, you don't know what Nick claimed to be,
or you don't know the status of the assertion that Nick is English.

With emphasis, these can be clarified:

*Nick* claims to be English.

This sentence informs the reader that there was dispute as to who it was
that had asserted that he was English.

Nick claims to be *English*.

This sentence informs the reader that there was dispute as to what
nationality Nick had asserted he had.

Nick *claims* to be English.

This sentence informs the reader that Nick's assertion itself is disputed.

Without explicit emphasis, the next thing to do is fall back on analysis;
we already know that we are talking about Nick, because he's been quoted,
we have the quote of what he said in view... The only other content *left*
is the claim, and thus, the default interpretation is that I am calling
attention to the fact that he has made this claim, which implies that I
think it's significant that he is *claiming* this.  Meaning I'm hinting that
I think he's wrong or lying.  On a matter where there's little room for
error, that would imply lying.

The reason I'm offering this fairly long explanation is that Shao's posts
are reading, to me, an awful lot like the posts of a lot of people who have
not yet picked up that set of analysis tools, and who don't have the raw
instincts that make them "obvious" to most people, so I figure I should
provide the information.  This is one of those things where it looks
strange at first, but if you try it out for a while, the explanatory and
predictive power are amazing.  Empirically, people really are doing this
analysis all the time.

For a vaguely C-related example:

Imagine that someone were to ask my opinion of a program, and I were to
respond "Well.  It compiled."

Would you understand this to be a positive, neutral, or negative statement
about the program?  (Hint:  The answer is, so far as I can tell, fairly
unambiguous.)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

blmblm@myrealbox.com <blmblm@myrealbox.com> writes:
> In article <lnsk2uklxq.fsf@nuthaus.mib.org>,
> Keith Thompson  <kst-u@mib.org> wrote:
>> blmblm@myrealbox.com <blmblm@myrealbox.com> writes:
>> [103 lines deleted]
>> 
>> I believe that the e-mail address under which spinoza1111 posts
>> works.  If you want to have a debate with him, I suggest you do
>> so by e-mail.  Even with "(OT)" in the subject, I can think of no
>> reasonable justification for doing so in this newsgroup.
>> 
>> *Please* stop feeding the troll.
>
> Didn't we have a similar exchange a while back ....

Why yes, I believe we did.

> Some of us are slow learners, I guess.  Or maybe it's like quitting
> smoking, which (as I understand it) for some people only happens
> after repeated attempts.
>
> As for taking the discussion to e-mail -- well, no, that's not
> something I really want to do, for a variety of reasons, not all
> of which I want to explain here.  But one of them is some sense
> that the discussion started as a public debate and should finish
> that way.  

I suggested e-mail as an alternative to posting here.  It actually
doesn't matter to me whether you engage him in an e-mail discussion
or not.  All I ask is that you not feed the troll *here*.

> But my, what a lot of "I really want to reply to this!" stuff 
> there's been in recent posts.  I guess it's good that I have 
> less time these days for Usenet.

Ignoring trolls is a learned skill.  In the past, I often engaged
trolls in debate myself, explaining to them in great detail why
they were wrong.  It never did any good, and it was very likely
just the reaction the trolls wanted.

A large part of the reason we participate here is, frankly, to
explain to people why they're wrong.  That sounds a bit harsh,
but it's a large part of teaching and learning.  So when someone
here makes an incorrect statement about C (as I've done myself
on occasion), people jump in and post corrections, and everyone
learns something.  That's the good part.

The trick is to recognize the cases when posting a correction
isn't going to do anyone any good.  Without speculating on what
actually motivates them, long painful experience shows that engaging
spinoza1111 in debate *never does any good*.

I understand the temptation.  Personally, I've found that a killfile
is a good way to avoid it.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

Shao Miller <sha0.miller@gmail.com> writes:
[...]
> Now perhaps you can see why it's important to be tolerant.  A trivial
> mistake leads to an ambiguity.  It's really not easy to type and
> review inside the 11-row box that Google gives for posting via a web
> page interface.
[...]

So copy-and-paste it into your favorite editor, edit it there, then
copy-and-paste it back into your web browser.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

On Aug 6, 1:53=A0pm, Keith Thompson <ks...@mib.org> wrote:
> ... ... ...
> A large part of the reason we participate here is, frankly, to
> explain to people why they're wrong. =A0That sounds a bit harsh,
> but it's a large part of teaching and learning. =A0So when someone
> here makes an incorrect statement about C (as I've done myself
> on occasion), people jump in and post corrections, and everyone
> learns something. =A0That's the good part.
>
> The trick is to recognize the cases when posting a correction
> isn't going to do anyone any good.
> ... ... ...
Tricky, indeed. :)  Strictly referring to discussion of C, there is a
slight risk that if one (A) makes the judgment that "posting a
correction isn't going to do anyone any good," that something that
they (A) take for granted as being correct cannot be brought to
awareness as something which might actually deserve reconsideration.
That is, (still referring to C) inhibition of one's own offering of
arguments/reasoning/beliefs is a strong way to protect that set from
change, even if that change _might_ "do" "good", were it to happen. :)

The scenario could be considered akin to use of 'volatile'.

#ifdef DONT_BOTHER_RESPONDING
#define ANY_GOOD
#else
#define ANY_GOOD volatile
#endif

extern ANY_GOOD const int reality;

void f(void) {
  static int local_copy =3D 0;
  local_copy |=3D reality;
  /* ... Operate ... */
  local_copy |=3D reality;
  /* ... Operate ... */
  local_copy |=3D reality;
  /* ... Operate ... */
  return;
}

On Aug 6, 2:26=A0pm, Keith Thompson <ks...@mib.org> wrote:
> Shao Miller <sha0.mil...@gmail.com> writes:
>
> [...]> Now perhaps you can see why it's important to be tolerant. =A0A tr=
ivial
> > mistake leads to an ambiguity. =A0It's really not easy to type and
> > review inside the 11-row box that Google gives for posting via a web
> > page interface.
>
> [...]
>
> So copy-and-paste it into your favorite editor, edit it there, then
> copy-and-paste it back into your web browser.
Thanks, Keith.  I don't have a time machine, but that's certainly what
I do now. :)

On 06 Aug 2010 16:18:48 GMT, Seebs <usenet-nospam@seebs.net>
wrote:

>On 2010-08-06, blmblm  myrealbox.com <blmblm@myrealbox.com> wrote:
>> In article <57bf02b5-471b-460e-938a-d5db62e73eaf@i28g2000yqa.googlegroups.com>,
>> Shao Miller  <sha0.miller@gmail.com> wrote:
>>> If one perceives a negative connotation, I find it likely that it is
>>> due to their conditioning; sometimes cultural, sometimes personal.
>
>And this, Shao, is why I told you about Gricean Maxims, so you could
>understand how many connotations are NOT related to any conditioning
>at all.  And that you still haven't done it is why you're still plonked;
>I didn't plonk you for being wrong, but for being unwilling to learn.

The trouble with your advice is that you were wrong then and that
you are wrong now.

    

On 2010-08-06, Richard Harter <cri@tiac.net> wrote:
> The trouble with your advice is that you were wrong then and that
> you are wrong now.

Without a specific statement as to what I said that was wrong, and what
you propose as an alternative, this statement is not very useful to me.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On Aug 6, 9:32=A0pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <lnsk2uklxq....@nuthaus.mib.org>,
> Keith Thompson =A0<ks...@mib.org> wrote:
>
> > blm...@myrealbox.com <blm...@myrealbox.com> writes:
> > [103 lines deleted]
>
> > I believe that the e-mail address under whichspinoza1111posts
> > works. =A0If you want to have a debate with him, I suggest you do
> > so by e-mail. =A0Even with "(OT)" in the subject, I can think of no
> > reasonable justification for doing so in this newsgroup.
>
> > *Please* stop feeding the troll.

"Please stop talking to the Jew"
>
> Didn't we have a similar exchange a while back ....
>
> Some of us are slow learners, I guess. =A0Or maybe it's like quitting
> smoking, which (as I understand it) for some people only happens
> after repeated attempts.

How dare you apologize to him? I am not a "troll". I am a human being,
who's also a computer author who was fucking asked by Princeton to
assist Nash. This is what I mean by your enabling, and how dare you
object to me calling you "my dear" in an effort to tone down the utter
hatred I see here?

You enable evil.
>
> As for taking the discussion to e-mail -- well, no, that's not
> something I really want to do, for a variety of reasons, not all
> of which I want to explain here. =A0But one of them is some sense
> that the discussion started as a public debate and should finish
> that way. =A0
>
> But my, what a lot of "I really want to reply to this!" stuff
> there's been in recent posts. =A0I guess it's good that I have
> less time these days for Usenet.
>
> --
> B. L. Massingill
> ObDisclaimer: =A0I don't speak for my employers; they return the favor.

On Aug 6, 10:27=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-08-06, blmblm =A0myrealbox.com <blm...@myrealbox.com> wrote:
>
> > In article <lnsk2uklxq....@nuthaus.mib.org>,
> > Keith Thompson =A0<ks...@mib.org> wrote:
> >> *Please* stop feeding the troll.
> > But my, what a lot of "I really want to reply to this!" stuff
> > there's been in recent posts.
>
> No one disputes that he is an *effective* troll. =A0He has a truly
> astounding grasp of how to get something *almost* totally wrong, with
> just enough hints of logical connectivity to make it look as though
> there is some point in argumentation.
>
> Seriously, just plonk him and move on. =A0It's not going to get anywhere;
> people have been trying to argue with the guy for ten or twenty years,
> and it's gotten nowhere. =A0The more you argue, the more he has to believ=
e
> crazy stuff not to feel like he's lost a point, so all it does is make
> him even more extreme.
>

Fuck you, Peter Seebach. You're the problem here. You are self-
confessedly an incompetent programmer who nonetheless, because you're
also a Mama's boy, conducts vicious attacks on reputations creating
nothing but confusion.
> -s
> --
> Copyright 2010, all wrongs reversed. =A0Peter Seebach / usenet-nos...@see=
bs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny picturesht=
tp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On Aug 7, 1:53=A0am, Keith Thompson <ks...@mib.org> wrote:
> blm...@myrealbox.com <blm...@myrealbox.com> writes:
> > In article <lnsk2uklxq....@nuthaus.mib.org>,
> > Keith Thompson =A0<ks...@mib.org> wrote:
> >> blm...@myrealbox.com <blm...@myrealbox.com> writes:
> >> [103 lines deleted]
>
> >> I believe that the e-mail address under whichspinoza1111posts
> >> works. =A0If you want to have a debate with him, I suggest you do
> >> so by e-mail. =A0Even with "(OT)" in the subject, I can think of no
> >> reasonable justification for doing so in this newsgroup.
>
> >> *Please* stop feeding the troll.
>
> > Didn't we have a similar exchange a while back ....
>
> Why yes, I believe we did.
>
> > Some of us are slow learners, I guess. =A0Or maybe it's like quitting
> > smoking, which (as I understand it) for some people only happens
> > after repeated attempts.
>
> > As for taking the discussion to e-mail -- well, no, that's not
> > something I really want to do, for a variety of reasons, not all
> > of which I want to explain here. =A0But one of them is some sense
> > that the discussion started as a public debate and should finish
> > that way. =A0
>
> I suggested e-mail as an alternative to posting here. =A0It actually
> doesn't matter to me whether you engage him in an e-mail discussion
> or not. =A0All I ask is that you not feed the troll *here*.
>
> > But my, what a lot of "I really want to reply to this!" stuff
> > there's been in recent posts. =A0I guess it's good that I have
> > less time these days for Usenet.
>
> Ignoring trolls is a learned skill. =A0In the past, I often engaged

"Ignoring Jews is a learned skill."

> trolls in debate myself, explaining to them in great detail why
> they were wrong. =A0It never did any good, and it was very likely

To reduce knowledge to a matter of other people being in the wrong is
just sad...and Fascistic.


> just the reaction the trolls wanted.
>
> A large part of the reason we participate here is, frankly, to
> explain to people why they're wrong. =A0That sounds a bit harsh,

This presumes that as corporate programmers you know your jobs.
However, in my thirty years of experience world-wide I discovered that
consistently, the corporation does not want you to know your job with
the possible exception of people so specialized that they can and do
not think outside their specialty (as in the common example of the
programmer who knows only one thing, that OO somehow is "inefficient",
because he learned a primitive language in 1980 and simply does not
want to learn anything new...there being too much to see on TV).

You pose as brain workers, but do not give any evidence of love of
thinking.

> but it's a large part of teaching and learning. =A0So when someone

Perhaps it was in your upbringing, but, of course, the problem is that
the programming field is overrun with people who manage anger poorly
owing to dysfunctional educations.


> here makes an incorrect statement about C (as I've done myself
> on occasion), people jump in and post corrections, and everyone
> learns something. =A0That's the good part.
>
> The trick is to recognize the cases when posting a correction
> isn't going to do anyone any good. =A0Without speculating on what
> actually motivates them, long painful experience shows that engagingspino=
za1111in debate *never does any good*.
>
> I understand the temptation. =A0Personally, I've found that a killfile
> is a good way to avoid it.

There is a Klown named Kiki
A little God that is Tiki
He runs his mouth
But remains uncouth
That tinpot god named Kiki


>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org =A0<http://www.ghoti.net/~=
kst>
> Nokia
> "We must do something. =A0This is something. =A0Therefore, we must do thi=
s."
> =A0 =A0 -- Antony Jay and Jonathan Lynn, "Yes Minister"

On Aug 7, 2:26=A0am, Keith Thompson <ks...@mib.org> wrote:
> Shao Miller <sha0.mil...@gmail.com> writes:
>
> [...]> Now perhaps you can see why it's important to be tolerant. =A0A tr=
ivial
> > mistake leads to an ambiguity. =A0It's really not easy to type and
> > review inside the 11-row box that Google gives for posting via a web
> > page interface.
>
> [...]
>
> So copy-and-paste it into your favorite editor, edit it there, then
> copy-and-paste it back into your web browser.

Lo! Kiki the Tiki groans from the skies
His pearls of wisdom to flute notes and sighs!
The people are assembled in the public square
The day turns foul, the Sun breaks, and all is Fair
Today's Delphine advice breaks out in thund'rous words
To the cry of circling, astounded, and angry birds
"Copy and paste it into an editor you like,
Edit it there, and lo, Pat, and thus, Mike,
You may paste it back into your Web browser, be it ever so crude
Am I not wise, am I not the "dude".
The people are aghast at finding such Pearls
Of wisdom, most especially the Girls:
They rip off wet underpants at Kiki to toss
They scream with passion, they pant with such Sauce!
You're such a Guru, we Gnow it you Gnu you
Tell us how our nasty little corporate jobs to do!
Kiki the Tiki nods ever so wise
From his throne on a toilet high up in the skies
"Death to all trolls" is his parting oration
And for such crap Kiki's the toast of the nation!

On the Internet, nobody knows you're a Dog
Some people love this themselves they do snog
Wrapped up in their bullshit at the bottom of the sea
They never awake to their sad and pathetic own misery.

>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org =A0<http://www.ghoti.net/~=
kst>
> Nokia
> "We must do something. =A0This is something. =A0Therefore, we must do thi=
s."
> =A0 =A0 -- Antony Jay and Jonathan Lynn, "Yes Minister"

"spinoza1111" <spinoza1111@yahoo.com> ha scritto nel messaggio
news:ceafef4d-b152-4826-86f7-a63bba471f4c@f20g2000pro.googlegroups.com...
>On Aug 6, 3:04 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
>wrote:
>> On 5 Aug, 17:55, John Kelly <j...@isp2dial.com> wrote:
>>
>> > On Thu, 5 Aug 2010 07:28:33 -0700 (PDT),spinoza1111
>> > <spinoza1...@yahoo.com> wrote:
>>
>"So some people have reason to be irritated by responses to Jews."
>Your daemonization of "trolls" (and your utter failure to understand
>the meaning of the word) is a miniature working model of Fascism,
>which shows that you are probably the sort of person who under stress
>joins Fascist causes.

it seems here we are not man, women, individuals, Jews, etc
here we are just written words, thinks in one mind
the fight are between thinks each other

>> No word matters.
>> But man forgets reality and remembers words.
>> The more words he remembers, the cleverer do his fellows esteem him.
>> "Lord of Light" Roger Zelazny

In article <ea23780c-cd63-415b-aabe-348ba230908e@t2g2000yqe.googlegroups.com>,
Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
>On Aug 6, 11:48�am, gaze...@shell.xmission.com (Kenny McCormack)
>wrote:
>>
>> My own view is that you don't bother arguing with nutjobs (like Kiki and
>> friends in this ng and the various political nutjobs in the politics
>> groups) - rather, what you do do is to discuss with other sensible
>> people, how the nutjobs became such nutjobs. �As I like to put it, you
>> don't discuss the maze with the rats.
>>
>Ah this is the "sociobiology study group" move.

(Interesting story - clipped)
Interesting take.  Of course, irrelevant in my view.

The fact is that when you are dealing with crazy people, at some point,
you have to step back and have everyone agree that the people you are
dealing with are crazy.  Their views are not of equal value to other
people's views.

Everyone knows the truth of the above.  It's just common sense.

-- 
"We should always be disposed to believe that which appears to us to be
white is really black, if the hierarchy  of the church so decides." 

    - Saint Ignatius Loyola (1491-1556) Founder of the Jesuit Order -

On Fri, 06 Aug 2010 10:53:24 -0700, Keith Thompson
<kst-u@mib.org> wrote:

[snip]

>A large part of the reason we participate here is, frankly, to
>explain to people why they're wrong.

We!!???  You certainly don't speak for me, and I dare say you
don't speak for many others.  In my view the value of a newsgroup
like this is to provide a place where skilled practioners can
discuss their art.  In other words it is about using C to write
programs, programs that are well written and well structured.

An artisan thinks about what works well and what doesn't.  Each
programming language has its own quirks, its own special
features, and its own underlying paradigms.  To use them well,
one has to, so to speak, follow the grain.

Usw.    

>That sounds a bit harsh,
>but it's a large part of teaching and learning.

You see, you perceive the group as being about teaching and
learning.  I perceive it as about sharing.  Teaching the puppies
is important but it is not, in my view of course, what this group
is or should be about.  

>So when someone
>here makes an incorrect statement about C (as I've done myself
>on occasion), people jump in and post corrections, and everyone
>learns something.

This is indeed a nice function of the group but I feel it is one
of the less important functions.  You seemingly have a different
view and that's okay too.

But please be careful with your we's.  You speak for yourself and
for those who agree with you, and not for all of us.

On Sat, 07 Aug 2010 15:37:31 GMT, cri@tiac.net (Richard Harter) wrote:

>On Fri, 06 Aug 2010 10:53:24 -0700, Keith Thompson
><kst-u@mib.org> wrote:
>
>[snip]
>
>>A large part of the reason we participate here is, frankly, to
>>explain to people why they're wrong.
>
>We!!???  You certainly don't speak for me, and I dare say you
>d