[PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc
Tue Jun 22 08:59:19 GMT 2021
On Tue, 22 Jun 2021, Richard Sandiford wrote:
> Kees Cook <email@example.com> writes:
> > On Mon, Jun 21, 2021 at 03:39:45PM +0000, Qing Zhao wrote:
> >> So, if “pattern value” is “0xFFFFFFFFFFFFFFFF”, then it’s a valid canonical virtual memory address. However, for most OS, “0xFFFFFFFFFFFFFFFF” should be not in user space.
> >> My question is, is “0xFFFFFFFFFFFFFFFFF” good for pointer? Or “0xAAAAAAAAAAAAAAAA” better?
> > I think 0xFF repeating is fine for this version. Everything else is a
> > "nice to have" for the pattern-init, IMO. :)
> Sorry to be awkward, but 0xFF seems worse than 0xAA to me.
> For integer types, all values are valid representations, and we're
> relying on the pattern being “obviously” wrong in context. 0xAAAA…
> is unlikely to be a correct integer but 0xFFFF… would instead be a
> “nice” -1. It would be difficult to tell in a debugger that a -1
> came from pattern init rather than a deliberate choice.
> I agree that, all other things being equal, it would be nice to use NaNs
> for floats. But relying on wrong numerical values for floats doesn't
> seem worse than doing that for integers.
> 0xAA… for float is (if I've got this right) -3.0316488252093987e-13,
> which admittedly doesn't stand out as wrong. But I'm not sure we
> should sacrifice integer debugging for float debugging here.
We can always expose the actual value as --param. Now, I think
we'd need a two-byte pattern to reliably produce NaNs anyway,
so with floats taken out of the picture the focus should be on
pointers where IMHO val & 1 and val & 15 would be nice to have.
So sth like 0xf7 would work for those. With a two-byte pattern
we could use 0xffef or 0x7fef.
Anyway, it's probably down to priorities of the project involved
(debugging FP stuff or integer stuff).
More information about the Gcc-patches