Issue 180613.1: 0xffff in tables rendered with spaces

Author: Andrew Cagney
Champion: Ron Brender
Date submitted: 2018-06-13
Date revised: 2021-03-14
Date closed: 2021-08-09
Type: Editorial
Status: Accepted
DWARF Version: 6
Section 7.5.3, pg 206

The PDF document, when viewed with evince and/or firefoxes 
builtin viewer, seems to have embedded spaces in some hex values.
For instance when trying to cut/pasting a value from a table tables,
some values copy ok while others contain spaces?

Table 7.3: Tag encodings, page 206:
     DW_TAG_lo_user                 0x4080
     DW_TAG_hi_user                 0x f f f f
Table 7.5: Attribute encodings, page 212:
     DW_AT_lo_user                  0x2000
     DW_AT_hi_user                  0x3 f f f

I suspect it is coming from:

\newcommand{\xffff}     {0x\hspace{1pt}f\hspace{2pt}f\hspace{2pt}f\hspace{2pt}f}


The scheme noted above for the hex value 0xffff (and similarly for 0xff, 0x3f and
0x3fff) came into use as a way to suppress the ligatures that were generated by
LaTeX for these values. The editor resorted to using horizontal space to disable
the ligatures because \/ and {} didn't work, nor did the DisableLigatures command
in the microtext package. Don't ask why...

As a result of this issue a different workaround has been devised that should avoid
the problem and still give satisfactory esthetics. For example, for 0xffff the new
command definition is

\newcommand{\xffff} {0x\texttt{ffff}}

This (and similarly for the other values) will be used in all future releases of the

2021-03-14:  Updated.
2021-08-09:  Accepted.