carciofi@SRC.Honeywell.COM (Jim Carciofini) (10/12/89)
I just got GNU emacs 18.55 working on an IBM PS/2 (model P70) under AIX 1.1 I used m-ibmps2-aix.h and s-usg5-2-2.h I also had to add the following in src/config.h after the "#include m-ibmps2-aix.h" line: /* AIX has ptys unlike most usg machine */ #define HAVE_PTYS /* Hack to get around apparent bug in AIX C compiler? "regex.c" appears to assume that C will extend the sign bit when a char is cast to an int. AIX C V1.1 does not do this. This hack does not work when compiler optimizations are turned on. Is there a better way to do this? */ #undef SIGN_EXTEND_CHAR #define SIGN_EXTEND_CHAR(x) ((signed char) x) The SIGN_EXTEND_CHAR problem caused most regular expresions to fail. Thus temacs broke while trying to load "inc-vers". I am new to C and dont know if this is the "right" way to fix this. I would like a "clean" fix that will work when I turn on compiler optimizations. Any ideas?
hue@netcom.UUCP (Jonathan Hue) (10/12/89)
In article <34525@srcsip.UUCP> carciofi@SRC.Honeywell.COM (Jim Carciofini) writes: >#define HAVE_PTYS >/* Hack to get around apparent bug in AIX C compiler? "regex.c" appears to > assume that C will extend the sign bit when a char is cast to an int. > AIX C V1.1 does not do this. This hack does not work when compiler > optimizations are turned on. Is there a better way to do this? */ >#undef SIGN_EXTEND_CHAR >#define SIGN_EXTEND_CHAR(x) ((signed char) x) It's not a bug - chars are unsigned in the PS/2's compiler. It shouldn't extend the sign when promoting to an int. When I brought up 18.52 I used something like the following: #define SIGN_EXTEND_CHAR(x) ((x) & 0x80 ? ((x) - 255) : (x)) -Jonathan
hue@netcom.UUCP (Jonathan Hue) (10/15/89)
In article <2896@netcom.UUCP> hue@netcom.UUCP I write: > >#define SIGN_EXTEND_CHAR(x) ((x) & 0x80 ? ((x) - 255) : (x)) That should have been 256, not 255. Seems like the (signed char) cast should have worked though. -Jonathan
meissner@twohot.rtp.dg.com (Michael Meissner) (10/16/89)
In article <2896@netcom.UUCP> hue@netcom.UUCP (Jonathan Hue) writes: > It's not a bug - chars are unsigned in the PS/2's compiler. It shouldn't > extend the sign when promoting to an int. When I brought up 18.52 I used > something like the following: > > #define SIGN_EXTEND_CHAR(x) ((x) & 0x80 ? ((x) - 255) : (x)) A usually more efficent way of sign extending characters (depending on how much branches cost in terms of hardware speed or compiler optimizations) is: #define SIGN_EXTEND_CHAR(a) ((((a) & 0xFF) ^ 0x80) - 0x80) The & 0xFF can be eliminated if you are sure that a is in fact a char variable and not an integer, since that automatically occurs in promoting an unsigned char to int. -- Michael Meissner, Data General. If compiles where much Uucp: ...!mcnc!rti!xyzzy!meissner faster, when would we Internet: meissner@dg-rtp.DG.COM have time for netnews?
lhf@aries5.uucp (Luiz H de Figueiredo) (10/17/89)
In article <MEISSNER.89Oct16114934@twohot.rtp.dg.com> meissner@twohot.rtp.dg.com (Michael Meissner) writes: >In article <2896@netcom.UUCP> hue@netcom.UUCP (Jonathan Hue) writes: > >A usually more efficent way of sign extending characters (depending >on how much branches cost in terms of hardware speed or compiler >optimizations) is: > >#define SIGN_EXTEND_CHAR(a) ((((a) & 0xFF) ^ 0x80) - 0x80) Why not use #define SIGN_EXTEND_CHAR(a) ( (int) (signed char) (a) ) I am missing something? ------------------------------------------------------------------------------- Luiz Henrique de Figueiredo internet: lhf@aries5.uwaterloo.ca Computer Systems Group bitnet: lhf@watcsg.bitnet University of Waterloo ------------------------------------------------------------------------------- eof