<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">GCC may have some hints:<div class=""><br class=""></div><div class=""><blockquote type="cite" class="">-fdelete-null-pointer-checks<br class="">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.<br class="">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.<br class=""><br class="">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.<br class=""><br class="">Passes that use the dataflow information are enabled independently at different optimization levels. <br class=""></blockquote><div class=""><br class=""></div>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.<br class=""><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 18 mars 2016 à 12:40:35, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 17, 2016, at 20:21 , Félix Cloutier <<a href="mailto:felixcca@yahoo.ca" class="">felixcca@yahoo.ca</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class="">Fortunately, when a type has a single invalid value for which no operations are valid, Swift already has a solution: Optionals.<br class=""></blockquote><div class=""><br class=""></div><div class="">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.)</div></div></div></blockquote><div class=""><br class=""></div><div class="">Okay, you're right, it was a bad description of the problem. UnsafePointer remains "unsafe" for a lot of other reasons. :-)</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class="webkit-block-placeholder"></div><div class="">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.</div></div></div></blockquote></div><br class=""><div class="">Good point. Technically in the C standard, there must be <i class="">some</i> 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).</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div></div></div></blockquote></div><br class=""></div></body></html>