https://sourceware.org/bugzilla/show_bug.cgi?id=30865
--- Comment #1 from Nick Clifton <nickc at redhat dot com> ---
(In reply to Fangrui Song from comment #0)
> A side effect possibly from this commit is that 0x literals have different
> behaviors from decimal literals and expressions.
>
> .text : { *(.text) } =0x90 # set the fill pattern to 0x90909090
> .text : { *(.text) } =0x90909090 # set the fill pattern to 0x90909090
> .text : { *(.text) } =144 # set the fill pattern to 0x00000090
> .text : { *(.text) } =0x90+0 # set the fill pattern to 0x00000090
>
> This has been the case for ~20 years, so probably not worth changing,
Agreed.
> but I
> felt obliged to point out this special behavior to warn users about 0x90
> 0x9090 0x909090 that are shorter than 4 bytes.
So a documentation update is needed.
In the course of investigating this I also discovered that the difference
only applies to simple hexadecimal values specified with a 0x prefix. It
does not apply to expressions involving hex numbers, eg 0x1 + 0x2, nor to
hex values specified via a $ prefix, eg $9a, nor to hex values specified
by a letter suffix, eg 9aH, nor to hex values specified with a magnitude,
eg 0x9aK
Anyway please take a look at the uploaded patch which updates the
documentation and adds a new test case to make sure that the documented
behaviour continues.
--
You are receiving this mail because:
You are on the CC list for the bug.
