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

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

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

Show all headers | View raw

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.)

> 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.

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.

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?

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".

> (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.

-- 
Best regards,
Andrey

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