bmw20 at cl.cam.ac.uk
Mon Jul 24 17:00:37 CEST 2006
The latest release of ECL (0.9i) provides a certain amount of support for use of Unicode:
"ECL can also be built with support for strings and symbols with unicode
characters (patches by B. Spilsbury). However, since the reader still does not
understand external formats, there is some way until we can claim that ECL
Unicode support is needed by the (C++) fspp module in order to compute (Unicode) character offsets. Would anyone object to upgrading PET to this new version of ECL? (There is some non backwards-compatibility in the naming of functions calls in the new version, which presumably could be worked around with suitable #ifdef's.)
On a related note... a call to the function pic_base_state::opt_double_attr in pic-handler.cpp results in a SIGFPE exception under certain conditions (namely, when PET is compiled on my Ubuntu laptop, but not my Fedora office machine; when PET is compiled with ECL support, although this part of the code has nothing to do with any ECL calls; only after a varying number of XML PIC inputs have been received).
//Program received signal SIGFPE, Arithmetic exception.
//0x08099fac in pic::pic_base_state::opt_double_attr (this=0x9444f80, attr=@0xbf8f6a0c, aname=0x815a751 "prio", def=0) at pic-handler.cpp:72
This is apparently not a new bug relative to the PET source code (I can reproduce it when I check out older versions of the PET source) and appears to apply equally to ECL 0.9h and 0.9i. Does anyone have any idea how to fix this?
More information about the developers