Article View: gnu.gcc.help
Article #49901Re: ungetc function
From: Wayne Pollock
Date: Fri, 03 Dec 1993 17:18
Date: Fri, 03 Dec 1993 17:18
43 lines
2821 bytes
2821 bytes
In a previous article ICP%ANDESCOL.BITNET@mitvma.mit.edu (Gabriel Perez) writes: >I have your compiler installed on a Solbourne (Sparc clone) machine; I >am trying to install the f2c package from AT&T, but an error occurs >because reportedly the ungetc function is not declared; I have tried >including your stdio.h (which is supossed to be the proper header file >according to the ANSI C documentation I got) but it does not work; can you >please give me a hint on what is happenning? Thank you . The answer is simple: Gnu C (gcc) is NOT ANSI C! It only will produce a standard (ANSI) C compiler if it was built on a system that already has a standard C compiler. I suspect that you, me, and 99% of the prospective users of Gnu C don't already have a standard C compiler (that's what we want gcc for!). In this case the resulting compiler is not K&R C and not standard C. This problem as I understand it is the the C compiler maintainers/creators at Gnu don't consider the (required by the standard) header files to be part of the C compiler for some perverse reason. Some library functions apparently are also not considered part of C by these folks. So if the existing header files have missing or wrong information, it is not added or corrected. Some common problems I have identified with Gnu C built on a Sun Sparc with SunOS and the supplied sun (K&R) C compiler are: in <stdio.h> missing prototypes, especially for ungetc, printf family missing SEEK_SET, SEEK_CUR, and SEEK_END macros (mistakenly installed in <unistd.h>) missing typedef for fpos bad prototype for fgetpos, fsetpos functions in <time.h> missing macro CLOCKS_PER_SEC in <signal.h> missing typedef for sig_atomic_t I'm sure other problems exist too. If you know of any, please sent them to me and I'll try to keep a list of patches to gcc to make it compliant with the standard. (Actually, I hope the maintain of gcc gets mad when he/she reads this and responds with the reasons why the header files are "not our problem"!) Wayne Pollock (The MAD Scientist) Internet: pollock@csee.usf.edu
Technical Details
Message-ID:
<2dnsca$sc2@suntan.eng.usf.edu>Path:
arc1-ca.pugleaf.net!gmd.de!rrz.uni-koeln.de!news.rhrz.uni-bonn.de!urmel.informatik.rwth-aachen.de!news.dfn.de!darwin.sura.net!mailer.acns.fsu.edu!usenet.ufl.edu!suntan.eng.usf.edu!eggo!pollockReferences:
<9312010211.AA27420@life.ai.mit.edu>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 11318c,3600218bddf3d55d X-Google-Attributes: gid11318c,public X-Google-ArrivalTime: 1993-12-03 12:05:44 PST Path: arc1-ca.pugleaf.net!gmd.de!rrz.uni-koeln.de!news.rhrz.uni-bonn.de!urmel.informatik.rwth-aachen.de!news.dfn.de!darwin.sura.net!mailer.acns.fsu.edu!usenet.ufl.edu!suntan.eng.usf.edu!eggo!pollock From: pollock@eggo.usf.edu (Wayne Pollock) Newsgroups: gnu.gcc.help Subject: Re: ungetc function Date: 3 Dec 1993 17:18:02 GMT Organization: University of South Florida at Tampa Lines: 43 Distribution: gnu Message-ID: <2dnsca$sc2@suntan.eng.usf.edu> References: <9312010211.AA27420@life.ai.mit.edu> NNTP-Posting-Host: eggo.usf.edu