empty slices: defined?

[Gabriel Dos Reis]

DJ Delorie <dj@redhat.com> writes:

| > Yes, but if __gs._M_index is null, we cannot get to 
| > __gs._M_index->_M_index (even if only its address is taken) used by
| 
| We don't have to dereference it to know its address.

I guess  the point was lost.
:-(

|  It's 0x18 on my
| system, which is the value passed.  Essentially, gcc is computing
| (__gs._M_index + OffsetOf(_M_index)), which requires no dereferencing.

Yes, but that does not define what should be computed and passed
around, nor does it define the behaviour.  What, am I after is what
shall be computed for a defined or *specified* behaviour.

Currently we have an undefined behaviour; the real issue is whether it
shall be changed to something definite or just clarifed in more
verbose words that it is undefined behaviour.

| > the expression template _GClos<> later, so my question is what will be
| > computing?  If one passes a null pointer to _GClos<>, what will it do
| > with it?
| 
| It dereferences the nearly-null pointer and crashes.  It's only a
| handful of opcodes after the function call, so it was easy to debug.

Yes, but I'm still after what shall be the behaviour in case it is
decided to be anything except "undefined behaviour". 

Said differently, the current behaviour is that non-trivial uses of
empty gslice is undefined behaviour.  Assume, for a second that, we're
about to change that to a defined behaviour.  A null pointer will have
to be passed somewhere, e.g. to _GClos<>, my question is what will it
do with it?

Essentially, I'm trying to clarify the cost and the complexity of
defining the behaviour for an empty slice (of which we haven't seen
useful uses yet).

-- Gaby