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. Félix > Le 18 mars 2016 à 12:40:35, Jordan Rose <[email protected]> a écrit : > > >> On Mar 17, 2016, at 20:21 , Félix Cloutier <[email protected] >> <mailto:[email protected]>> wrote: >> >>> Fortunately, when a type has a single invalid value for which no operations >>> are valid, Swift already has a solution: Optionals. >> >> To me, this makes it sound like dereferencing an unsafe pointer is unsafe >> only if the pointer is nil. (Nil does have the merit that it's generally one >> of the only addresses known to be invalid, though.) > > Okay, you're right, it was a bad description of the problem. UnsafePointer > remains "unsafe" for a lot of other reasons. :-) > > >> >> One thing that I would worry about, though, is the case where dereferencing >> address 0 is legal. My understanding is that Swift is aimed to be a systems >> language, and this case is relatively frequent on embedded devices. > > Good point. Technically in the C standard, there must be some pointer value > that cannot be the address of anything valid, whether or not it has a bit > pattern of 0; the intent was that Swift's 'nil' would follow whatever C did > for that platform rather than being 0. But I imagine a lot of embedded C code > doesn't actually follow this rule (i.e. "NULL" will still give you the 0 > address). > > I'm not very familiar with this space at all, but I'll look into it some > more. If you know what existing compilers do here that'd be great to read. > > Jordan >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
