Fergus Henderson wrote:
>"The behaviour is undefined unless
> <blah>" does not imply "if <blah> then the behaviour is defined".

Well, for me (and I suspect most people) it does imply just that.  If in
fact the behavior is undefined (whether by explicit statement or by
omission) regardless of <blah>, then the "unless <blah>" statement is
either redundant, deceptive, or just plain wrong.  Instead it should
just say "The behavior is undefined."


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Hi,

as a result of a discussion in comp.lang.c++ (whether the following is
legal: 'char str[5]; char *ptr = str - 1; ptr[1];') I looked through
the expr.add section 5 where the corresponding situation is handled.
There I noticed that the section was modified since the release of the
April DWP.  The relevant part now read like this (expr.add section 5):

  [...] If  the result is used as an operand of the unary * operator,
  the behavior is undefined unless  both  the  pointer operand  and the
  result point to elements of the same array object, or the pointer
  operand points one past  the  last  element  of  an  array object
  and the result points to an element of the same array object, or the
  pointer operand points to the  element  of  an  array  and  the
  result points one past the last element of the same array.

In particular, it contains the clause: "If the result is used as an
operand of the unary * operator, the behavior is undefined unless ...
the pointer operand points to the element of an array and the result
points one past the last element of the same array" (with some stuff
removed for clarity). The stuff after the three dots ("...") was not
present in the April DWP.

With the new rules, I can apply the unary * operator to the result of
the expression even if the result of the expression points one past the
last element and I get defined behavior. I don't think this is the
correct intention or am I missing something?
--
<mailto:dietmar.kuehl@uni-konstanz.de>
<http://www.informatik.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article 6@news.belwue.de, kuehl@uzwil.informatik.uni-konstanz.de (Dietmar Kuehl) writes:
>
>as a result of a discussion in comp.lang.c++ (whether the following is
>legal: 'char str[5]; char *ptr = str - 1; ptr[1];') I looked through
>the expr.add section 5 where the corresponding situation is handled.
>There I noticed that the section was modified since the release of the
>April DWP.  The relevant part now read like this (expr.add section 5):
>
>  [...] If  the result is used as an operand of the unary * operator,
>  the behavior is undefined unless  both  the  pointer operand  and the
>  result point to elements of the same array object, or the pointer
>  operand points one past  the  last  element  of  an  array object
>  and the result points to an element of the same array object, or the
>  pointer operand points to the  element  of  an  array  and  the
>  result points one past the last element of the same array.

The latest draft, 15 November 1996, removes the "result of the unary *"
part, and the entire paragraph now reads as follows:

"When an expression that has integral type is added to or subtracted from
a pointer, the result has the type of the pointer operand. If the pointer
operand points to an element of an array object, and the array is large
enough, the result points to an element offset from the original element
such that the difference of the subscripts of the resulting and original
array elements equals the integral expression. In other words, if the
expression P points to the ith element of an array object, the
expressions (P)+N (equivalently, N+(P)) and (P)-N (where N has the value n)
point to, respectively, the i+nth and i-nth elements of the array object,
provided they exist. Moreover, if the expression P points to the last
element of an array object, the expression (P)+1 points one past the
last element of the array object, and if the expression Q points one past
the last element of an array object, the expression (Q)-1 points to the
last element of the array object. If both the pointer operand and the
result point to elements of the same array object, or one past the last
element of the array object, the evaluation shall not produce an overflow;
otherwise, the behavior is undefined."

In the original example, neither the evaluation of (str-1) nor the
subsequent (ptr[1]) has defined behavior according to this paragraph.
As in C, you can create a pointer "one past" the end of the array, but
you cannot depend on dereferencing it. Also as in C, you cannot depend
on creating a pointer "one before" the start of the array.

---
Steve Clamage, stephen.clamage@eng.sun.com




[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

kuehl@uzwil.informatik.uni-konstanz.de (Dietmar Kuehl) writes:

>April DWP.  [...] (expr.add section 5): [...]
>In particular, it contains the clause: "If the result is used as an
>operand of the unary * operator, the behavior is undefined unless ...
>the pointer operand points to the element of an array and the result
>points one past the last element of the same array" (with some stuff
>removed for clarity). The stuff after the three dots ("...") was not
>present in the April DWP.
>
>With the new rules, I can apply the unary * operator to the result of
>the expression even if the result of the expression points one past the
>last element and I get defined behavior. I don't think this is the
>correct intention or am I missing something?

You are missing something, I think.  "The behaviour is undefined unless
<blah>" does not imply "if <blah> then the behaviour is defined".

In this case, the behaviour is not explicitly undefined as a result of
this specific text in [expr.add]/5, but on the other hand I'm pretty
sure that the behaviour it is not explicitly defined anywhere either.
Behaviour that is not defined anywhere is undefined behaviour.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]