> On Mar 18, 2016, at 13:11 , Félix Cloutier <[email protected]> wrote: > > GCC may have some hints: > >> -fdelete-null-pointer-checks >> Assume that programs cannot safely dereference null pointers, and that no >> code or data element resides at address zero. This option enables simple >> constant folding optimizations at all optimization levels. In addition, >> other optimization passes in GCC use this flag to control global dataflow >> analyses that eliminate useless checks for null pointers; these assume that >> a memory access to address zero always results in a trap, so that if a >> pointer is checked after it has already been dereferenced, it cannot be null. >> Note however that in some environments this assumption is not true. Use >> -fno-delete-null-pointer-checks to disable this optimization for programs >> that depend on that behavior. >> >> This option is enabled by default on most targets. On Nios II ELF, it >> defaults to off. On AVR and CR16, this option is completely disabled. >> >> Passes that use the dataflow information are enabled independently at >> different optimization levels. > > I recall that my first time being bit by null being valid was on AVR32 > (though with GCC 3.something), and this seems to confirm it.
In an offline conversation Doug pointed out that Clang and LLVM also assume that NULL is 0, so there'd be a lot more work than just improving Swift to make Swift work on such a platform. I think when the time comes the implementer for such a platform can designate a non-zero bit pattern to use as an invalid pointer instead. Jordan _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
