All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
To: David Sletten <david.paul.sletten@gmail.com>
Cc: linux-man@vger.kernel.org, mtk.manpages@gmail.com
Subject: Re: Error in 'man operator'
Date: Sat, 28 Aug 2021 02:01:39 +0200	[thread overview]
Message-ID: <40cbdcb1-1356-b749-ed53-61ed9dc2dd2e@gmail.com> (raw)
In-Reply-To: <71c78812-940e-8c15-c9ae-0dcde955232d@gmail.com>

Hi David,

On 8/28/21 1:39 AM, Alejandro Colomar (man-pages) wrote:
> Hi,
> 
> On 8/27/21 8:11 PM, David Sletten wrote:
>> Hi,
>>
>> I've run across what I believe is a minor error in the man page for C 
>> operators (https://man7.org/linux/man-pages/man7/operator.7.html ).
>>
>> The man page lists casting in the 2nd row of the table:
>>
>>         Operator Associativity   Notes
>>         () [] -> . ++ --                    left to right [1]
>>         ! ~ ++ -- + - (type) * & sizeof     right to left [2]
>>         * / %                               left to right
>>
>> However, in "C A Reference Manual" (5th ed.), table 7-3 on pg. 205 
>> shows that all of the operators in row 2 above have a precedence of 15 
>> except for casts which have a precedence of 14. Consequently, the man 
>> page should display casts as the (new) 3rd row in the table above.
>>
>> Thanks for your effort in maintaining this documentation.
>>
> 
> Reviewing the standard (C18), "C A Reference Manual" seems to be right. 
>   Unary operators are mentioned in C18::6.5.3, and casts are in 
> C18::6.5.4 (they are mentioned in order of precedence).
> 
> I also noticed that we're missing compound literals in the first row. 
> And we're also missing _Alignof() in the second row.
> However, since all of those use parentheses (and braces),
> there's no doubt in their precedence, so I'll ignore them for now.
> 
> And for some reason they are in a different order from the one in the 
> standard, which makes it a bit difficult to correlate what is in the 
> manual page and what is in the standard, so I think reordering them 
> inside the rows will also be an improvement.

There seems to be a note in the standard that implies that casts have 
effectively the same precedence as the unary operators (I don't know why 
they would have decided to define it in a separate major subsection; 
maybe it was easier to write the differences in that way).

See the standard: (Note 86 in C18::6.5):

> 86)The syntax specifies the precedence of operators in the evaluation of an expression, which is the same as the order of themajor subclauses of this subclause, highest precedence first. Thus, for example, the expressions allowed as the operandsof the binary+operator (6.5.6) are those expressions defined in 6.5.1 through 6.5.6.  The exceptions are cast expressions(6.5.4) as operands of unary operators (6.5.3), and an operand contained between any of the following pairs of operators:grouping parentheses()(6.5.1), subscripting brackets[](6.5.2.1), function-call parentheses()(6.5.2.2), and the conditionaloperator?:(6.5.15).Within each major subclause, the operators have the same precedence.  Left- or right-associativity is indicated in eachsubclause by the syntax for the expressions discussed therein


That makes sense, since the cast operator really is unary (it applies to 
a "unary expression") and since it and all of the so-called unary 
operators and right-to-left associativity, I can't imagine of an 
expression where that different precedence would matter.

I mean:
!(int)x
(int)!x

The precedence doesn't matter there, as they apply one after the other, 
right to left.

So, I'll keep casts in row 2.

Cheers,

Alex

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

  reply	other threads:[~2021-08-28  0:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-27 18:11 Error in 'man operator' David Sletten
2021-08-27 23:39 ` Alejandro Colomar (man-pages)
2021-08-28  0:01   ` Alejandro Colomar (man-pages) [this message]
2021-08-28  0:08     ` David Sletten
2021-08-28 10:56       ` Alejandro Colomar (man-pages)
2021-08-28  0:17     ` Alejandro Colomar (man-pages)
2021-08-28  0:20       ` David Sletten
2021-08-28  5:43       ` Jakub Wilk
2021-08-28 10:50         ` Alejandro Colomar (man-pages)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40cbdcb1-1356-b749-ed53-61ed9dc2dd2e@gmail.com \
    --to=alx.manpages@gmail.com \
    --cc=david.paul.sletten@gmail.com \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.