* Error in 'man operator'
@ 2021-08-27 18:11 David Sletten
2021-08-27 23:39 ` Alejandro Colomar (man-pages)
0 siblings, 1 reply; 9+ messages in thread
From: David Sletten @ 2021-08-27 18:11 UTC (permalink / raw)
To: mtk.manpages, alx.manpages; +Cc: linux-man
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.
--
Have all good days!
David Sletten
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Error in 'man operator'
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)
0 siblings, 1 reply; 9+ messages in thread
From: Alejandro Colomar (man-pages) @ 2021-08-27 23:39 UTC (permalink / raw)
To: David Sletten; +Cc: linux-man, mtk.manpages
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.
Thanks,
Alex
--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Error in 'man operator'
2021-08-27 23:39 ` Alejandro Colomar (man-pages)
@ 2021-08-28 0:01 ` Alejandro Colomar (man-pages)
2021-08-28 0:08 ` David Sletten
2021-08-28 0:17 ` Alejandro Colomar (man-pages)
0 siblings, 2 replies; 9+ messages in thread
From: Alejandro Colomar (man-pages) @ 2021-08-28 0:01 UTC (permalink / raw)
To: David Sletten; +Cc: linux-man, mtk.manpages
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/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Error in 'man operator'
2021-08-28 0:01 ` Alejandro Colomar (man-pages)
@ 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)
1 sibling, 1 reply; 9+ messages in thread
From: David Sletten @ 2021-08-28 0:08 UTC (permalink / raw)
To: Alejandro Colomar (man-pages); +Cc: linux-man, mtk.manpages
All right. I knew I wasn't on completely solid ground since I don't have
the standard. Thanks for checking.
On 8/27/21 8:01 PM, Alejandro Colomar (man-pages) wrote:
> 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
>
--
Have all good days!
David Sletten
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Error in 'man operator'
2021-08-28 0:01 ` Alejandro Colomar (man-pages)
2021-08-28 0:08 ` David Sletten
@ 2021-08-28 0:17 ` Alejandro Colomar (man-pages)
2021-08-28 0:20 ` David Sletten
2021-08-28 5:43 ` Jakub Wilk
1 sibling, 2 replies; 9+ messages in thread
From: Alejandro Colomar (man-pages) @ 2021-08-28 0:17 UTC (permalink / raw)
To: David Sletten; +Cc: linux-man, mtk.manpages
Hi David,
On 8/28/21 2:01 AM, Alejandro Colomar (man-pages) wrote:
> 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.
Hmm, I just came up with some very stupid piece of code that can show
the different precedence between "unary operators" and "cast operators":
sizeof(int)x;
Which I hope no-one on earth would ever want to be valid C.
If casts had the same precedence as unary operators, this would be:
First, cast x to int, then apply sizeof to the resulting int (since
sizeof can be used without parentheses on non-types).
But since sizeof has greater precedence than the cast, it would be:
First, calculate sizeof(int), then... x? Invalid expression!
And luckily, the second thing happens, and the compiler yells:
sizeof.c: In function ‘foo’:
sizeof.c:3:20: error: expected ‘;’ before ‘x’
3 | return sizeof(int)x;
| ^
| ;
So I think this deserves a new row.
Thanks!
Alex
>
> Cheers,
>
> Alex
>
--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Error in 'man operator'
2021-08-28 0:17 ` Alejandro Colomar (man-pages)
@ 2021-08-28 0:20 ` David Sletten
2021-08-28 5:43 ` Jakub Wilk
1 sibling, 0 replies; 9+ messages in thread
From: David Sletten @ 2021-08-28 0:20 UTC (permalink / raw)
To: Alejandro Colomar (man-pages); +Cc: linux-man, mtk.manpages
Ha. Nice work.
On 8/27/21 8:17 PM, Alejandro Colomar (man-pages) wrote:
> Hi David,
>
> On 8/28/21 2:01 AM, Alejandro Colomar (man-pages) wrote:
>> 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.
>
> Hmm, I just came up with some very stupid piece of code that can show
> the different precedence between "unary operators" and "cast operators":
>
> sizeof(int)x;
>
> Which I hope no-one on earth would ever want to be valid C.
>
> If casts had the same precedence as unary operators, this would be:
> First, cast x to int, then apply sizeof to the resulting int (since
> sizeof can be used without parentheses on non-types).
>
> But since sizeof has greater precedence than the cast, it would be:
> First, calculate sizeof(int), then... x? Invalid expression!
>
> And luckily, the second thing happens, and the compiler yells:
>
> sizeof.c: In function ‘foo’:
> sizeof.c:3:20: error: expected ‘;’ before ‘x’
> 3 | return sizeof(int)x;
> | ^
> | ;
>
>
> So I think this deserves a new row.
>
> Thanks!
>
> Alex
>
>>
>> Cheers,
>>
>> Alex
>>
>
>
--
Have all good days!
David Sletten
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Error in 'man operator'
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)
1 sibling, 1 reply; 9+ messages in thread
From: Jakub Wilk @ 2021-08-28 5:43 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: David Sletten, linux-man, Michael Kerrisk
* Alejandro Colomar <alx.manpages@gmail.com>, 2021-08-28, 02:17:
>Hmm, I just came up with some very stupid piece of code that can show
>the different precedence between "unary operators" and "cast
>operators":
>
>sizeof(int)x;
Perhaps a more vivid example would be:
sizeof (int) + 1
which is parsed as
(sizeof (int)) + 1
rather than:
sizeof ((int) +1)
--
Jakub Wilk
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Error in 'man operator'
2021-08-28 5:43 ` Jakub Wilk
@ 2021-08-28 10:50 ` Alejandro Colomar (man-pages)
0 siblings, 0 replies; 9+ messages in thread
From: Alejandro Colomar (man-pages) @ 2021-08-28 10:50 UTC (permalink / raw)
To: Jakub Wilk; +Cc: David Sletten, linux-man, Michael Kerrisk
Hi Jakub,
On 8/28/21 7:43 AM, Jakub Wilk wrote:
> * Alejandro Colomar <alx.manpages@gmail.com>, 2021-08-28, 02:17:
>> Hmm, I just came up with some very stupid piece of code that can show
>> the different precedence between "unary operators" and "cast operators":
>>
>> sizeof(int)x;
>
> Perhaps a more vivid example would be:
>
> sizeof (int) + 1
>
> which is parsed as
> (sizeof (int)) + 1
>
> rather than:
>
> sizeof ((int) +1)
Yes, definitely more convincing!
Thanks,
Alex
--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Error in 'man operator'
2021-08-28 0:08 ` David Sletten
@ 2021-08-28 10:56 ` Alejandro Colomar (man-pages)
0 siblings, 0 replies; 9+ messages in thread
From: Alejandro Colomar (man-pages) @ 2021-08-28 10:56 UTC (permalink / raw)
To: David Sletten; +Cc: linux-man, mtk.manpages, Jakub Wilk
Hi David,
On 8/28/21 2:08 AM, David Sletten wrote:
> All right. I knew I wasn't on completely solid ground since I don't have
> the standard. Thanks for checking.
You can find all of the C and C++ standards easily here:
<https://stackoverflow.com/questions/81656/where-do-i-find-the-current-c-or-c-standard-documents>
And a direct link to the C18 standard (actually a draft, but for most
things you'll need, it's enough):
<https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf>
Cheers,
Alex
--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-08-28 10:56 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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)
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)
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.