After doing a dichotomy search I found that:
2017-02-13 grischka mems & leaks commit was the last commit WITHOUT this
warning
Next commit also made by grischka, introduced this warning:
2017-02-13 grischka updates & cleanups (tcc-doc/Changelog/TODO ...)
I see no obvious changes from Grischka
Hello,
On Tue, 2 May 2017, grischka wrote:
Michael Matz wrote:
I chose to adjust field layout instead of field type; the latter can cause
invalid mem accesses with packed structs/fields:
Hi Michael,
May I suggest something:
It appears to me that it's the point of packed (pcc) bitfields
Michael Matz wrote:
I chose to adjust field layout instead of field type; the latter can cause
invalid mem accesses with packed structs/fields:
Hi Michael,
May I suggest something:
It appears to me that it's the point of packed (pcc) bitfields that
all bits are fully tightly packed with no
On 2017-05-02 14:24:22 +0200, Christian Jullien wrote:
> When I see this warning, it makes me think that application will produce
> unpredictable results based on value on stack.
> That's why I consider this as an annoying warning.
Certainly, but providing fake initialization may have the
When I see this warning, it makes me think that application will produce
unpredictable results based on value on stack.
That's why I consider this as an annoying warning.
It's hard to figure out that this code is platform dependent and will not
happen with mine (ARM).
Suppose that tomorrow,
Christian Jullien wrote:
So do you agree if I push this patch which works in all cases (even with
dead code :o)
+dl1.l.upper = 0;
+dl1.l.lower = 0;
No, please, we do not fix warnings in functions for platforms
where the function cannot be used as pointed out just by that
warning.
