Harald van Dijk via austin-group-l at The Open Group wrote in
 <[email protected]>:
 |On 03/09/2024 19:52, Martijn Dekker via austin-group-l at The Open Group 
 |wrote:
 |> Op 02-09-2024 om 21:30 schreef Steffen Nurpmeso via austin-group-l at 
 |> The Open Group:
 |>> At times you even get answers like "we already do more than
 |>> required", but noone understands why "+10++11" is a correctly
 |>> handled case, whereas "+10++VAR" is not, and if you generate
 |> 
 |> In ksh, this is an error:
 |> 
 |> $ echo $((+10++11))
 |> -ksh: +10++11: assignment requires lvalue
 |> 
 |> Does POSIX require this to work? ksh is finding an incorrect use of the 
 |> ++ increment prefix operator. Correct is:
 |> 
 |> $ echo $((+10+ +11))
 |> 21
 |
 |POSIX does not require ++ to be implemented but does not forbid it 
 |either. It says:
 |
 |   The sizeof() operator and the prefix and postfix "++" and "--"
 |   operators are not required.
 |
 |It is fine for shells to implement features that are not required, and 
 |if the "++" feature is implemented, it is correct for it to result in an 
 |error in this example, the C rules that POSIX defers to specify that 
 |this is treated as a ++, not two consecutive +s, even if that then 
 |results in a syntax error.

i want to point out again that in some shells "+10++VAR" is
interpreted as "+10 + +VAR" whereas "+10++11" is not interpreted
as "+10 + +11", which is an oddity.  I think it is a more
sensitive approach to normalize it to something that works, than
to treat both cases as errors (after X years of having this
behaviour in the wild; and yes, who does it is a playboy/girl, but
i will not forbid people to have fun with their tools).

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

    • Re: [10... Steffen Nurpmeso via austin-group-l at The Open Group
      • Re:... Harald van Dijk via austin-group-l at The Open Group
        • ... Steffen Nurpmeso via austin-group-l at The Open Group
          • ... Harald van Dijk via austin-group-l at The Open Group
            • ... Steffen Nurpmeso via austin-group-l at The Open Group
  • [1003.1(2024... Austin Group Bug Tracker via austin-group-l at The Open Group
    • Re: [10... Steffen Nurpmeso via austin-group-l at The Open Group
      • Re:... Martijn Dekker via austin-group-l at The Open Group
        • ... Steffen Nurpmeso via austin-group-l at The Open Group
        • ... Harald van Dijk via austin-group-l at The Open Group
          • ... Steffen Nurpmeso via austin-group-l at The Open Group
            • ... Steffen Nurpmeso via austin-group-l at The Open Group
  • [1003.1(2024... Austin Group Bug Tracker via austin-group-l at The Open Group
    • Re: [10... Geoff Clare via austin-group-l at The Open Group
    • Re: [10... Harald van Dijk via austin-group-l at The Open Group
      • Re:... Geoff Clare via austin-group-l at The Open Group
  • [1003.1(2024... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2024... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2024... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2024... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2024... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to