[swift-evolution] Making pointer nullability explicit (using Optional)

[Félix Cloutier]

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 <jordan_rose at apple.com> a écrit :
> 
> 
>> On Mar 17, 2016, at 20:21 , Félix Cloutier <felixcca at yahoo.ca <mailto:felixcca at yahoo.ca>> 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160318/0ff81dcf/attachment.html>