CTFE bug causes null check to pass on null pointers (Issue 7602)

[Don]

On 19.03.2012 22:14, H. S. Teoh wrote:
> On Mon, Mar 19, 2012 at 09:46:04PM +0100, Don wrote:
>> On 19.03.2012 18:25, H. S. Teoh wrote:
> [...]
>>> The main idea is to require a minimal number of lowerings from the
>>> compiler (effectively nothing more than syntactic sugar such as V[K]
>>> and AA literal syntax), and everything else will be done via existing
>>> operator overloading and templating mechanisms. Ideally, CTFE will
>>> "just work" with this implementation instead of requiring
>>> druntime-specific hacks in the compiler (but I'm not sure whether
>>> this will work, since it has to do memory allocations -- does CTFE
>>> support that?).
>>
>> Yes, CTFE supports 'new'. The big issue for the runtime is supporting
>> AA literals. CTFE needs to be able to take the output of the runtime
>> functions, and pass it as an AA literal to the rest of the compiler.
>
> I've thought about supporting literals. Currently what I have in mind is
> to build the AA in CTFE, then use mixins to explicitly create Slot
> structs and link them all up into an Impl struct. The address of the
> Impl struct (that contains the array of Slot*) is then readable at
> compile-time, so it can be assigned to const AA variables, .dup'd into
> mutable AA variables, etc.
>
> This only works for literals that only have compile-time known contents,
> of course. Things like:
>
> 	int x;
> 	int[string] aa = [ "abc": x ];
>
> won't work with this scheme.  To support literals that reference
> variables, some kind of runtime mechanism would be needed, perhaps
> something similar to the current implementation where the compiler
> passes an array of keys and an array of values to an AA factory
> function.


It may help you to know that inside the compiler, AA literals are 
implemented as two arrays, one of keys, one of values.
Those non-constant literals never participate in CTFE, so I think it 
would be best to treat them completely separately.




>
>
> [...]
>>>> I do not understand why it still part of the compiler after we
>>>> agreed to roll back to the D1 version.
>>>
>>> I'm late to the game; how was the D1 version implemented?
>>
>> It was just extern(C) library functions.
>>
>> The D2 version is exactly the same thing (all of the D1 functions
>> still exist in D2), except that it has an AssociativeArray!(Key,
>> Value) wrapper around the extern(C) functions.
>> Which sounds like a trivial intermediate step to a full library
>> implementation, but it isn't.
>
> Yeah, this "wrapper" is the source of a good number of issues currently
> on the bugtracker. It's also extremely ugly (the Range interface, for
> example, is essentially a copy-n-paste of the structs in aaA.d).
>
>
>> - it's a template, so it needs to be instantiated. What happens if
>> it hasn't been instantiated yet?
>> - what happens when AssociativeArray isn't a struct template?
>> - what happens if there's an error while instantiating it?
>> - what happens when all the functions are inlined away, and you're
>> left with just void* pointers?
>> - what happens when you something of type V[K] interacting with
>> something of type AssociativeArray!(K, V)? This happens in things
>> like template constraints, is() expressions, etc.
>> - how is CTFE supposed to deal with this ruddy thing, that's fully
>> of nasty casts to void *, and which may yet create AA literals
>> themselves?
>> - how are you supposed to get sensible error messages out of this beast?
>
> The source of most of these problems is the schizophrenic split between
> aaA.d and struct AssociativeArray. It has to be one or the other. There
> can be no intermediate. The compiler needs to treat V[K] as an alias for
> AssociativeArray!(K,V) (or vice versa, but regardless, the two must be
> *identical* in all respects). Having two different things for them (such
> as aaA.d returning void* and AssociativeArray!(K,V) being a struct
> wrapping a void*) only leads to pain and disaster.
>
>
>> The answer to these questions is, hundreds of hours work, and the
>> biggest implementation disaster in D's history. There can be no
>> 'intermediate step'. The syntax sugar should be added last, not first.
>
> Agreed.
>
>
> T
>