[GiNaC-devel] remove_dirac_ONE() and documentation patches

[Vladimir V. Kisil]

	Dear Alexey,

	Many thanks for the detailed advise. In fact I have already
  fixed my application by calling a local substitute of
  GiNaC::remove_dirac_ONE(). Since scalarisation like x*ONE - > x (or
  checking if it is possible at all) is a rather common task, I thought
  a user can benefit from non-throwing version in GiNaC. But I am not
  insisting by any means.

  Shall I write a documentation patch advising a user to make cut&paste
  of the GiNaC code of remove_dirac_ONE() if they will meet this type of
  problem?

  Best wishes,
  Vladimir
-- 
Vladimir V. Kisil                 http://www.maths.leeds.ac.uk/~kisilv/
  Book:     Geometry of Mobius Transformations     http://goo.gl/EaG2Vu
  Software: Geometry of cycles          http://moebinv.sourceforge.net/
>>>>> On Sat, 08 Jun 2019 10:25:36 +0400, Alexey Sheplyakov <asheplyakov at yandex.ru> said:

    ASh> Hi,
 
    ASh> 07.06.2019, 11:45, "Vladimir V. Kisil"
    ASh> <kisilv at maths.leeds.ac.uk>:
    >>>>>>> On Wed, 05 Jun 2019 20:51:10 +0100, "Vladimir V. Kisil"
    ASh> <kisilv at maths.leeds.ac.uk> said:
    >> 
    VVK> Dear All, I finally managed to check Alexey's proposition to
    VVK> wrap the throwing remove_dirac_ONE function. It indeed prevents
    VVK> my Windows app from crashing. Thus I attach the respective
    VVK> light-weighted patches.
    >> 
    >> Apology to everyone: the previously sent version had a debugging
    >> printout. The clean patch is attached now.
 
    ASh> I think the 1st and the 2nd patches are OK and can be applied.
    ASh> The one which adds a non-throwing remove_dirac_ONE() is much
    ASh> better too, however, I don't think adding non-throwing variant
    ASh> of every GiNaC method and function is a good idea.  Instead I
    ASh> suggest to fix the application itself (more details below).
 
    >> Thanks for further comment. Before making the respective change
    >> to the patch I wish to discuss the crash. It is indeed look
    >> strange (and took time to debug), but presence of exception
    >> within the GiNaC library was not an issue, but calling those
    >> methods from another library produced a crash. I do not
    >> understand coding well, by my guess would be that a Qt
    >> application run each library in a separate thread
 
    ASh> Nope, Qt applications don't (and can't) do that
 
    >> and exceptions are fine within one tread.
 
    ASh> Not only it's not right, it's not even wrong.

 
    ASh> ELF (Linux' binaries/shared libraries files format) and PE/COFF
    ASh> (windows' executables/shared libraries format) use completely
    ASh> different paradigms for run-time loading of code.
 
    ASh> ELF shared library contains code to be used by the program, and
    ASh> also the names of functions and data that it expects to find in
    ASh> other shared libraries and/or the program.  When the shared
    ASh> library A is joined to the program, all references to those
    ASh> functions and data in A's code are changed to point to the
    ASh> actual locations in other shared libraries and the program
    ASh> where the functions and data are placed in memory. This is
    ASh> basically a usual link operation.
 
    ASh> On the other hand PE/COFF shared library (DLL) is sort of
    ASh> self-contained: access to external functions and data goes
    ASh> through a lookup table (of that DLL). So the DLL code does not
    ASh> have to be fixed up at runtime to refer to the program’s
    ASh> memory; instead, the code already uses the DLL’s lookup table,
    ASh> and the lookup table is modified at runtime to point to the
    ASh> functions and data.
 
    ASh> The key difference is that each DLL has its own lookup table,
    ASh> and ELF has (sort of) a single lookup table for a whole
    ASh> program.
 
    ASh> Thus if a program uses two DLLs, A and B, malloc/free functions
    ASh> referenced by DLL A can be different from malloc/free functions
    ASh> used by DLL B. If such a program ends up allocating memory in
    ASh> DLL A and releasing it in DLL B, the result is (typically) a
    ASh> crash.
 
    ASh> A similar problem exists with C++ exceptions. The internal data
    ASh> used to find the matching catch block and perform stack
    ASh> unwinding are highly compiler-specific and may use global
    ASh> variables and heap. Thus if all DLLs aren't sharing C++ runtime
    ASh> cross-DLL exception (throwing an exception in DLL A and
    ASh> catching it in DLL B) is a problem (most likely crash).
 
    ASh> To recap: on windows exceptions are fine
 
    ASh> - within the same DLL - across DLLs sharing the same (C/C++)
    ASh> runtime
 
 
    ASh> Hope this helps, Alexey

    ASh> _______________________________________________ GiNaC-devel
    ASh> mailing list GiNaC-devel at ginac.de
    ASh> https://www.cebix.net/mailman/listinfo/ginac-devel