On Wed, 24 Feb 2016, David Lamparter wrote:
The Sun One Studio compiler is not a supported compiler per the list
in doc/overview.texi. As far as I know, that stopped working a long
time ago. I looked at it when we set up the OmniOS CI and vaguely
remember it was infeasible to make the shipped compiler work. Since
gcc is readily available for Solaris, I don't see this as an issue.
Well, indeed. I'm the last person I know of who regularly did non-GGC
(or GCC-following) builds (and that one had '#pragma(init_func)', which
GCC supports too, at least on that platform).
I could go with going GCC specific. Be good to try flush out anyone who
might be affected by that and give them a chance to object though.
Also, does this depend on using dynamic linking? We do have people who
like to build Quagga with --disable-shared at least (though, that still
results in an ELF binary dynamically linked).
Calling other functions from constructors is generally a bit of a bad
idea as the C runtime has not neccessarily [it should, but...] fully
initialized -- and any Quagga functions quite certainly won't have
been initialized. Having the code in a centralised function would
make neccessary a big fat warning on top of it so that no one
accidentally calls zlog_* or something similar. Having it right there
in the header with quite a bit of "magic" around it makes it very
obvious that the code is special.
A function can be documented special too. A function entry point in the
library just seems a little cleaner than twiddling the list head
directly, but... gut feeling more than anything.
That said, on ordering, the ELF stuff that provides DT_INIT also
provides a way of specifying dependencies via DT_NEEDED. Though, if that
level of twiddling was needed I'd definitely be arguing to stick to
idiomatic, standard C. :)
Lastly, on some architectures constructors are chained together as pure
function bodies without prologue and epilogue, i.e. they just run in
sequence.
That's... horrible.
The key thing here really is just to not have to update the library,
right?
No -- moving memtypes into the files they're used in was also a major
design goal, thus the existence of DEFINE_MTYPE_STATIC(). A table does
not allow for that.
You could have file specific groups.
Considering that the linker functionality for constructors is
neccessarily present on any architecture that supports C++ (this is
how global variable classes get their constructors called),
Right. Not everything supports C++ though. Not that Quagga.net supports
such platforms though. C++ is harder to bring up on weird platforms than
C though.
The thing I have on my mind is embedding Quagga into non-standard,
non-Unix, relatively minimal runtimes, that might have their own
compiler or else do not have special support from GCC for their exe
format. More and more of these runtimes are springing into existence,
thanks to IoT and ultra-minimal "virtualisation" efforts.
I used to sit beside someone who worked on that stuff, and they used to
have fun porting C code over.
Can you find a compiler/environment that does NOT work (but
worked before)?
For what we support, I don't know of any.
I'm just wondering how necessary it is to deviate from C and add more
runtime feature dependencies.
If this can be done in C, even if a bit more verbosely, I'd kind of tend
to that. If it can't be done in C, then the issue for me is that it will
be harder (again) to embed Quagga into other things.
Note, the table approach can still have per-file scope I think, by
having a group per file (and some way of making the group implicit to
the X... macros, if they're to be used as is).
Also, I have put considerable thought into making this as hard as
possible to (accidentally) misuse, removing for example the
possibility to forget initialisation calls. If someone forgets the
DECLARE_MTYPE (or DEFINE_MTYPE_STATIC), they get a compiler error.
If someone forgets the DEFINE_MTYPE, they get a linker error. Pass
NULL as type and you get a warning from the "nonnull" attribute. I'm
not saying it's impossible to misuse but it needs a special kind of
stupid ;)
Sure.
It's cute.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
You can fool some of the people some of the time,
and some of the people all of the time,
and that is sufficient.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
