3 ms·

>The expressible values for a pointer-to-T are, in theory, the following: A null pointer (pointer-to-0) A pointer to a valid instance of T A pointer to a previo

by eurleif 14y ago

>The expressible values for a pointer-to-T are, in theory, the following: A null pointer (pointer-to-0) A pointer to a valid instance of T A pointer to a previously valid, but now invalid because it was freed, instance of T A pointer to an arbitrary location in memory In C. Go has garbage collection, and no pointer arithmetic, so that's not the case in Go.

kevingadd 14y ago
If you think a garbage collector and the lack of pointer arithmetic protect you from heap corruption bugs and developers deciding they're smart enough to manually manage memory for some extra speed, I've got some bad news for you. ;)
- eurleif 14y ago
  How do you expect them to do that when the language doesn't allow it? Can you show an example of Go code which creates an invalid pointer?
  - Symmetry 14y ago
    There's a library called "unsafe" explicitely for this. I think it's reasonable to expect people to generally not use it, though. http://golang.org/pkg/unsafe/ http://golang.org/pkg/unsafe/
    - eurleif 14y ago
      As far as I know, it can only create a pointer of type A that actually points to a value of type B, not reference unallocated/deallocated memory. Nullable<T> could do that too if the language allowed it.
      - lagom 14y ago
        It's definitely possible to access unallocated memory e.g., // p points to address 1000 p := (*int)(unsafe.Pointer(uintptr(1000))) Of course, this is why use of the unsafe package is heavily discouraged.
  - kevingadd 14y ago
    Any language that lets you call out into third-party libraries not written in that language can end up with heap corruption. The important distinction is that a 'Nullable' value type need not involve a pointer, which means it can entirely live on the stack, which dramatically limits the damage that can be done by corruption: Worst case, corruption sets the 'hasValue' flag to true, and you read an uninitialized struct off the stack. Much less catastrophic than a double-free or pointer into random memory (Though, of course, a determined attacker could probably make do with either).

by eurleif 14y ago

kevingadd 14y ago

If you think a garbage collector and the lack of pointer arithmetic protect you from heap corruption bugs and developers deciding they're smart enough to manually manage memory for some extra speed, I've got some bad news for you. ;)

eurleif 14y ago
How do you expect them to do that when the language doesn't allow it? Can you show an example of Go code which creates an invalid pointer?
- Symmetry 14y ago
  There's a library called "unsafe" explicitely for this. I think it's reasonable to expect people to generally not use it, though. http://golang.org/pkg/unsafe/ http://golang.org/pkg/unsafe/
  - eurleif 14y ago
    As far as I know, it can only create a pointer of type A that actually points to a value of type B, not reference unallocated/deallocated memory. Nullable<T> could do that too if the language allowed it.
    - lagom 14y ago
      It's definitely possible to access unallocated memory e.g., // p points to address 1000 p := (*int)(unsafe.Pointer(uintptr(1000))) Of course, this is why use of the unsafe package is heavily discouraged.
- kevingadd 14y ago
  Any language that lets you call out into third-party libraries not written in that language can end up with heap corruption. The important distinction is that a 'Nullable' value type need not involve a pointer, which means it can entirely live on the stack, which dramatically limits the damage that can be done by corruption: Worst case, corruption sets the 'hasValue' flag to true, and you read an uninitialized struct off the stack. Much less catastrophic than a double-free or pointer into random memory (Though, of course, a determined attacker could probably make do with either).