> On Mar 24, 2016, at 3:50 PM, Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org> wrote: >> Thirdly, as mentioned in the prior discussion it's certainly possible on >> some platforms to remap the memory page at address 0x0 and make it usable to >> userland code. Even if we don't currently support any such platforms, we >> shouldn't lock ourselves into a situation where we need to be able to do >> this. > > I don't think this is mentioned in the proposal itself, but it came up in the > discussion. > > The C standard requires that there be a "null" pointer address which can be > stored into any pointer but which can never actually be valid. It does *not* > require that the null pointer address be 0x0. Most platforms do use 0x0, and > clang doesn't support a non-0x0 null pointer, but this is not required by the > C standard. > > I believe Swift should mimic this behavior. On platforms where 0x0 is a valid > address, Swift should not use 0x0 as the null pointer, but rather use some > other address which isn't valid (perhaps ~0x0). Pointer types should treat > this address as an unused value, which the enum machinery will then exploit > to represent Optional.none.
It is already a known constraint that the representation of an imported type (ignoring bridging conversions) has to match up with the representation of the original C type. If we supported a target with a non-zero null value, we would have to ensure that Optionals of the appropriate pointer type were represented that way. I'd actually be much more concerned about the pervasive assumptions about pointer representation in Clang and LLVM than I would be with Swift. Now, it would probably be very annoying to support a platform where different pointer types had different null values, but the last of those died awhile ago, I believe. All that said, I have negligible interest in putting any effort into supporting the ability to write to address zero in Swift. John. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
