Re: gnucap build with CMake on Windows

Christian Gagneraud <[email protected]>
Newsgroups gmane.comp.gnu.gnucap.devel
Message-ID <CABxGUThnnc=_vdZSW3xO7BF1BNRfhqt2is_P0ExB7uqoKnFyxQ@mail.gmail.com>
On Sat, 29 Jun 2019 at 06:44, Felix Salfelder <[email protected]> wrote:
>
> On Fri, Jun 28, 2019 at 03:36:30PM +0200, Patrick Mulder wrote:
> > This can be solved by putting the dll in the same path as the modelgen.exe
> > - so this works now
>
> Hi Patrick
>
> good you figured out this one, i think it requires some cmake skills to
> fix this properly, if possible.
>
> > but running the diode compile i get an empty map in
> > this constructor:
>
> what exactly do you mean? is it a compiler error? a warning is expected,
> but the warning you get with (newer?) g++ can be safely ignored.
>
> could you quote the complete error, please?
>
> > class DISPATCHER_BASE {
> > protected:
> >   std::map<std::string, CKT_BASE*> * _map; // (*)
> > private:
> >   explicit DISPATCHER_BASE(DISPATCHER_BASE*) {unreachable();incomplete();}
> > public:
> >   DISPATCHER_BASE() /*: _map(new std::map<std::string, CKT_BASE*>)*/ {
> >     if (!_map) {
> >       _map = new std::map<std::string, CKT_BASE*>;
> >     }else{unreachable();
> >       puts("build error: link order: constructing dispatcher that already
> > has contents\n");
> >     }
> >
> > How does the map init to work?
>
> currently, all dispatcher instances are static. static objects are
> initialised to zero (i.e. when they are copied to the stack). hence the

No, that is not mandated by the C++ standard, relying on this is
undefined behaviour...

> map pointer (*) is NULL at the beginning. in the normal (intended) case,
> you simply get a new map when the dispatcher is constructed.
>
> the other, unreachable, branch reports a linking problem. It happens on
> some BSD(?), and afaik it should not show up on M$/mingw. Sometimes
> things still seem to work properly, in case you see the error message.
> the code looks a bit weird because it tries to handle this gracefully.

... and that's why you're seeing this problem only under some circumstances.

You should either:
 explicitly initialise the member when declaring it, eg std::map<X, Y>
*m_map = nullptr;
or even better, do not use pointer to map, just use map.

But i guess you tried and it didn't work. The reason it doesn't work
(reliably) is because you're relying on another undefined behaviour,
static initialisation order.
See https://isocpp.org/wiki/faq/ctors#static-init-order

If you build your code with -fsanitize=address,undefined (both in
compiler and linker flags), all these problems will be reported at
runtime. These sanitizers produce 0 false positive.
https://github.com/google/sanitizers/wiki

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

_______________________________________________
Gnucap-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnucap-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.