Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #85954

Re: `bool` in pointer arithmetic: when does the promotion occur, if ever?

Show all headers | View raw

On 15/08/2022 22:59, Andrey Tarasevich wrote:
> On 8/15/2022 12:20 PM, David Brown wrote:
>>>
>>> Obviously, in pointer+bool contexts operands are NOT converted to a 
>>> common integer type. So, no, usual arithmetic conversions do not 
>>> apply here. As I already stated, the intent of the standard wording 
>>> is to say that usual arithmetic conversions apply only when _both_ 
>>> operands have integral or enum type.
>>>
>>
>> Read the paragraphs in the standards, and follow the rules.  When you 
>> write "p + b", with "p" being a pointer-to-int and "b" being a bool, 
>> you get the following chain:
> 
> That's exactly what I'm doing.
> 
>> "7.6.6 Additive operators" says "The usual arithmetic conversions 
>> (7.4) are performed for operands of arithmetic or enumeration type."  
>> The pointer is not an arithmetic or enumeration type, but the boolean is.
>>
>> The "7.4 Usual arithmetic conversions" are primarily concerned about 
>> two operands, but the pattern-matching list of "Otherwise, if either 
>> operand is ..." can be applied to a single operand too. 
> 
> That does not mean that you can simply pluck that part out of the whole 
> rule and nonchalantly discard the rest. (And I feel like I'm repeating 
> myself.)

Yes, you /can/.  These sections are written as lists of "otherwise, if 
..." rules.  Once you've triggered such a rule, the others on the list 
/can/ be discarded.  If none are triggered, then nothing happens - no 
promotions or conversions apply, nor is the code explicitly ruled valid 
or invalid.

> 
>> Since there are no floats, we hit "the integral promotions shall be 
>> performed on both operands" - in this case, just the one.  None of the 
>> rules after that are triggered.
> 
> That's not true. And I already covered this above.

I agree that "in pointer+bool contexts operands are NOT converted to a 
common integer type".  But I disagree that this means the paragraphs 
about "usual arithmetic conversions" and "integral promotions" don't 
apply - the standards explicitly say they do.

> 
> Firstly, the "rules after that" attempt to apply the concept of integer 
> conversion rank to both operands, which is not defined for pointer 
> types. The C++ standard does not adhere to the principle that "if some 
> rule is stated nonsensically then it is simply not triggered". Such 
> rules would be hard defects.

SFINAE ?

I think the way it is written /is/ defective - it is not clear enough 
how these rules apply.  I am merely trying to explain how /I/ interpret 
them.  My interpretation gives almost certainly the same results as the 
C++ committee intended, and it matches both the C standards (which are 
clearer here) and implementations.  But that does not mean it is correct 
- there may be other explanations that give the same resulting 
behaviour, and it may be that the standard is defective and there are no 
consistent readings of the standard here.


> 
> Secondly, in any case these rules cannot be brushed off under "not 
> triggered" premise because the very last rule in the list is a "sink": 
> it is not protected by a trigger at all, it is unconditional. If none of 
> the previous rules are "triggered" then the last rule applies:
> 
>    http://eel.is/c++draft/expr.arith.conv#1.3.5
>    - Otherwise, both operands are converted to the unsigned integer type 
> corresponding to the type of the operand with signed integer type.
> 
> What do you expect this to do if one operand is a pointer?

It doesn't get that far.  As I interpret this, only the bool gets the 
"usual arithmetic conversions" - thus references to "both operands" only 
apply to the single operand.  After the integral promotions are 
performed (turning the bool into int), we get "If both operands have the 
same type, no further conversion is needed" and stop there.

> 
> I thought that this problem would be obvious, but apparently I need to 
> spell out every detail... So, it is is actually me who's telling you to 
> "read the paragraphs in the standards, and follow the rules".

I'm sorry - I thought it was /you/ who asked the original question, 
looking for help?  And the thanks I get for going through the paragraphs 
and explaining as best I can how I read the standards, is to get my head 
bitten off?

Maybe my understanding of the standards is not quite right.  Maybe my 
explanation wasn't great.  But if this is your idea of how to say "I 
don't see it that way, but thanks for trying", I'll leave you to figure 
things out some other way.  Perhaps someone else will reply to you, and 
maybe give you a reading that you'd prefer.

> 
>> (Perhaps the "usual arithmetic conversions" are actually applied to 
>> both operands.  A pointer would return unscathed by "integral 
>> promotions" as it matches none of the rule triggers there.)
> 
> Yes, integral promotions are safe specifically because of this: every 
> rule in integral promotions is protected by an "if barrier" and 
> therefore it leaves pointers unchanged (assuming a pointer can get there 
> legally).
> 
> But the question is not about integral promotions. The question is about 
> usual arithmetic conversions. Rules of usual arithmetic conversions do 
> not implement this kind of protection.
> 

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

`bool` in pointer arithmetic: when does the promotion occur, if ever? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-08-15 10:45 -0700
  Re: `bool` in pointer arithmetic: when does the promotion occur, if ever? David Brown <david.brown@hesbynett.no> - 2022-08-15 20:09 +0200
    Re: `bool` in pointer arithmetic: when does the promotion occur, if ever? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-08-15 11:29 -0700
      Re: `bool` in pointer arithmetic: when does the promotion occur, if ever? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-08-15 11:35 -0700
      Re: `bool` in pointer arithmetic: when does the promotion occur, if ever? David Brown <david.brown@hesbynett.no> - 2022-08-15 21:20 +0200
        Re: `bool` in pointer arithmetic: when does the promotion occur, if ever? red floyd <no.spam.here@its.invalid> - 2022-08-15 13:49 -0700
        Re: `bool` in pointer arithmetic: when does the promotion occur, if ever? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-08-15 13:59 -0700
          Re: `bool` in pointer arithmetic: when does the promotion occur, if ever? David Brown <david.brown@hesbynett.no> - 2022-08-16 09:12 +0200
            Re: `bool` in pointer arithmetic: when does the promotion occur, if ever? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-08-16 09:56 -0700
              Re: `bool` in pointer arithmetic: when does the promotion occur, if ever? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-15 07:18 -0700
                Re: `bool` in pointer arithmetic: when does the promotion occur, if ever? Language Lawyer <language.lawyer@gmail.com> - 2022-09-19 03:28 -0700
                Re: `bool` in pointer arithmetic: when does the promotion occur, if ever? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-02 12:37 -0700
  Re: `bool` in pointer arithmetic: when does the promotion occur, if ever? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-15 14:36 -0700
    Re: `bool` in pointer arithmetic: when does the promotion occur, if ever? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-15 14:57 -0700
  Re: `bool` in pointer arithmetic: when does the promotion occur, if ever? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-08-16 21:13 +0200
  Re: `bool` in pointer arithmetic: when does the promotion occur, if ever? Language Lawyer <language.lawyer@gmail.com> - 2022-08-17 09:08 -0700

csiph-web