In article <81arq4$gs6$1@halcyon.com>,
  aitken@halcyon.com (William E. Aitken) wrote:
>
>  Note that I agree with the committee's decision that issue 55
> is a no defect [at least I do now].  I simply believe that their
> rationale is sub-optimal.  It seems that the language of clause 13
> yields the same conclusions without having to resort to awkward
> readings of 5p9.  As someone has already pointed out on this thread,
> because one of the operands has a user defined type, clause 13
> applies.  The language of 13.6p13 and 13.3.1.2p7 make it abundantly
> clear that by the time clause 5 gets a chance to operate, the
> non-pointer operand will have type ptrdiff_t.  A case can be made that
> all the references to enumeration types in this section [and probably
> most other parts of clause 5] are somewhat misleading, but it's
> difficult to argue that this is worthy of a TC.

I believe you are correct here; I'll add these references to the
rationale for that issue.  (The "usual arithmetic conversions"
rationale is still the only one that gives the correct results for
wchar_t and bool operands, though.)

Thanks for pointing this out.
--
William M. Miller, wmm@fastdial.net
OnDisplay, Inc. (www.ondisplay.com)


Sent via Deja.com http://www.deja.com/
Before you buy.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
>
>It makes perfect sense to me. Did you read all of the sections
>I referred to? The enum gets promoted to an integer type in
>an additive-expression.
>
With the use of 5p9, which is defined for two operands of
arithmetic or enum type. If we now use it with pointer+enum,
what happens with the pointer operand?

As an example, after the fourth bullet (integral promotions),
the fifth bullet reads:

  - Then, if either operand is unsigned long the other shall be
    converted to unsigned long

If the enum gets promoted to unsigned long, the pointer shall
also be converted to unsigned long? I really don't think that
this is the intention.

I don't see any special rule saying that only part of 5p9
may be used or that only one operand may be subject to
these conversions in this case.

I'm not arguing against the obvious, that the enum should
be converted to some integral type so it can be used in 5.7p5
It's just the way it is done, with 5p9 and some kind of
changed semantic to "hide" the fact that there is also a
pointer operand involved, that I find peculiar.

>But where is the advantage in prohibiting subtracting a
>value from itself?
>
The advantage is to prohibit arithmetic involving pointer to functions
(and from your text I assume you also mean pointer to members) as it
seems to have limited use. Personally I just think it brings in
too much nuisance with very little gained.

I don't think C allows this kind of arithmetic. Does it?
(not that it make any difference, just interesting to know)


Regards
//Gabriel

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

[I replied to an earlier posting in this thread with essentially
similar material to the following, but it never appeared.  I'll try
again here.]

In article <811vvo$7j2$1@halcyon.com>,
  aitken@halcyon.com (William E. Aitken) wrote:
>
> In article <3832EDE9.1537D1E9@sun.com>,
> Steve Clamage  <stephen.clamage@sun.com> wrote:
> >
> >Gabriel Netterdag wrote:
> >>
> >> Steve Clamage wrote:
> >> >
> >> > Gabriel Netterdag wrote:
> >> > >
> >> > > The usual arithmetic conversions is meant to bring two
> >> > > operands of arithmetic/enumeration type to a common type.
> >> > > As it only applies to arithmetic/enumeration types, I don't
> >> > > see what the rationale for core issue 55 solve.
> >> >
> >> > The section on "usual arithmetic conversions" in 5 paragraph 9
> >> > says that the integral promotions are performed.  The integral
> >> > promotions are defined in 4.5, in which paragraph 2 says enums
> >> > are promted to an int or long type. Thus, no special rule is
> >> > needed for pointer+enum.
> >> >
> >> "Usual arithmetic conversions" only make sense when both operands
> >> are of arithmetic or enumeration type.
> >
> >It makes perfect sense to me. Did you read all of the sections
> >I referred to? The enum gets promoted to an integer type in
> >an additive-expression.
> >
>
> What about the note at the very end of 5 p9?
>
> "Note: otherwise, the only remaining case is that both operands are
{\tt int.}"
>
> This is only true if both types were arithmetic or enumeration types
> to begin with.  This certainly suggests to me that whoever originally
> drafted this section only intended it to define the usual arithmetic
> conversions for a pair of types both of which were either arithmetic
> or enumeration types.
>
> Actually, the second sentence of 5 p9 states "the purpose is to yield
> a common type, which is also the type of the result."  This seems to
> suggest that the proposed resolution of issue 55 is at best an abuse
> of the usual arithmetic conversions.   In fact, the second part of
this
> sentence, taken literally, seems to preclude the use of the standard
> arithmetic conversions in describing the semantics of the relational
> operators, since there result type is actually bool, not the common
type
> produced by the usual arithmetic conversions.

The use of the "usual arithmetic conversions" is a bit awkward in
the case of a pointer and an enum (or wchar_t or bool) operand.  The
description of the "usual arithmetic conversions" was obviously
written with a view toward operations with two arithmetic operands.
Nevertheless, 5.7p1 says, "The usual arithmetic conversions are
performed for operands of arithmetic or enumeration type."  In the
case of a pointer and an enum, the conversions are not applied to
the pointer operand but they are applied to the enum.  The only one
of the bullets in the description in 5p9 that can be applied to an
enum operand in the case where the other operand is not arithmetic
or enumeration is the fourth bullet, so the enum operand is promoted
to an integral type according to the integral promotions in 4.5.

It would probably have been cleaner if the wording of 5.7p1 were
something like, "If both operands are of arithmetic or enumeration
type, the usual arithmetic conversions are performed on both
operands; otherwise, if either operand has integral or enumeration
type, the integral promotions are performed on that operand."
However, it was the considered opinion of the core language working
group that the existing language is sufficiently clear in achieving
that effect that no defect report is required.

The mandate of the Committee at this point is to change the Standard
only where it is manifestly wrong -- where there is an unresolvable
self-contradiction, where the existing language would lead a
careful reader to a different conclusion than was intended by the
Committee, or where the Standard fails to address a critical question.

Those criteria do not apply in this case.  The clear intention of the
Committee was to have enums promoted to integral type in this kind of
expression, and a close and careful application of the existing words
leads to that result.

I imagine the wording will be cleaned up when the Standard is opened
for review after five years.  At this point, the wording, though less
than ideal, is good enough not to cause compiler writers to implement
the feature incorrectly; there is not sufficiently urgency to require
that it be addressed in a Technical Corrigendum.

> >>
> >> > > I also wonder why 5.7p8 mention subtraction of function
pointers.
> >> >
> >> > Because it is valid to subtract two function pointers as long as
they
> >> > point to the same function. The result is a null pointer. If that
> >> > provision were not included, the subtraction would not be
allowed,
> >> > and there is no reason to prohibit it.
> >> >
>
>    But subtraction of function pointers isn't legal anyway.   5.7
Paragraph 2
> states requirements on the two operands of subtraction.   There are
three
> possibilities, and none of them allows function pointers.   All
pointer types in
> this paragraph are required to be pointers to completely defined
object types.

This is a good point.  I will be adding an issue to the core language
issues list regarding the contradiction between 5.7p2 and 5.7p8.
--
William M. Miller, wmm@fastdial.net
OnDisplay, Inc. (www.ondisplay.com)


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8148i9$4qs$1@nnrp1.deja.com>,  <wmm@fastdial.net> wrote:
>[I replied to an earlier posting in this thread with essentially
>similar material to the following, but it never appeared.  I'll try
>again here.]
>
>However, it was the considered opinion of the core language working
>group that the existing language is sufficiently clear in achieving
>that effect that no defect report is required.
>
>The mandate of the Committee at this point is to change the Standard
>only where it is manifestly wrong -- where there is an unresolvable
>self-contradiction, where the existing language would lead a
>careful reader to a different conclusion than was intended by the
>Committee, or where the Standard fails to address a critical question.
>
>Those criteria do not apply in this case.  The clear intention of the
>Committee was to have enums promoted to integral type in this kind of
>expression, and a close and careful application of the existing words
>leads to that result.
>

 Note that I agree with the committee's decision that issue 55
is a no defect [at least I do now].  I simply believe that their
rationale is sub-optimal.  It seems that the language of clause 13
yields the same conclusions without having to resort to awkward
readings of 5p9.  As someone has already pointed out on this thread,
because one of the operands has a user defined type, clause 13
applies.  The language of 13.6p13 and 13.3.1.2p7 make it abundantly
clear that by the time clause 5 gets a chance to operate, the
non-pointer operand will have type ptrdiff_t.  A case can be made that
all the references to enumeration types in this section [and probably
most other parts of clause 5] are somewhat misleading, but it's
difficult to argue that this is worthy of a TC.

>> [explanation of seeming discrepency between 5.7p2 & 5.7p8]
>
>
>This is a good point.  I will be adding an issue to the core language
>issues list regarding the contradiction between 5.7p2 and 5.7p8.

thanks.

--
William E. Aitken        | Formal verification is the
email: aitken@halcyon.com                   |  future of computer science ---
Snail: 6124 86th Ave SE Mercer Island WA    | Always has been, always will be.
===============================================================================


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

wmm@fastdial.net wrote:
>
> The first three bullets of 5p9 don't apply to the enum operand,
> but the fourth bullet does: "Otherwise, the integral promotions
> (4.5) shall be performed on both operands."  (The Standard is a bit
> awkward here, since the "usual arithmetic conversions" are only
> being applied to the enum operand and not the pointer operand, so
> "both operands" is a bit of a misnomer, but it is clear enough that
> this is what was intended that we didn't feel a DR was warranted.)
>
Awkward indeed. It is this partial use of 5p9 that doesn't agree with
the description and purpose of the "usual arithmetic conversions".
If the intention is to use integral promotions, why not just say so?

Regards
//Gabriel
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3830A655.4D56B6C2@quidsoft.se>,
  Gabriel Netterdag <gabriel.netterdag@quidsoft.se> wrote:
> Steve Clamage wrote:
> >
> > Gabriel Netterdag wrote:
> > >
> > > The usual arithmetic conversions is meant to bring two
> > > operands of arithmetic/enumeration type to a common type.
> > > As it only applies to arithmetic/enumeration types, I don't
> > > see what the rationale for core issue 55 solve.
> >
> > The section on "usual arithmetic conversions" in 5 paragraph 9
> > says that the integral promotions are performed.  The integral
> > promotions are defined in 4.5, in which paragraph 2 says enums
> > are promted to an int or long type. Thus, no special rule is
> > needed for pointer+enum.
> >
> "Usual arithmetic conversions" only make sense when both operands
> are of arithmetic or enumeration type. Going through the steps
> described in 5p9 with an pointer operand and an enumeration operand
> will end up at the note (under the last bullet), where it is assumed
> that both operands are of int type. As I see it, the whole point of
> the "usual arithmetic conversions" is to bring the operands to a
> common type, which also is the result type.
> In the case pointer+enum there is no common type, neither should
> there be one.

As I said in my other posting in this thread, use of the "usual
arithmetic conversions" in operations involving a pointer and an enum
is a bit awkward.  As you point out, there is no common type, and
that is the primary purpose of the "usual arithmetic conversions."
However, the fact is that 5.7p1 says that they are "performed for
operands of arithmetic or enumeration type."  In the case of a
pointer and an enumeration, they don't apply to the pointer operand
but do apply to the enumeration operand, and the result is that the
enumeration operand is promoted to an integral type.  (The same is
true for wchar_t and bool operands.)  Consequently, the description
in 5.7p5 already describes what happens with enum, bool, and wchar_t
operands because they no longer have that type, they are now
expressions of integral type.

It might have been cleaner if 5.7p1 said something like, "If both
operands have arithmetic or enumeration type, the usual arithmetic
conversions are performed; otherwise the integral promotions are
performed on any operand of integral or enumeration type."  However,
the core language working group felt that the current wording was
clear enough (with this as the effect) that it did not constitute a
defect in the Standard.

> > > I also wonder why 5.7p8 mention subtraction of function pointers.
> >
> > Because it is valid to subtract two function pointers as long as
they
> > point to the same function. The result is a null pointer. If that
> > provision were not included, the subtraction would not be allowed,
> > and there is no reason to prohibit it.
> >
> But that's not what 5.7p2 say:
>
> For subtraction one of the following shall hold:
>  - both operands have arithmetic or enumeration type; or
>  - both operands are pointers to cv-qualified or cv-unqualified
versions
>    of the same completely defined object type; or
>  - the left operand is a pointer to a completely defined object type
and
>    the right operand has integral or enumeration type.

You're right, this is an inconsistency in the wording of the Standard
and I will open an issue in the core language issues list.

> What is the reason to allow it? As I see it, the only thing you can do
> (without invoking undefined behavior) is to calculate ptrdiff_t(0).

I'll mention this opinion in the description of the issue.
--
William M. Miller, wmm@fastdial.net
OnDisplay, Inc. (www.ondisplay.com)


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <t73du3bm4t.fsf@calumny.jyacc.com>,
  Hyman Rosen <hymie@prolifics.com> wrote:
>
> Steve Clamage <stephen.clamage@sun.com> writes:
> > Because it is valid to subtract two function pointers as
> > long as they point to the same function. The result is
[zero].
> > If that provision were not included, the subtraction would
> > not be allowed, and there is no reason to prohibit it.
>
> The reason to prohibit it is so that the provision would
> not need to be included in the standard. If the only time
> it is permitted to subtract two function pointers is when
> they are known to be equal, then of what use is the
> construct? The compiler can simply replace *any* such
> subtraction by zero, without examining the two pointers at
> all!

I'm not a compiler implementor, so this may be just a wild
guess. But it seems to me that disallowing the subtraction
would be yet another special case that the compiler would
have to check for. Currently, every single type of pointer
defines subtraction. There are many cases where the result
is undefined, such as where the two pointers are not part
of the same complete object, but there are no cases where
subtraction of two pointers of like type requires a compiler
diagnostic.

Two pointers to functions can't point to functions in the
same "complete object" unless they point to the very same
function, so the only time that the subtraction would be
meaningful is also the special case where we know the
answer ahead of time. But requiring the compiler to
identify this special case -- weather we make it illegal
or require the answer to always be 0 -- would add at
least a small complication to what is already a fairly
complicated language.

In other words, it pays to be permissive when the rule
won't help us to catch bad programming practices. There's
no reason to forbid the subtraction, so we shouldn't
forbid the subtraction!

Besides, I think that it makes perfect sense to compare
two pointers-to-function for equality, and that certainly
seems related. Why would we allow (p==q) but not allow
((p-q)==0)?

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW <allan_w@my-deja.com> writes:
> Currently, every single type of pointer defines subtraction.

No. You can not subtract void * pointers.

> In other words, it pays to be permissive when the rule
> won't help us to catch bad programming practices. There's
> no reason to forbid the subtraction, so we shouldn't
> forbid the subtraction!

But subtracting two function pointers *is* bad practice,
so disallowing it would help catch errors. How can a
construct whose value is 0 whenever it's not undefined
be anything but an error?

> Besides, I think that it makes perfect sense to compare
> two pointers-to-function for equality, and that certainly
> seems related. Why would we allow (p==q) but not allow
> ((p-q)==0)?

Because if p != q, then (p - q) is undefined. And this same
construct is not legal for void * pointers.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gabriel Netterdag <gabriel.netterdag@quidsoft.se> wrote:

> 5.7p5 doesn't explain the semantics when one operand
> is of pointer type and the other of enum type. It only
> explains the case where the operand is of integral type.

An enum type is a user defined type, so we have to watch for operator
overloading.

Unless there is a user-defined operator available, we will end up at
13.6/13 and the enum should be converted to ptrdiff_t.

At the beginning of 13.6 there is a statement that, after overload
resolution has resolved to a built-in operator, additional restrictions
from clause 5 may apply.

I can see no such restriction in 5.7/1 or 5.7/5. Enumerated types are
explicitly allowed. Therefore 13.6/13 seems to suggest that the enum
value will be converted to ptrdiff_t, which would generally require an
integral promotion followed by an integral conversion.

Maybe 5.7/5 should state that all integral or enumeration types should
be promoted to ptrdiff_t ?

A look at 13.6 may also explain why subtraction of equal function
pointers may have been allowed.

-- J   rg Barfurth



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <382BF564.F3B270C7@quidsoft.se>,
  Gabriel Netterdag <gabriel.netterdag@quidsoft.se> wrote:
> 5.7p5 doesn't explain the semantics when one operand
> is of pointer type and the other of enum type. It only
> explains the case where the operand is of integral type.
>
> I noticed that this issue already have been raised in a DR,
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/core8.htm#55,
> but ended up as a NAD (Not A Defect) and I find the
> rationale somewhat surprising:
>
>     Paragraph 1 invokes "the usual arithmetic conversions"
>     for operands of enumeration type.
>
> The usual arithmetic conversions is meant to bring two
> operands of arithmetic/enumeration type to a common type.
> As it only applies to arithmetic/enumeration types, I don't
> see what the rationale for core issue 55 solve.

5.7p1 says, "The usual arithmetic conversions are performed for
operands of arithmetic or enumeration type."  Although "the usual
arithmetic conversions" (5p9) don't apply to the pointer operand,
they do apply to the enum operand.

The first three bullets of 5p9 don't apply to the enum operand,
but the fourth bullet does: "Otherwise, the integral promotions
(4.5) shall be performed on both operands."  (The Standard is a bit
awkward here, since the "usual arithmetic conversions" are only
being applied to the enum operand and not the pointer operand, so
"both operands" is a bit of a misnomer, but it is clear enough that
this is what was intended that we didn't feel a DR was warranted.)

According to 4.5p2, the enum is converted to an int, unsigned, long,
or unsigned long, depending on its underlying type.

Thus 5.7p5 doesn't need to describe how an enum is handled; by that
point, it's already been promoted to an integral type, and the
description of how to handle an integral type is sufficient.

> I also wonder why 5.7p8 mention subtraction of function pointers.

Probably just so that the intuitive identity between "p == q" and
"p - q == 0" will be maintained for all pointers, not just for
pointers to objects.
--
William M. Miller, wmm@fastdial.net
OnDisplay, Inc. (www.ondisplay.com)


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gabriel Netterdag wrote:
>
> Steve Clamage wrote:
> >
> > Gabriel Netterdag wrote:
> > >
> > > The usual arithmetic conversions is meant to bring two
> > > operands of arithmetic/enumeration type to a common type.
> > > As it only applies to arithmetic/enumeration types, I don't
> > > see what the rationale for core issue 55 solve.
> >
> > The section on "usual arithmetic conversions" in 5 paragraph 9
> > says that the integral promotions are performed.  The integral
> > promotions are defined in 4.5, in which paragraph 2 says enums
> > are promted to an int or long type. Thus, no special rule is
> > needed for pointer+enum.
> >
> "Usual arithmetic conversions" only make sense when both operands
> are of arithmetic or enumeration type.

It makes perfect sense to me. Did you read all of the sections
I referred to? The enum gets promoted to an integer type in
an additive-expression.

>
> > > I also wonder why 5.7p8 mention subtraction of function pointers.
> >
> > Because it is valid to subtract two function pointers as long as they
> > point to the same function. The result is a null pointer. If that
> > provision were not included, the subtraction would not be allowed,
> > and there is no reason to prohibit it.
> >
>
> What is the reason to allow it? As I see it, the only thing you can do
> (without invoking undefined behavior) is to calculate ptrdiff_t(0).

But where is the advantage in prohibiting subtracting a value from itself?

--
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
> Gabriel Netterdag wrote:
>> I also wonder why 5.7p8 mention subtraction of function pointers.
>
> Because it is valid to subtract two function pointers as long as they
> point to the same function. The result is a null pointer.

I think you meant that the result is zero, not null.

-- David R. Tribble, david@tribble.com, http://david.tribble.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage <stephen.clamage@sun.com> writes:
> Because it is valid to subtract two function pointers as long as they
> point to the same function. The result is a null pointer. If that
> provision were not included, the subtraction would not be allowed,
> and there is no reason to prohibit it.

The reason to prohibit it is so that the provision would not need
to be included in the standard. If the only time it is permitted
to subtract two function pointers is when they are known to be
equal, then of what use is the construct? The compiler can simply
replace *any* such subtraction by zero, without examining the two
pointers at all!


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3832EDE9.1537D1E9@sun.com>,
Steve Clamage  <stephen.clamage@sun.com> wrote:
>
>Gabriel Netterdag wrote:
>>
>> Steve Clamage wrote:
>> >
>> > Gabriel Netterdag wrote:
>> > >
>> > > The usual arithmetic conversions is meant to bring two
>> > > operands of arithmetic/enumeration type to a common type.
>> > > As it only applies to arithmetic/enumeration types, I don't
>> > > see what the rationale for core issue 55 solve.
>> >
>> > The section on "usual arithmetic conversions" in 5 paragraph 9
>> > says that the integral promotions are performed.  The integral
>> > promotions are defined in 4.5, in which paragraph 2 says enums
>> > are promted to an int or long type. Thus, no special rule is
>> > needed for pointer+enum.
>> >
>> "Usual arithmetic conversions" only make sense when both operands
>> are of arithmetic or enumeration type.
>
>It makes perfect sense to me. Did you read all of the sections
>I referred to? The enum gets promoted to an integer type in
>an additive-expression.
>

What about the note at the very end of 5 p9?

"Note: otherwise, the only remaining case is that both operands are {\tt int.}"

This is only true if both types were arithmetic or enumeration types
to begin with.  This certainly suggests to me that whoever originally
drafted this section only intended it to define the usual arithmetic
conversions for a pair of types both of which were either arithmetic
or enumeration types.

Actually, the second sentence of 5 p9 states "the purpose is to yield
a common type, which is also the type of the result."  This seems to
suggest that the proposed resolution of issue 55 is at best an abuse
of the usual arithmetic conversions.   In fact, the second part of this
sentence, taken literally, seems to preclude the use of the standard
arithmetic conversions in describing the semantics of the relational
operators, since there result type is actually bool, not the common type
produced by the usual arithmetic conversions.

>>
>> > > I also wonder why 5.7p8 mention subtraction of function pointers.
>> >
>> > Because it is valid to subtract two function pointers as long as they
>> > point to the same function. The result is a null pointer. If that
>> > provision were not included, the subtraction would not be allowed,
>> > and there is no reason to prohibit it.
>> >

   But subtraction of function pointers isn't legal anyway.   5.7 Paragraph 2
states requirements on the two operands of subtraction.   There are three
possibilities, and none of them allows function pointers.   All pointer types in
this paragraph are required to be pointers to completely defined object types.
In short, it seems that this provision defines required behavior of ill
formed programs.   Is this really what we want?


--
William E. Aitken        | Formal verification is the
email: aitken@halcyon.com                   |  future of computer science ---
Snail: 6124 86th Ave SE Mercer Island WA    | Always has been, always will be.
===============================================================================


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gabriel Netterdag wrote:
>
> 5.7p5 doesn't explain the semantics when one operand
> is of pointer type and the other of enum type. It only
> explains the case where the operand is of integral type.
>
> I noticed that this issue already have been raised in a DR,
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/core8.htm#55,
> but ended up as a NAD (Not A Defect) and I find the
> rationale somewhat surprising:
>
>     Paragraph 1 invokes "the usual arithmetic conversions"
>     for operands of enumeration type.
>
> The usual arithmetic conversions is meant to bring two
> operands of arithmetic/enumeration type to a common type.
> As it only applies to arithmetic/enumeration types, I don't
> see what the rationale for core issue 55 solve.

The section on "usual arithmetic conversions" in 5 paragraph 9
says that the integral promotions are performed.  The integral
promotions are defined in 4.5, in which paragraph 2 says enums
are promted to an int or long type. Thus, no special rule is
needed for pointer+enum.

>
> I also wonder why 5.7p8 mention subtraction of function pointers.

Because it is valid to subtract two function pointers as long as they
point to the same function. The result is a null pointer. If that
provision were not included, the subtraction would not be allowed,
and there is no reason to prohibit it.

--
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
>
> Gabriel Netterdag wrote:
> >
> > The usual arithmetic conversions is meant to bring two
> > operands of arithmetic/enumeration type to a common type.
> > As it only applies to arithmetic/enumeration types, I don't
> > see what the rationale for core issue 55 solve.
>
> The section on "usual arithmetic conversions" in 5 paragraph 9
> says that the integral promotions are performed.  The integral
> promotions are defined in 4.5, in which paragraph 2 says enums
> are promted to an int or long type. Thus, no special rule is
> needed for pointer+enum.
>
"Usual arithmetic conversions" only make sense when both operands
are of arithmetic or enumeration type. Going through the steps
described in 5p9 with an pointer operand and an enumeration operand
will end up at the note (under the last bullet), where it is assumed
that both operands are of int type. As I see it, the whole point of
the "usual arithmetic conversions" is to bring the operands to a
common type, which also is the result type.
In the case pointer+enum there is no common type, neither should
there be one.

> > I also wonder why 5.7p8 mention subtraction of function pointers.
>
> Because it is valid to subtract two function pointers as long as they
> point to the same function. The result is a null pointer. If that
> provision were not included, the subtraction would not be allowed,
> and there is no reason to prohibit it.
>
But that's not what 5.7p2 say:

For subtraction one of the following shall hold:
 - both operands have arithmetic or enumeration type; or
 - both operands are pointers to cv-qualified or cv-unqualified versions
   of the same completely defined object type; or
 - the left operand is a pointer to a completely defined object type and
   the right operand has integral or enumeration type.

What is the reason to allow it? As I see it, the only thing you can do
(without invoking undefined behavior) is to calculate ptrdiff_t(0).


Regards
//Gabriel
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

5.7p5 doesn't explain the semantics when one operand
is of pointer type and the other of enum type. It only
explains the case where the operand is of integral type.

I noticed that this issue already have been raised in a DR,
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/core8.htm#55,
but ended up as a NAD (Not A Defect) and I find the
rationale somewhat surprising:

    Paragraph 1 invokes "the usual arithmetic conversions"
    for operands of enumeration type.

The usual arithmetic conversions is meant to bring two
operands of arithmetic/enumeration type to a common type.
As it only applies to arithmetic/enumeration types, I don't
see what the rationale for core issue 55 solve.

I also wonder why 5.7p8 mention subtraction of function pointers.

Regards
//Gabriel
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]