According to <http://dlang.org/phobos/core_memory.html>:

"Registers, the stack, and any other memory locations added through the GC.addRange function are always scanned conservatively."

1. Can that be safely assumed to be a canonical list of all possible sources of false pointers?

2. What about memory allocated through language constructs such as "new", append ("~"/"~="), closures, or any others I may be forgetting? Is this memory always/never/sometimes set to NO_SCAN? (I assume not "always", as that would be silly.) If "sometimes", what are the conditions?

A couple specific examples:

3. Are there any situations where a (for example) int[] or long[] that is stored on the GC heap could lead to false pointers?

4. Same question as #3, but if it's an array of structs, and the struct type contains no members that are statically-typed as pointers.

On Thursday, 20 April 2017 at 02:27:37 UTC, Nick Sabalausky (Abscissa) wrote:
> According to <http://dlang.org/phobos/core_memory.html>:
>
> "Registers, the stack, and any other memory locations added through the GC.addRange function are always scanned conservatively."
>
> 1. Can that be safely assumed to be a canonical list of all possible sources of false pointers?
>
> 2. What about memory allocated through language constructs such as "new", append ("~"/"~="), closures, or any others I may be forgetting? Is this memory always/never/sometimes set to NO_SCAN? (I assume not "always", as that would be silly.) If "sometimes", what are the conditions?
>
> A couple specific examples:
>
> 3. Are there any situations where a (for example) int[] or long[] that is stored on the GC heap could lead to false pointers?
>
> 4. Same question as #3, but if it's an array of structs, and the struct type contains no members that are statically-typed as pointers.

1. No, that's not the full list. Closures are indeed an important source of GC-allocated objects with pointers and often false pointers, for example.

2. With "new" compiler decides by the type whether the data may contain pointers, so arrays of numbers or arrays of structs with no pointers inside will be allocated as NO_SCAN.

3-4. As long as the compiler is sure about absence of pointers in allocated type, you're safe, I don't see a way for that data to become a source of false pointers (unless you fool the compiler with casts).

https://issues.dlang.org/show_bug.cgi?id=15723

On 04/20/2017 09:00 AM, Kagamin wrote:
> https://issues.dlang.org/show_bug.cgi?id=15723

Hmm, so apparently embedded data (even if it's from a C lib) can also be a source of false pointers. Thanks, good to know.

On Thursday, 20 April 2017 at 20:26:06 UTC, Nick Sabalausky (Abscissa) wrote:
> (even if it's from a C lib)

Same for D: .rdata is fine, but afaik you have only strings there, the rest - .data, .bss, .tls will suffer the same issue.

On 04/22/2017 08:56 AM, Kagamin wrote:
> .rdata is fine, but afaik you have only strings there, the rest - .data,
> .bss, .tls will suffer the same issue.

I don't know anything about the various object file sections. :/

They are for static data an thread-local storage.