On Tue, Oct 13, 2015 at 07:32:08PM +0200, Eric Botcazou wrote:
> > My main question about this series is - how generally useful do you
> > expect it to be? I know of some different projects that would like
> > bi-endian capability, but it looks like this series implements something
> > that is a little too limited to be of use in these cases.
>
> AdaCore has customers who have been using it for a few years. With the
> inline
> pragma and either the configuration pragma (Ada) or the switch (C/C++), you
> can use it without much code rewriting.
>
> > It looks like it comes with a nontrivial maintenance cost.
>
> Nontrivial but manageable IMO and the heavily modified parts (mostly the RTL
> expander) are "cold" these days. I suspect that less "limited" versions
> would
> be far more intrusive and less manageable.
>
> Of course I would do the maintenance (I have been doing it for a few years at
> AdaCore), except for the C++ front-end that I don't know at all; that's why
> I'm OK to drop the C++ support for now.
I haven't looked at the C++ changes, but I tend to think they mat may be
the language where this is the least useful. I expect it would be
pretty "trivial" to write some wrapper classes that use bswap in
operators so you could say things like struct { uint32_t_be x; }; and
have x stored in big endian. At which point all you are really missing
is a flag to have all struct members work that way, but rewriting all
struct members of type uint32_t to uint32_t_be should be straight
forward.
trev
