rds95@leah.Albany.Edu (Robert Seals) (04/21/89)
Hello, I've noticed that programs which need to go into cbreak (I think - the one that sends chars directly through to the program without a newline when entered from a terminal) don't work correctly when compiled with gcc 1.34. This would seem to me to be a function of the library routines and not the compiler, but both `less' (v97) and `scrabble' (just posted to c.s.?) exhibit the same behavior - when compiled with cc, they deal with the keyboard as expected, but with gcc, they do nothing til return is entered. gcc -O -v -Wall -finline-functions -fstrength-reduce files.c on Ultrix 1.2. Any ideas? rob
James.Aspnes@CS.CMU.EDU (04/23/89)
Your problem is very likely to be the result of non-ANSI-conformant macros lurking in /usr/include/sys/ioctl.h (I'm assuming that since leah.albany.edu is running sendmail you're on a BSD system). Try compiling your program with -traditional.
meissner@DG-RTP.DG.COM (Michael Meissner) (04/28/89)
In article <1776@leah.Albany.Edu> rds95@leah.Albany.Edu (Robert Seals) writes: | Hello, | | I've noticed that programs which need to go into cbreak (I think - the | one that sends chars directly through to the program without a newline | when entered from a terminal) don't work correctly when compiled with | gcc 1.34. This would seem to me to be a function of the library routines | and not the compiler, but both `less' (v97) and `scrabble' (just posted | to c.s.?) exhibit the same behavior - when compiled with cc, they | deal with the keyboard as expected, but with gcc, they do nothing til | return is entered. This seems to come up every so often. Usually this comes about because the include file "/usr/include/sys/ioctl.h" (and others too, but this is the prime culprit) is not compatible with ANSI. Since GCC defaults to the ANSI interpretation, it means that you issue the wrong ioctl. In particular, the following macros are the ones with problems (macros taken from a Sun 3.5 system, since we have one internally): #define _IO(x,y) (IOC_VOID|('x'<<8)|y) #define _IOR(x,y,t) (IOC_OUT|((sizeof(t)&IOCPARM_MASK)<<16)|('x'<<8)|y) #define _IORN(x,y,t) (IOC_OUT|(((t)&IOCPARM_MASK)<<16)|('x'<<8)|y) #define _IOW(x,y,t) (IOC_IN|((sizeof(t)&IOCPARM_MASK)<<16)|('x'<<8)|y) #define _IOWN(x,y,t) (IOC_IN|(((t)&IOCPARM_MASK)<<16)|('x'<<8)|y) /* this should be _IORW, but stdio got there first */ #define _IOWR(x,y,t) (IOC_INOUT|((sizeof(t)&IOCPARM_MASK)<<16)|('x'<<8)|y) #define _IOWRN(x,y,t) (IOC_INOUT|(((t)&IOCPARM_MASK)<<16)|('x'<<8)|y) /* ... */ #define TIOCSETC _IOW(t,17,struct tchars)/* set special characters */ #define TIOCGETC _IOR(t,18,struct tchars)/* get special characters */ These macros depend on substituting the argument 'x' into the character constant, which is what ANSI disallows. To fix this, you have a few options: 1) Use the -traditional switch, which will tell GCC to do things the old fashioned PCC way; 2) Use the fixincludes script provided with GCC to repair the includes, so they can used with an ANSI compiler. The includes are put into GCC's private directory: /usr/local/lib/gcc-include which GCC searches before /usr/include. I have noticed that the include files that are fixed don't work with non-ANSI compilers or GCC's -traditional switch. -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner If compiles were much Internet: meissner@dg-rtp.DG.COM faster, when would we Old Internet: meissner%dg-rtp.DG.COM@relay.cs.net have time for netnews?
cks@white.toronto.edu (Chris Siebenmann) (05/03/89)
In article <8904281417.AA13699@tiktok.dg.com> Michael Meissner <meissner@dg-rtp.dg.com> writes: ... | which GCC searches before /usr/include. I have noticed that | the include files that are fixed don't work with non-ANSI | compilers or GCC's -traditional switch. I consider this a definate bug, and have a patch that papers over the problem (I don't consider it a 100% true fix). My fix causes gcc to skip its include directory when -traditional is given. Since other necessary things may live in there, this isn't a perfect solution, but sort of adding a -ansi-specific include directory I can't think of one. My patch (apply to cccp.c): *** /tmp/,RCSt1022929 Wed May 3 16:16:49 1989 --- cccp.c Tue Mar 7 21:08:35 1989 *************** *** 769,779 **** /* Unless -fnostdinc, tack on the standard include file dirs to the specified list */ if (!no_standard_includes) { ! if (include == 0) ! include = (cplusplus ? cplusplus_include_defaults : include_defaults); ! else last_include->next = (cplusplus ? cplusplus_include_defaults : include_defaults); } /* Initialize output buffer */ --- 769,788 ---- /* Unless -fnostdinc, tack on the standard include file dirs to the specified list */ if (!no_standard_includes) { ! /* cks@white.toronto.edu Sept 28/1988: Skip GCC include directory ! with ANSI-ied files if -traditional set. ! */ ! if (include == 0) { ! include = (cplusplus ? cplusplus_include_defaults : include_defaults); ! if (traditional) ! include ++; ! } ! else { last_include->next = (cplusplus ? cplusplus_include_defaults : include_defaults); + if (traditional) + last_include->next ++; + } } /* Initialize output buffer */ -- "I shall clasp my hands together and bow to the corners of the world." Number Ten Ox, "Bridge of Birds" Chris Siebenmann ...!utgpu!{ncrcan,ontmoh!moore}!ziebmef!cks cks@white.toronto.edu or ...!utgpu!{,csri!}cks