bugGNU roff - Bugs: bug #63334, \[u....] syntax for ASCII...

 
 

bug #63334: \[u....] syntax for ASCII characters handled inconsistently

Submitter:  Dave <barx>
Submitted:  Tue 08 Nov 2022 09:34:02 AM UTC
   
 
Category:  Core Severity:  2 - Minor
Item Group:  Warning/Suspicious behaviour Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 22 Jan 2024 02:05:19 AM UTC, comment #1: 

original submission:

> Looking at all the pre-alphabet ASCII symbols:
>
> $ printf "\\[u%04x] " $(seq 32 64) | nroff | cat -s


This produces some incorrect syntax: printf's "%04x" conversion produces hex digits with lowercase letters, but groff needs uppercase.  Changing the "x" to "X" corrects this.

> Five of them are handled as expected, 15 are converted to
> unrecognized \ characters, and 13 are not recognized at all. 


The news gets better (or worse) when you fix the above syntax error.  Now 8 characters are handled as expected, 23 are converted to unrecognized \ characters, and 2 are not recognized at all.

Dave <barx>
Group Member
Tue 08 Nov 2022 09:34:02 AM UTC, original submission:  

I see the same behavior in groff 1.22.4 and in the latest git code.  (And for that matter, going all the way back to at least 1.19.2.)

ASCII characters represented in \[u....] form are handled inconsistently.  A simple demonstration of the difference:

$ echo '\[u0021]\[u0022]' | nroff | cat -s
troff: <standard input>:1: warning: can't find special character '\!'
"

\[u0022] is correctly converted to, and output as, a quotation mark.  But \[u0021], rather than being converted to a "!", is for some reason converted to the sequence "\!", which (unsurprisingly) is not a recognized character.

It's not clear to me what internal mechanism might cause this: if "\[u0021]" were parsed as a backslash followed by "[u0021]", the bracketed sequence wouldn't be specially interpreted at all.

Looking at all the pre-alphabet ASCII symbols:

$ printf "\\[u%04x] " $(seq 32 64) | nroff | cat -s

Five of them are handled as expected, 15 are converted to unrecognized \ characters, and 13 are not recognized at all. 

That last case I don't consider a bug, since (current) groff does not specify that any of them should be recognized.  (The 1.22.4 groff_char(7) page sort of gave the impression that some of them would be, but these sequences have been removed from the drastically rewritten 1.23 groff_char(7).)  Arguably, none of this is a bug, since no documentation explicitly states that, for example, "\[u0021]" will be recognized as "!".  But the way it is handled is surprising enough that I wanted to at least bring it to the development team's attention.

Dave <barx>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by barx (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code