QUESTIONS 2

[Angus Leeming <a.leeming@ic.ac.uk>]

Before I ask the questions, I'll sweeten you up by saying that I've got
GIOP_format working happily on the Alpha.

José> Yes. You're correct. req_align is certainly not "reader friendly" code. :-)
José> It might not even be the fastest possible, but as it is critical for
José> performance we should be very careful when changing it.

I have had to change req_align() to do so :-(
However, I think that the logic behind the old version was incorrect.
(Certainly, it didn't work on the Alpha!) The new version is no bigger, so
performance shouldn't change.

_______________________________________________________________ 
Ok, the questions:

There is a variable "bool endianess" in GIOP_format. What is its purpose?

I THINK that it exists so that data written by one machine can be read by
another. Is this correct?

If so, then "long" should be cast to "long long" for storage (in
GIOP_format) ALWAYS, because long is 64 bits on some machines and 32 bits on
others.

If this isn't its purpose, then endianess is redundant I think. (And
consequently, all those calls to bswap_16() etc are unnecessary.)

Another, related question:
Is GIOP_format designed to import/export between different machines whilst
XDR_format is designed for one machine only?

If XDR_format is designed for possibly MANY machines then similar endianess
functionality should be put in XDR_format. It doesn't exist currently.
Furthermore, since the length of a word differs between machines, then the code
should use 64 bits as its storage size ALWAYS. Same reasoning as above. Sounds
horrible, doesn't it!!!

If XDR_format is designed for ONE machine only, then we can discard all that
bswap_32() etc stuff. The internal translations don't need it. This means that
those global functions can be sucked back into the class.

I'm willing to implement the fixes, but need the answers to do so...
Angus