[En-Nut-Discussion] Just a word of warning with WinAVR-20050214.

[Vesa Jääskeläinen]

Vesa Jääskeläinen wrote:

> I was able to trace it back to it's source. GCC is a bit too aggressive 
> about optimizations, I really don't see its rationale but it optimized 
> away NULL pointer checks in certain situations. I will continue 
> discussion on this issue with GCC developers but following switch gives 
> a cure "-fno-delete-null-pointer-checks".

And now I see some rationale on this optimization :)

There is actually a bug in Nut/OS & Nut/Net, but there could be several 
places where we have ioctl handlers code.

If we think about AHDLC's ioctl handler, at variable declarations it 
have already referenced that data pointer. In case it was NULL it reads 
four bytes from memory location 0. And this allowed GCC to optimize NULL 
pointer check out of the picture.

For now I will put -fno-delete-null-pointer-checks as default 
compilation flag with AVR-GCC as there seems to be other parts of the 
Nut/OS & Nut/Net affected by this issue. As needed to disable 
optimizations from AHDLC driver and whole os/ directory until it started 
to work.

I think the whole code base needs to be reviewed against this issue and 
fix possible problems. But as AVR's do not hang with NULL pointers this 
workaround can be used. And in this case in principle it is just four 
bytes from start of SRAM. In most of the cases it is just a time penalty.

I think I now understand situation why this was done and if someone 
needs a better explanation I will provide it on request.

> Problem code in a bit complex situation:
> if ((ppv != NULL) && (*ppv != NULL)) {
> 
> First compare was omitted without this flag.

Thanks,
Vesa Jääskeläinen