Re: Using C23 digit separators not locale digit grouping characters

Brian Inglis
2023-01-29T21:04:52Z

On 2023-01-29 07:38, Alejandro Colomar wrote:
> On 1/28/23 21:40, Brian Inglis wrote:
>> Seeing the recent tv_nsec patches drop the standard locale digit grouping
>> characters "," from the member range [0-999,999,999] made me regret the loss
>> of the punctuation which provides better and quicker comprehension of long
>> strings of digits.

> Nice! Didn't remember about that separator.  It makes a lot of sense to use it
> in comments and the likes in the pages.  Maybe we should be a bit more cautious
> in source code examples, but definitely for big numbers outside of running code
> should have them.
The major compilers support them from draft C23, and the code is in examples,
not source that has to compile on older compilers, so not much to be concerned
about there, although some more opinions would be helpful.

> наб, would you please update your patches with that? I also have a few
> comments that I'll write in a moment in answers to your patches.
>> It may be time to consider using the locale independent C23 digit
>> separator characters "'" wherever more than a handful of digits occur,
>> possibly convert grouping character uses in existing man pages as they are
>> changed, and specify a future standard policy approach to provide better
>> and quicker comprehension of long strings of digits: perhaps using a new
>> digit separator register and glyph escape sequence \*ds \*[ds] \[ds] \(ds
>> if not in use by base groff?
> The sequence for the unslanted single quote is \(aq.
Granted, but would it not be better to consider using a semantic digit separator
groff man escape sequence, especially in text, whose rendering could be tweaked,
rather than a generic literal apostrophe quote used everywhere?
If nothing else is proposed and accepted, I will use the generic \(aq, and if
future changes are required, they can be targeted by digit context.

> We could add somewhere in man-pages(7) that decimal numbers should use a
> separator every 3 digits, and hex and binary should use it every 4 digits.
As well as the 3 decimal, 4 binary/hex, we could use yyyy'mm['dd]L for POSIX and
similar date digit strings, and 0x10'ffff for Unicode code points,
distinguishing between the Basic and Supplementary Multilingual Plane indices
and codes, just as examples from what I've seen so far.

I've also noticed a lot of apparently random decimal digit strings that are
binary powers or close deltas: those would be more comprehensible if rendered in
text as Ki/Mi/Gi[+/-n], so would that be preferable, using the IEC i suffix to
avoid ambiguity?

>> As well as the recently modified pages:
>>
>> clock_getres.2
>> timer_settime.2
>> timerfd_create.2
>> utimensat.2
>>
>> there appear to be obvious occurrences in only the following pages:
>>
>> futex.2
>> read.2
>> sendfile.2
>> write.2
>> mallopt.3
>> keyrings.7
>> mq_overview.7
>> sched.7
>> time_namespaces.7
>>
>> but there appear to be about 400 pages with more than 6 decimal digit
>> strings (some spurious glibc hex commits and address outputs) where it
>> could perhaps help, such as in POSIX version dates e.g. 2001'12L, and
>> undoubtedly more with long digit strings in other radixes.
> Would you mind preparing a patch for all of those? If you'll do it, better
> wait until we merge наб's patches, to avoid conflicts.
I'll start anyway, need to review over 300 files with over 900 digit strings,
having cut a bunch more pages with output examples.

Any particular subdivision of files patched into git logged patches, by section,
by type of edit, separate logged patches for files with many edits, or...?

FYI although many hits are likely output, the top candidates so far are:

80 man5/proc.5
55 man2/statfs.2
34 man7/feature_test_macros.7
32 man3/dl_iterate_phdr.3
30 man7/units.7
30 man5/rpc.5
23 man3/termios.3
20 man3/malloc_info.3
17 man2/userfaultfd.2
16 man7/keyrings.7
15 man7/time_namespaces.7
14 man7/posixoptions.7
14 man3/mallopt.3
13 man7/utf-8.7
12 man2/reboot.2
12 man2/keyctl.2

--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada

La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry