Topic: Possible DRs


Author: "Al Grant" <tnarga@arm.REVERSE-NAME.com>
Date: Tue, 8 Jan 2002 15:19:36 GMT
Raw View
"Stephen Clamage" <stephen.clamage@sun.com> wrote in message
news:5lof3uk2f6t89sd4ohotn0lvmrqv8pr0s3@4ax.com...
> On Fri,  4 Jan 2002 19:25:10 GMT, Ron Natalie <ron@sensor.com> wrote:
> >>
> >> 7) This one is really obscure. A union can contain two members
> >> ( with subobjects ) such that these subobjects overlap. Is it legal
> >> to assign one sucg object to another?
> >
> >This is a good one.
>
> Section 5.17, paragraph 8:
>
> If the value being stored in an object is accessed from another object
> that overlaps in any way the storage of the first object, then the
> overlap shall be exact and the two objects shall have the same type,
> otherwise the behavior is undefined.

What does "accessed from" mean?  Does it mean "loaded from
without an intervening sequence point"?  Because surely it
is acceptable to load a value from a subobject into something,
take a sequence point, and then store the value into an
overlapping subobject.

Given the function
  S f(S *s) { return *s; }
is it defined to pass one subobject and assign the result to an
overlapping subobject?  1.9#17 says there is a sequence point
between the copying of the return value (i.e. from *s, to
wherever the return value is) and the evaluation of any
expression outside the function.

What about
  S f(S *s) { S x = *s; return x; }



---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]





Author: Steve Clamage <clamage@eng.sun.com>
Date: Tue, 8 Jan 2002 17:05:36 GMT
Raw View
On Tue, 8 Jan 2002, Al Grant wrote:

> Date: Tue,  8 Jan 2002 15:19:36 GMT
> From: Al Grant <tnarga@arm.REVERSE-NAME.com>
> Newsgroups: comp.std.c++
> Subject: Re: Possible DRs
>
> "Stephen Clamage" <stephen.clamage@sun.com> wrote in message
> news:5lof3uk2f6t89sd4ohotn0lvmrqv8pr0s3@4ax.com...
> > On Fri,  4 Jan 2002 19:25:10 GMT, Ron Natalie <ron@sensor.com> wrote:
> > >>
> > >> 7) This one is really obscure. A union can contain two members
> > >> ( with subobjects ) such that these subobjects overlap. Is it legal
> > >> to assign one sucg object to another?
> > >
> > >This is a good one.
> >
> > Section 5.17, paragraph 8:
> >
> > If the value being stored in an object is accessed from another object
> > that overlaps in any way the storage of the first object, then the
> > overlap shall be exact and the two objects shall have the same type,
> > otherwise the behavior is undefined.
>
> What does "accessed from" mean?  Does it mean "loaded from
> without an intervening sequence point"?  Because surely it
> is acceptable to load a value from a subobject into something,
> take a sequence point, and then store the value into an
> overlapping subobject.

The section in question applies only to the assignment operator.
The question above was about assigning overlapping objects,
and this is the section that applies.

Your example of using an intermediate temporary objects
eliminates the overlapping assignment.

--
Steve Clamage, stephen.clamage@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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]





Author: Michiel Salters<Michiel.Salters@cmg.nl>
Date: Fri, 4 Jan 2002 23:26:04 GMT
Raw View
In article <3C36019C.32739F68@sensor.com>, Ron Natalie says...
>
>Michiel Salters wrote:
>
>>
>> 1)
>> What's the use of the access specifier "protected:" in unions ? They
>> can't be base classes anyway ?
>
>Not much, but do you want to add a special case for unions just because
>it doesn't have a good use?

Probably a QOI, yes. A warning is in order.

>> 2)
>> Why are the (additional) signatures of main() implementation-defined,
>> while their use is undefined? What good is it to know that your
>> implementation will accept a signature int main( float ); if you have
>> to fear that using it will format your HD?
>
>Where does it say it is undefined?  The idea was to allow additional
>implementation defined signatures like the UNIX:
> int main(int argc, char* argv[], char* env[]);
>construct.

Yes - but what does a program do using such a signature? A Unix compiler
must document only the signature.

>> 3)
>> What prohibits int f( volatile void )? What does it mean, if it
>> doesn't cause a program to be ill-formed?
>
>Ill-formed.  8.3.5 permits f(void) as a special case only in that
>exact form.

Yes, that's indeed the special case. But the reasoning by which
volatile void is ill-formed was not obvious to me.

>> 4)
>> Exactly what clause of the standard outlaws the use of reserved
>> keywords for other purposes ? int for; ?
>
>2.11 says "they are unconditionally treated as keywords in phase 7"
>which means they can never be resolved gramtically to identifiers
>(or any of the other types of tokens).  The same is true of the
>alternate operator/punctuatiior names.

Makes sense.

>> 5)
>> Is it legal to compare addresses of objects, if these objects are
>> members of different array elements? I.e. is &p[0].a < &p[1].b legal?
>> Is it always true ?
>
>unspecified from a literal reading of 5.9.

Dunno. Both are indirect part of the same arry p.

>> 6)
>> Pointers to members: Given
>> struct A { int a } ;
>> struct B : public A { };
>> struct C : public A { };
>> struct D : public B,C { };
>> D now has two members A::a, via B::A and C::A. So logically, pointers
>> are unequal. But since neither one is smaller or bigger than the other,
>> according to 5.9/2, what should > return ?
>
>D does not have any members.  It has subobjects B::A and C::A each with
>a member a.  The results of any such comparison is unspecified (members
>of different objects 5.9/2 second bulletted case).

Ok.

>> 7) This one is really obscure. A union can contain two members
>> ( with subobjects ) such that these subobjects overlap. Is it legal
>> to assign one sucg object to another?
>
>This is a good one.
>
>> Personally, I think 3) and 6) warrant DRs, but I'm not certain
>> about the others.
>
>Actually, I think 3 and 6 are fine.  7 is the one I am concerned about.

At least it's clear 1 and 4 don't matter.

Regards,

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]





Author: Stephen Clamage <stephen.clamage@sun.com>
Date: Mon, 7 Jan 2002 06:12:16 GMT
Raw View
On Fri,  4 Jan 2002 19:25:10 GMT, Ron Natalie <ron@sensor.com> wrote:
>>
>> 7) This one is really obscure. A union can contain two members
>> ( with subobjects ) such that these subobjects overlap. Is it legal
>> to assign one sucg object to another?
>
>This is a good one.

Section 5.17, paragraph 8:

If the value being stored in an object is accessed from another object
that overlaps in any way the storage of the first object, then the
overlap shall be exact and the two objects shall have the same type,
otherwise the behavior is undefined.

---
Steve Clamage, stephen.clamage@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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]





Author: "Anthony Williams"<anthwil@nortelnetworks.com>
Date: Mon, 7 Jan 2002 15:25:10 GMT
Raw View
"Michiel Salters" <Michiel.Salters@cmg.nl> wrote in message
news:QFqZ7.4501$cD4.8752@www.newsranger.com...
> In article <3C36019C.32739F68@sensor.com>, Ron Natalie says...
> >
> >Michiel Salters wrote:
> >> 3)
> >> What prohibits int f( volatile void )? What does it mean, if it
> >> doesn't cause a program to be ill-formed?
> >
> >Ill-formed.  8.3.5 permits f(void) as a special case only in that
> >exact form.
>
> Yes, that's indeed the special case. But the reasoning by which
> volatile void is ill-formed was not obvious to me.

8.3.5p2 says "The parameter list (void) is equivalent to the empty parameter
list. Except for this special case, void shall not be a parameter type
(though types derived from void, such as void*, can)."

So f(void) is permitted as the special case, f(int,void) is illegal. Fine.

Is volatile-T a "type derived from T"?

In any case, "The cv-qualified or cv-unqualified versions of a type are
distinct types;" (3.9.3p1), so "volatile void" is not "void", and is not
explicitly affected by this restriction.

8.9.1p9 introduces restrictions on void:

"The void type has an empty set of values. The void type is an incomplete
type that cannot be completed. It is used as the return type for functions
that do not return a value. Any expression can be explicitly converted to
type cv void (5.4). An expression of type void shall be used only as an
expression statement (6.2), as an operand of a comma expression (5.18), as a
second or third operand of ?: (5.16), as the operand of typeid, or as the
expression in a return statement (6.6.3) for a function with the return type
void."

However, is an expression of type cv-void necessarily of type void? If so,
why the distinction in the middle of the paragraph? If not, expressions can
be of type "const void", and can then be treated as normal rvalue
expressions --- except that non-class rvalues cannot have cv-qualified
types, so there isn't a problem (though I would personally like to see that
restriction removed, for consistency).

Indeed, since void is not an object type, function parameters of "volatile
void" (which is incomplete) are OK, as only object type parameters are
required to be complete (5.2.2p4)

8.3.2p1 prevents references to cv-void, but that doesn't affect this issue.

In any case, f(volatile void) can never be called, because you cannot have
an lvalue of type void to copy, and rvalues of type void cannot appear in
function call expressions.

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optical Components Ltd
The opinions expressed in this message are not necessarily those of my
employer



---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]





Author: Michiel Salters<Michiel.Salters@cmg.nl>
Date: Fri, 4 Jan 2002 17:52:15 GMT
Raw View
Hi,

I ran into some possible DRs today, when looking at appendix J of
the C99 standard ( Gert Jan de Vos & I were trying to determine which
of those points applies to C++, too ).

I'm not sure which deserve an DR, so I'd like some opinions here:

1)
What's the use of the access specifier "protected:" in unions ? They
can't be base classes anyway ?

2)
Why are the (additional) signatures of main() implementation-defined,
while their use is undefined? What good is it to know that your
implementation will accept a signature int main( float ); if you have
to fear that using it will format your HD?

3)
What prohibits int f( volatile void )? What does it mean, if it
doesn't cause a program to be ill-formed?

4)
Exactly what clause of the standard outlaws the use of reserved
keywords for other purposes ? int for; ?

5)
Is it legal to compare addresses of objects, if these objects are
members of different array elements? I.e. is &p[0].a < &p[1].b legal?
Is it always true ?

6)
Pointers to members: Given
struct A { int a } ;
struct B : public A { };
struct C : public A { };
struct D : public B,C { };
D now has two members A::a, via B::A and C::A. So logically, pointers
are unequal. But since neither one is smaller or bigger than the other,
according to 5.9/2, what should > return ?

7) This one is really obscure. A union can contain two members
( with subobjects ) such that these subobjects overlap. Is it legal
to assign one sucg object to another? Is this implementable? Can a
class provide protection against this? The usual self-assignment
protection fails, because the this-pointers aren't identical.

Personally, I think 3) and 6) warrant DRs, but I'm not certain
about the others.

Regards

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]





Author: Ron Natalie <ron@sensor.com>
Date: Fri, 4 Jan 2002 19:25:10 GMT
Raw View

Michiel Salters wrote:

>
> 1)
> What's the use of the access specifier "protected:" in unions ? They
> can't be base classes anyway ?

Not much, but do you want to add a special case for unions just because
it doesn't have a good use?

>
> 2)
> Why are the (additional) signatures of main() implementation-defined,
> while their use is undefined? What good is it to know that your
> implementation will accept a signature int main( float ); if you have
> to fear that using it will format your HD?

Where does it say it is undefined?  The idea was to allow additional
implementation defined signatures like the UNIX:
 int main(int argc, char* argv[], char* env[]);
construct.

> 3)
> What prohibits int f( volatile void )? What does it mean, if it
> doesn't cause a program to be ill-formed?

Ill-formed.  8.3.5 permits f(void) as a special case only in that
exact form.

>
> 4)
> Exactly what clause of the standard outlaws the use of reserved
> keywords for other purposes ? int for; ?

2.11 says "they are unconditionally treated as keywords in phase 7"
which means they can never be resolved gramtically to identifiers
(or any of the other types of tokens).  The same is true of the
alternate operator/punctuatiior names.

>
> 5)
> Is it legal to compare addresses of objects, if these objects are
> members of different array elements? I.e. is &p[0].a < &p[1].b legal?
> Is it always true ?

unspecified from a literal reading of 5.9.

>
> 6)
> Pointers to members: Given
> struct A { int a } ;
> struct B : public A { };
> struct C : public A { };
> struct D : public B,C { };
> D now has two members A::a, via B::A and C::A. So logically, pointers
> are unequal. But since neither one is smaller or bigger than the other,
> according to 5.9/2, what should > return ?

D does not have any members.  It has subobjects B::A and C::A each with
a member a.  The results of any such comparison is unspecified (members
of different objects 5.9/2 second bulletted case).

>
> 7) This one is really obscure. A union can contain two members
> ( with subobjects ) such that these subobjects overlap. Is it legal
> to assign one sucg object to another?

This is a good one.

>
> Personally, I think 3) and 6) warrant DRs, but I'm not certain
> about the others.

Actually, I think 3 and 6 are fine.  7 is the one I am concerned about.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]