On 12/7/21 00:31, наб wrote:
On Mon, Dec 06, 2021 at 11:56:19PM +0100, Alejandro Colomar (man-pages) wrote:
I (more or less) understand the deduction of why that happens on certain
systems, what I was wondering is if there's an intention behind that, or if
it's just an accident. Why not just use plain 'long' always as POSIX says
it should be. I don't see the feature part of this bug.
'long' is at least 32 bits, which
is enough for 1G. Was there ever a good reason for glibc to use 64 bits? It
seems like a wrong decision that is maintained for consistency. If that's it
I'm in favor of mentioning it in a Bugs section (as Jakub proposed), instead
of a Notes section. Maybe someone from glibc may give a rationale for this
deviation from POSIX.
AFAICT, as you say, this isn't much more than a side-effect
of using the amd64 ABI and not being too careful with how it interacts
with the POSIX requirement (it's entirely feasible to re-wrap
a user-space timespec, or even use the bitfield trick glibc
already does to not have to do it), but then I'm far from an expert;
indeed, maybe someone with more glibc involvement will know.
Updating to Bugs for now, maybe we can downgrade later.
Sure, I'll delay applying this patch to allow for comments.
Maybe preceding the paragraph with "In/On (I never
knew if there goes in or on) glibc," would do.
Out of those two: on (in would point to glibc internals),
but I'd actually go for "Under", here, since glibc is an over-arching
(literally) universe-defining context, rather than an add-on,
or something build your program on top of.
Interesting :)
For my own curiosity: which preposition would you use in Spanish here?
I would say "en" (which normally translates to "in" in English).
Under some circumstances I might use "con" ("with" in English), but it
would be rarer.
On 12/6/21 23:03, наб wrote:
+.br
We don't use '.br'. In this case I think just continuing in the same
paragraph would be fine (i.e., no break at all).
+In reality, the field ends up being defined as:
Here I'd add a blank line with '.PP'.
+.EX
+.in +4
Please, revert the order of .in and .EX.
It's meaningless, but I prefer consistency. See man-pages(7), which shows
this order, and also the following:
$ grep -rn '^\.EX$' -A1 man? | grep '\.in' | wc -l
2
$ grep -rn '^\.EX$' -B1 man? | grep '\.in' | wc -l
1048
One of those 2 cases was this patch.
Sure, sure, and sure
+#if !(__x86_64__ && __ILP32__ /* == x32 */)
Now I notice:
Shouldn't this use defined()?
#if !(defined(__x86_64__) && defined(__ILP32__) /* == x32 */)
Eeeeh, not really? That's functionally identical but, like,
very verbose for no good reason.
Are those defined to actual values? Or are they defined just empty?
I thought they were empty (but have never used those macros, so don't
know at all), in which case it would matter:
user@sqli:~/src/test$ cat defined.c
#define C
#define D
#if A && B
#warning AB
#else
#warning notAB
#endif
#if C && D
#warning CD
#else
#warning notCD
#endif
user@sqli:~/src/test$ cc -Wall -Wextra defined.c
defined.c:7:2: warning: #warning notAB [-Wcpp]
7 | #warning notAB
| ^~~~~~~
defined.c:10:7: error: operator '&&' has no left operand
10 | #if C && D
| ^~
defined.c:13:2: warning: #warning notCD [-Wcpp]
13 | #warning notCD
| ^~~~~~~
Cheers,
Alex
--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/
