Because nobody uses that compiler for Apple anymore.  Apparently they never
even did a version for Apples with Intel processor.

When UG creates a new element, and SideVectors are switched on,
then a new SideVector is created for each face of the new element.
Since most faces are shared by two elements, though, the consequence
is that there are two SideVectors for each interior face.  To obtain
a single SideVector per face (as it should be), the UG refinement
code calls the method DisposeDoubledSideVector for these duplicated
SideVectors.  This appears to be easier than only creating one
SideVector for each face to begin with.

However, so far the duplicate SideVectors were not disposed in a
green, non-rule based refinement of an element.  This lead to
memory leaks which could be observed when running the Dune UGGrid
test with --enable-system-heap and valgrind.  This patch adds
the missing calls to DisposeDoubledSideVector, and fixes those
leaks.

Incidentally, this also appears to be the proper fix for the issue
described in Dune FlySpray 170,

https://dune-project.org/flyspray/index.php?do=details&task_id=170

which had previously been hacked around in dune-grid.

In my eyes, this makes code easier to read.

This becomes bool when compiled as C++, and _Bool when compiled as C.

It makes the code and the debugger output easier to read.

This fixes a memory leak, as could be observed in valgrind.

I had simply misspelled it in the DisposeMem method.
It's a surprise the program never crashed with such a severe
bug in it.

No further changes necessary.  The argument really is const and never
modified.

The virtual communication channels allocated for the tree structure were
never freed.  Additionally, the ppif layer may get initialized twice:
when called from Dune, its gets initialized both for the 2d UGGrid and
for the 3d UGGrid.  In that case, the channels initiated for 2d leaked
when being overwritten by newly allocated channels for 3d.

Which is not empty, but contains the text "Leave this file here!".
The file was placed there in 1995, never touched, and is not apparently
referenced from anywhere else.  So out it goes...

This silences a few warnings I get from recent AutoTools

There is no guarantee that it matches the topology of the actual machine
in any way.  Also, it does not appear to be used anywhere in the ug core
at all.  Finally, it contains some small memory leaks.  Admittedly, these
leaks would be easy to fix, but since the code is not used I may as well
rip it out altogether.

[[Imported from SVN: r8530]]

UG implements a small hack to save memory and communication bandwidth:
the NODE data structure contains a VECTOR*, which points to the node data.
If there is no node data then this pointer is not used.  In that case,
instead of allocating sizeof(NODE) bytes for each NODE, the program
allocates sizeof(NODE)-SIZEOF(VECTOR*) bytes instead, and promises to
never touch the missing bytes.

(The same is done for edges).

This 'special' computation is done twice: once in ugm.c, where the memory
for NODEs is allocated, and once in initddd.c, where the DDD communication
layer is told about the NODE type.  The special hack, i.e., the subtraction
of sizeof(VECTOR*) from the object size in case no node data was used,
was massing in initddd.c.  This lead to valgrind giving 'Invalid read' errors
during load balancing (see below).

This patch fixes the size computation in initddd.c, and hence avoid the
valgrind errors.

==1863== Invalid read of size 2
==1863==    at 0x4C2DA60: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:877)
==1863==    by 0x99457C: UG::D3::XferPackSingleMsg(UG::D3::_XFERMSG*) (pack.c:564)
==1863==    by 0x994A36: UG::D3::XferPackMsgs(UG::D3::_XFERMSG*) (pack.c:762)
==1863==    by 0x9842D0: UG::D3::DDD_XferEnd() (cmds.c:611)
==1863==    by 0x9B132C: UG::D3::TransferGridFromLevel(UG::D3::multigrid*, int) (trans.c:835)
==1863==    by 0x9AADC0: UG::D3::lbs(char const*, UG::D3::multigrid*) (lb.c:659)
==1863==    by 0x96D684: UG::D3::LBCommand(int, char**) (commands.c:10658)
==1863==    by 0x4B475F: Dune::UG_NS<3>::LBCommand(int, char const**) (ugwrapper.hh:1019)
==1863==    by 0x4B9CD6: Dune::UGGrid<3>::loadBalance(int, int, int, int, int) (uggrid.cc:534)
==1863==    by 0x42828E: Dune::UGGrid<3>::loadBalance() (uggrid.hh:491)
==1863==    by 0x41D79D: bool Dune::UGGrid<3>::loadBalance<LoadBalance::LBDataHandle<Dune::UGGrid<3>, std::vector<Dune::FieldVector<double, 3>, std::allocator<Dune::FieldVector<double, 3> > >, 3> >(LoadBalance::LBDataHandle<Dune::UGGrid<3>, std::vector<Dune::FieldVector<double, 3>, std::allocator<Dune::FieldVector<double, 3> > >, 3>&) (uggrid.hh:517)
==1863==    by 0x4117B6: void LoadBalance::test<Dune::UGGrid<3> >(Dune::UGGrid<3>&) (test-parallel-ug.cc:473)
==1863==  Address 0xcdf690a is 2 bytes after a block of size 104 alloc'd
==1863==    at 0x4C2935B: malloc (vg_replace_malloc.c:270)
==1863==    by 0x6562F5: UG::GetFreelistMemory(UG::HEAP*, int) (heaps.c:618)
==1863==    by 0x8252A5: UG::D3::GetMemoryForObjectNew(UG::HEAP*, int, int) (ugm.c:326)
==1863==    by 0x825814: CreateNode(UG::D3::grid*, UG::D3::vertex*, UG::D3::geom_object*, int, int) (ugm.c:584)
==1863==    by 0x8350FA: UG::D3::InsertBoundaryNode(UG::D3::grid*, void**) (ugm.c:4731)
==1863==    by 0x845384: UG::D3::InsertMesh(UG::D3::multigrid*, UG::D3::mesh*) (ugm.c:6661)
==1863==    by 0x831ACC: UG::D3::CreateMultiGrid(char*, char*, char*, unsigned long, int, int) (ugm.c:3297)
==1863==    by 0x958EEB: UG::D3::NewCommand(int, char**) (commands.c:1640)
==1863==    by 0x4D7C1E: Dune::UG_NS<3>::NewCommand(int, char**) (ugwrapper.hh:1028)
==1863==    by 0x4DF3EA: Dune::GridFactory<Dune::UGGrid<3> >::createGrid() (uggridfactory.cc:465)
==1863==    by 0x411425: Dune::StructuredGridFactory<Dune::UGGrid<3> >::createCubeGrid(Dune::FieldVector<double, 3> const&, Dune::FieldVector<double, 3> const&, std::array<unsigned int, 3ul> const&) (structuredgridfactory.hh:189)
==1863==    by 0x40ADF2: void testParallelUG<3>(bool) (test-parallel-ug.cc:518)

[[Imported from SVN: r8529]]

[[Imported from SVN: r8528]]

[[Imported from SVN: r8527]]