[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XTL 1.3.pl.9
- To: XTL list <email@example.com>
- Subject: Re: XTL 1.3.pl.9
- From: Angus Leeming <firstname.lastname@example.org>
- Date: Fri, 5 May 2000 19:35:09 +0100
- Delivered-To: mailing list email@example.com
- Mailing-List: contact firstname.lastname@example.org; run by ezmlm
I've tried to be as thorough as I can here.
giop.h input_raw/output_raw cause unaligned access errors at the
moment. (Ie your FIXME needs attention!) See Note 1.
Fixing it to not produce these errors "breaks the standard". Once done, however,
together with the other changes (see below) I can confirm that example codes
compile and run as they should on Alpha machines running Tru64 unix 4.0e, code
compiled with gcc-2.95.2 and with DIGITAL C++ V6.1-029. (I'd also note that
compiling optimised code with g++ takes forever in comparison to cxx.)
So, giop.h needs sorting. I'll have a look next week. You too?
Finally: mips - SGI (really?)
No! I'll have a go on 32 and 64 bit SGI machines next week. Perhaps!
Similarly, I'll check that all is Ok on a linuxAlpha machine with gcc-2.95.2.
Have a good w/e.
Note 1: giop.h
// FIXME: I'm not sure about this. Why is it required in GIOP?
// Even if it is, it should not depend on local word length, or
// we will not be able to talk to a different architecture at
// the other end.
// if (res%lenWord!=0)
The code as is (ie, commented out) causes unaligned access errors.
Changing it to
as is done in xdr.h removes these errors when running examples/tests/giop but
NOT when running examples/bench/xtl/giop.
The only way to remove all these error messages is to uncomment the
standard-breaking code. Some thought needed, I'm afraid.
Note 2: giop.h
call me picky, but to call a boolian variable machineEndianess makes no sense.
How can it be true? MachineLittleendian can be true. Get my drift?
Note 3: xdr.h
Its good to see I finally got xdr.h done satisfactorily / standard conformingly!
Did you notice my comment to input_simple(long)?
I think it would be better to have
This will work correctly on all machines.
The files <cstring> and <cstdio> don't exist on my machine (or on many other
proprietry unices. I think, therefore, that you should put include/cheaders/
back in. Otherwise the examples won't compile on these machines. What's the
harm in them anyway? A minimal version would be:
Anyway, the Makefiles currently refer to them in the $INCLUDE variable for
cxx, so there's some inconsistency somewhere...
Why have you not applied my patches to examples/smart and examples/test? I can
resubmit them if you wish?
The Makefiles in examples/auto, examples/bench/xtl and examples/bench/vxtl don't
make any object files, so the dependency info at the bottom should be changed
giop.o: ../../../include/xtl/objio.h ../../../include/xtl/config.h
giop: ../../../include/xtl/objio.h ../../../include/xtl/config.h
ogiop: ../../../include/xtl/objio.h ../../../include/xtl/config.h
They all need a "make dep" first!
I forgot to mention that if insufficient memory is allocated to the buffer then
the code in examples/bench/xtl core dumps mysteriously. It appears not to
trigger buffer_overflow_error. At least, I didn't get any message to screen.
What happens on your machines?
For the README as you requested
- Angus Leeming
Department of Biological & Medical Systems, Imperial College, London, UK