Re: link order

On Sat, 29 Jun 2019 at 22:42, Felix Salfelder <[email protected]> wrote:
>
> On Sat, Jun 29, 2019 at 10:10:24PM +1200, Christian Gagneraud wrote:
> > But yes, every now and then this can happen. because _map is not initialised.
>
> You are reiterating that, at the start of the program, _map is not zero
> in static instances. is there any evidence for this? any ref to a
> standard?

The evidence is the very existence of this thread. It obviously does
happen, b/c you're observing it right now.
I have explained the reason why.

What is static is just an object, this object is created (read: memory
allocation+initialisation) using the default constructor.
The default constructor doesn't inilialise _map.
There is no guarentee as to what the value of _map is.

Sorry, i don't have a link to share, this is  basic C++ rules.

Concerning the "on the stack" aspect, resizing the stack is as easy as
incrementing a pointer, the pointed to memory doesn't have to be
initialised AFAIK.

>
> it was like that in ANSI-C, and, to my knowledge, nothing ever changed.
>
> > I once had to maintain a code base with such a 'static plugin system'.
> > It worked well for ages, and one day I had to manage 2 version of an
> > arm-linux-gcc toolchain (from different vendors).
> >
> > One of the toolchain would provoke early crashes.
> > The fix was to reverse the link order of the executable, this was a
> > makefile based project, and i had a special rule that depended of the
> > version of gcc, to handle the link order.
>
> reversing the link order is a trivial change, that we could easily do
> (even conditionally, depending on the tool chain).
>
> you claim that dispatchers cannot work in principle, which i am hesitant
> to believe. i think we need to disentangle more carefully into
>
> - what is static memory initialised to (and why do you think it is not
>   zero)?
> - how can we control the link order (i.e. the order of static instances)
>   better?

Please don't attempt to control the link order, my (real) example was
an example of what you shouldn't do.

> - how can we deal with error cases (i.e. if the linker or user got it
>   wrong)?

If you don't rely on undefined behaviour, this question has no reason to exist.


> - what compilers actually do misbehave and in which way, regardless of
>   what the standard says.

Compilers don't misbehave, you rely on undefined behaviour, and you're
trying to build a solution based on the different behaviour you've
observed so far.

>> clearly, if we managed to control the link order, we wouldn't have to
> rely on the zero initialisation, which is (only) used in the
> troubleshooting code.  we simply can't get rid of it without anything
> better in place.

The problem is actually the other way around. Just default initialise
_data to nullptr, and this specific problem is gone!

>
> please let us know if you have a workable solution for this, or even an
> alternative approach that achieves the goal.
>
> thanks
> felix
>
> PS: please Patrick, give us more details on the error you are actually
> seeing -- this is getting a bit theoretical (:

_______________________________________________
Gnucap-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnucap-devel