segmentation fault on GiNaC-1.2.0 using MinGW on Win XP

[Richard B. Kreckel]

Hi!

On Thu, 8 Apr 2004, Christian Bauer wrote:
> On Wed, Apr 07, 2004 at 01:28:29PM +0200, Johannes Brunen wrote:
> > However, the initilaization of the const _num0 reference happens at some
> > time later. Therefore it is undefined at the point of usage in the
> > ex::construct_from_int(int i) call from function_options::initialize().
>
> Ah, of course. This explains it. The ex() default ctor uses _num0_bp
> directly, so static ex objects are always initialized correctly as long
> as you're only using the default ctor.

The joy of the initializion order!

It all looks so correct until you realize that the const references
themselves aren't initialized yet while the objects they're supposed to
reference are already initialized.  This is pervert.

I still do hope that the C++ Committee does see the light some lucky day
and realize that they can do a great favor to the language and its
community by simply demanding that if dependencies form a DAG, then that
DAG shall be established by the linker.  AIX seems to do it.  Patches for
GNU ld to that effect have been suggested.  It's so obviously the correct
thing to do!  Rather, they say nothing.  The GNU folks then say the order
is determined by the link line.  Hahaha!  Very funny.  I have 855 modules
in CLN.  Under no circumstances am I going to manually arrange that link
line.  This problem is definitely the most irritating issue of C++.  It is
also the issue most insistently dodged by the Standard Committee.

> Maybe the ex::construct_from_*() functions should also use the _num*_bp
> pointers instead of the references?

Definitely.  Basically, this was the situation in the GiNaC 1.1 tree.

I have applied a patch on GiNaC-1.2 and HEAD to that effect.  FYI: I've
also undone the previous patch in function.pl, since it isn't needed
anymore and the original version (albeit equivalent) seems to make the
intent clearer.

Cheers
    -richy.
-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>