samperi@marob.MASA.COM (Dominick Samperi) (02/25/89)
The AT&T C compiler (from System V, Release 2?) chokes on a declaration of the form: extern int bob(double (*)()) ; On the other hand, it is accepted by Microsoft C and other C compilers. The AT&T C++ translator also chokes on this. Is this declaration incorrect, or have I been bitten by a compiler bug? -- Dominick Samperi -- ESCC samperi@marob.masa.com uunet!hombre!samperi
guy@auspex.UUCP (Guy Harris) (02/26/89)
>The AT&T C compiler (from System V, Release 2?) chokes on a declaration >of the form: > >extern int bob(double (*)()) ; > >On the other hand, it is accepted by Microsoft C and other C compilers. (Deep breath, count to 5) Prototypes are a relatively new feature in C implementations. Some compilers do not support them. The "Portable C Compiler", upon which many (most?) UNIX C compilers - including the ones AT&T supplies - are based, does not support them. >The AT&T C++ translator also chokes on this. Is this declaration >incorrect, or have I been bitten by a compiler bug? Neither. The declaration in question appears to be correct, except that it says the argument taken by "bob" is a pointer to a function returning "double", but doesn't say what sort of arguments that function takes. I think this is legal, however. This does not mean that there is a bug in the AT&T C compiler, though. It merely means that the S5R2 C compiler doesn't support function prototypes. I don't know whether it's legal C++ or not; if it is, I suspect the declaration says, in C++, that the function to which the pointer points takes no arguments (since C++, unlike C, does not have the notion of "old-style" function declarations where an empty argument list indicates that the types of the arguments are unknown).
gwyn@smoke.BRL.MIL (Doug Gwyn ) (02/26/89)
In article <569@marob.MASA.COM> samperi@marob.MASA.COM (Dominick Samperi) writes: >The AT&T C compiler (from System V, Release 2?) chokes on a declaration >of the form: >extern int bob(double (*)()) ; Of course it does, because that's a function prototype, which was only recently added to the C language. AT&T UNIX C compilers up to SVR4 support a flavor of C modeled after K&R 1st Edition Appendix A, with some common extensions (enums, struct copy, void). I am told that the UNIX SVR4 C compiler will conform to the (forthcoming) ANSI C standard, which includes function prototypes. Until then, you must leave the argument declarations out of your function declarations.
platt@ndla.UUCP (Daniel E. Platt) (02/26/89)
In article <569@marob.MASA.COM>, samperi@marob.MASA.COM (Dominick Samperi) writes: > The AT&T C compiler (from System V, Release 2?) chokes on a declaration > of the form: > > extern int bob(double (*)()) ; > > On the other hand, it is accepted by Microsoft C and other C compilers. > The AT&T C++ translator also chokes on this. Is this declaration > incorrect, or have I been bitten by a compiler bug? The declaration you made corresponds to the ANSI standard, where arguement type checking is legal. In the K&R standard, as well as in C++, type checking of this kind is NOT standard. You haven't found a bug, just a problem with the various standards that are now floating around. What you need to do is to declare extern int bob(); and you need to make sure that the type passed and received are the same (very sure, or it won't work!!!). Hope this helps! Dan Platt
gwyn@smoke.BRL.MIL (Doug Gwyn ) (02/26/89)
In article <1071@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes:
- >extern int bob(double (*)()) ;
-... but doesn't say what sort of arguments that function takes. I
-think this is legal, however.
Yes, it's legal, but it explicitly amounts to an "old style" declaration
of the "bob" function, with all the consequences thereof.
-I don't know whether it's legal C++ or not; if it is, I suspect the
-declaration says, in C++, that the function to which the pointer points
-takes no arguments ...
That's right. Old C++ did not use func(void) but rather just func().
This may be changing toward ANSI C style, but I don't know for sure.ark@alice.UUCP (Andrew Koenig) (02/26/89)
In article <1071@auspex.UUCP>, guy@auspex.UUCP (Guy Harris) writes: [discussion about extern int bob(double (*)()); ] > (Deep breath, count to 5) Prototypes are a relatively new feature in C > implementations. Some compilers do not support them. The "Portable C > Compiler", upon which many (most?) UNIX C compilers - including the ones > AT&T supplies - are based, does not support them. > The declaration in question appears to be correct, except that it says > the argument taken by "bob" is a pointer to a function returning > "double", but doesn't say what sort of arguments that function takes. I > think this is legal, however. Sure it is -- the arguments of the function are unspecified so it's up to the programmer to get them right when calling it. > I don't know whether it's legal C++ or not; if it is, I suspect the > declaration says, in C++, that the function to which the pointer points > takes no arguments (since C++, unlike C, does not have the notion of > "old-style" function declarations where an empty argument list indicates > that the types of the arguments are unknown). Exactly right. It is legal C++, by the way, but presently available C++ translator do not support it -- it is hard to parse. You can achieve the same effect by a semantic hack: typedef (*doublefp)(); extern double bob(doublefp); or by a syntactic hack: extern double bob(auto double(*)()); The (not yet generally available) C++ translator on my machine supports the original form of the declaration just fine, so I imagine it will also be supported by the next version released. -- --Andrew Koenig ark@europa.att.com
samperi@marob.MASA.COM (Dominick Samperi) (02/27/89)
In article <9717@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>The AT&T C compiler (from System V, Release 2?) chokes on a declaration >>of the form: >>extern int bob(double (*)()) ; > >Of course it does, because that's a function prototype, which was only >recently added to the C language. Yes, but this does not explain why the AT&T C++ translator chokes. It turns out that although the translator will not swallow this declaration, the following goes down without a whimper: typedef double (*PFD)() ; extern int bob(PFD) ; Furthermore, B. Stroustrup's C++ text claims that the first declaration should be valid (see Section 8.7). -- Dominick Samperi -- ESCC samperi@marob.masa.com uunet!hombre!samperi
samperi@marob.MASA.COM (Dominick Samperi) (02/27/89)
In article <1071@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >I don't know whether it's legal C++ or not; if it is, I suspect the >declaration says, in C++, that the function to which the pointer points >takes no arguments (since C++, unlike C, does not have the notion of >"old-style" function declarations where an empty argument list indicates >that the types of the arguments are unknown). It is legal in C++ (see Section 8.7 of Stroustrup's text). Furthermore, changing the declaration to 'extern bob(double (*)(void)) ;' does not help. The only thing that the C++ translator will swallow is 'typedef double (*PFD)() ; extern bob(PFD) ;'. -- Dominick Samperi -- ESCC samperi@marob.masa.com uunet!hombre!samperi
guy@auspex.UUCP (Guy Harris) (02/27/89)
>Yes, it's legal, but it explicitly amounts to an "old style" declaration >of the "bob" function, with all the consequences thereof. That's what I figured. >That's right. Old C++ did not use func(void) but rather just func(). >This may be changing toward ANSI C style, but I don't know for sure. S ("S", by analogy to "K&R") says in "15.3 Anachronisms": The extensions presented here may be provided to make it easier to use C programs as C++ programs. Note that each of these features has undesirable aspects. An implementation providing them should also provide a way for the user to ensure that they did not occur in a source file. ... The keyword 'void' may be used to indicat that a function takes no arguments, thus '(void)' is equivalent to '()'. Assuming this is still the case, then 1) ANSI C style is *supported*, but 2) it's deprecated. I don't know what the "undesirable aspect" of the extension in question is; perhaps it's the mismatch between declaration and use - you call a no-arguments function as "foo()", but declare it as "foo(void)". I do consider that mismatch undesirable, although eliminating it in C89 (or C90?) is impractical, given the volume of old code out there. Assuming a new version of the C standard comes out sometime in the future, I would like to see "int foo()" mean "'foo' is a function that takes no arguments and returns 'int'" in that new version; by that time, presumably, all the old-style non-prototype function declarations and definitions would have gone away. (The May 13, 1988 draft indicates that old-style function declarators and definitions are "obsolescent features".) I would also like to see compilers at least have an option to warn about 1) old-style function declarators and definitions, 2) functions not declared as "void" that return no value, and 3) functions declared "implicitly", in order to encourage the use of prototype declarations and definitions and the improved type-checking that would result. (As I remember, "cfront" produces some or all of those warnings if it detects any of the above items in C++ programs fed to it.)
prc@maxim.ERBE.SE (Robert Claeson) (02/28/89)
In article <9726@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > Old C++ did not use func(void) but rather just func(). > This may be changing toward ANSI C style, but I don't know for sure. At least the AT&T C++ Translator 1.1 does support both styles. A function taking no arguments can be declared as either func() or func(void). -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden Tel: +46 (0)758-202 50 Fax: +46 (0)758-197 20 EUnet: rclaeson@ERBE.SE uucp: {uunet,enea}!erbe.se!rclaeson ARPAnet: rclaeson%ERBE.SE@uunet.UU.NET BITNET: rclaeson@ERBE.SE
lfoard@wpi.wpi.edu (Lawrence C Foard) (03/01/89)
In article <1071@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >.... > >(Deep breath, count to 5) Prototypes are a relatively new feature in C >implementations. Some compilers do not support them. The "Portable C >Compiler", upon which many (most?) UNIX C compilers - including the ones >AT&T supplies - are based, does not support them. > >.... Turbo C and probably other PC C compilers have supported ANSI prototypes for several years. Although AT&T still hasn't gotten its act together yet, GNU-C supports ANSI prototypes and is available free. ANSI prototypes are definitly worth using because most stupid errors are caught at compile time instead of run time. They also make math much easier because it will automatically convert an integer to a float when passed to a function. Does any one know why AT&T is delaying so much? Standard UNIX C still barfs on things like p=-1 . -- /----------------------------------------------------------------------------\ | My opinions are violently objected to by my employer. I was fired last year| | but they forgot to remove my account. Lawrence Foard (entropy) | \----------------------------------------------------------------------------/
gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/01/89)
In article <1109@wpi.wpi.edu> lfoard@wpi.wpi.edu (Lawrence C Foard) writes: >Does any one know why AT&T is delaying so much? AT&T decided to wait until there is a C standard before releasing a compiler that is claimed to conform to it. Since the details of prototypes MIGHT have changed up until the very last minute, this avoids customers starting to use the new features and then having the rug pulled from under them when the features had to be changed. >Standard UNIX C still barfs on things like p=-1 . No, it doesn't. P.S. Obviously I'm not an official AT&T spokesman.
mhampson@wpi.wpi.edu (Mark A. Hampson) (03/02/89)
Unless mistaken, C++ is a superset of the proposed ANSI Standard C.
In ANSI C the statement you indicated had undefined array dimensions,
which sorry to say is a violation of ANSI C.
--
Mark A. Hampson WPI Mechanical Engineering
Internet: mhampson@wpi.wpi.edu Worcester, MA 01609 USA
(508) 831-5498
70% of all code is idiot proofing djones@megatest.UUCP (Dave Jones) (03/02/89)
From article <1144@wpi.wpi.edu>, by mhampson@wpi.wpi.edu (Mark A. Hampson):
> Unless mistaken, C++ is a superset of the proposed ANSI Standard C.
Not unless they've fixed it. Last I heard, C++ required prototypes,
so it would not accept an old C program (or an old C include-file, which
is a royal pain), and it did the prototypes just a little differently
from ANSII C.
But then, I haven't obtained an update in a long time.ftw@masscomp.UUCP (Farrell Woods) (03/03/89)
In article <1109@wpi.wpi.edu> lfoard@wpi.wpi.edu (Lawrence C Foard) writes: >Turbo C and probably other PC C compilers have supported ANSI prototypes for >several years. Have they now? Tell me again how many years Turbo C has been around. Tell me again how how many years the dpANS and pANS have been available for compiler vendors. What's your definition of "several years?" >Although AT&T still hasn't gotten its act together yet, GNU-C >supports ANSI prototypes and is available free. ANSI prototypes are definitly >worth using because most stupid errors are caught at compile time instead of >run time. They also make math much easier because it will automatically >convert an integer to a float when passed to a function. Does any one know why >AT&T is delaying so much? Standard UNIX C still barfs on things like >p=-1 . The answer to your first question is obvious. They don't have the benefit of your wisdon and knowledge at their disposal. Had they these things, they would have had a satisfactory compiler out for "several years" now. The answer to your second question requires more information. Please define "Standard UNIX C" for us and maybe we can help. Some compilers supported the "=op" expressions as well as the current "op=" type. Some compilers were silent about it (Whitesmiths, for example), and some would issue a warning, and in the case of your example, decrement p. Go stand in the corner with those who still think 'x' is an int. Sheesh! -- Farrell T. Woods Voice: (508) 692-6200 x2471 MASSCOMP Operating Systems Group Internet: ftw@masscomp.com 1 Technology Way uucp: {backbones}!masscomp!ftw Westford, MA 01886 OS/2: Half an operating system
ftw@masscomp.UUCP (Farrell Woods) (03/03/89)
Recently, I ended a response with: >Go stand in the corner with those who still think 'x' is an int. What I *really* meant was: >Go stand in the corner with those who still think 'x' is a char. -- Farrell T. Woods Voice: (508) 692-6200 x2471 MASSCOMP Operating Systems Group Internet: ftw@masscomp.com 1 Technology Way uucp: {backbones}!masscomp!ftw Westford, MA 01886 OS/2: Half an operating system
henry@utzoo.uucp (Henry Spencer) (03/03/89)
In article <1109@wpi.wpi.edu> lfoard@wpi.wpi.edu (Lawrence C Foard) writes: >... Standard UNIX C still barfs on things like p=-1 . To the extent that this is true -- there is no such thing as a "standard UNIX C" with consistent behavior across Unixes -- it barfs because it *should*: there is still reason to worry about old code that uses the old, no-longer-supported assignment operators like =- . Compilers in new environments, like Turbo C, don't have to worry about this, but compilers for environments that have 15 or 20 years of C history behind them can't always ignore such issues. -- The Earth is our mother; | Henry Spencer at U of Toronto Zoology our nine months are up. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/03/89)
In article <774@masscomp.UUCP> ftw@quasar.masscomp.UUCP (Farrell Woods) writes: >Go stand in the corner with those who still think 'x' is an int. What IS this, anyway? 'x' IS an int.
tp@granite.dec.com (t patterson) (03/03/89)
In article <9774@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn <gwyn>) writes: >In article <774@masscomp.UUCP> ftw@quasar.masscomp.UUCP (Farrell Woods) writes: >>Go stand in the corner with those who still think 'x' is an int. > >What IS this, anyway? 'x' IS an int. well, if some of you guys aren't going to believe Doug Gwyn and Chris Torek, will you belive your own C compiler? following is a script testing pcc, gcc 1.31, and vcc (DEC's own) on Ultrix 2.2: (apologies for the quickie C program...) Script started on Thu Mar 2 20:20:30 1989 granite [51] cat xint.c main() { printf("size is: %d\n", sizeof('x') ); } granite [52] cc xint.c granite [53] a.out size is: 4 granite [51] gcc -v gcc version 1.31 granite [52] gcc xint.c granite [53] a.out size is: 4 granite [54] vcc xint.c granite [55] a.out size is: 4 granite [56] script done on Thu Mar 2 20:21:18 1989 hmm... either 'x' is an "int" or a lot of compiler writers are wrong. (or "sizeof(char)" was suddenly and unexpectedly given a promotion.) -- t. patterson domain: tp@decwrl.dec.com path: decwrl!tp icbm: 122 9 41 W / 37 26 35 N % opinions herein are mine alone and certainly not those of DEC
guy@auspex.UUCP (Guy Harris) (03/03/89)
>Although AT&T still hasn't gotten its act together yet, I think S5R4 will fully support ANSI C (assuming that "ANSI C" exists in time to make an implementation for S5R4; otherwise, it'll probably correspond to the last draft that AT&T could reasonably use to build an implementation). >ANSI prototypes are definitly worth using Yes, I think most of us agree; however, the fact is that not all UNIX C compilers support them, so you either have to live with that or get a compiler such as GCC that does support them. >Does any one know why AT&T is delaying so much? No, perhaps they decided not to put out an "old C plus prototypes" compiler as a stopgap measure? >Standard UNIX C still barfs on things like p=-1 . The System V C compiler may issue a warning, but it interprets that statement as "assign -1 to 'p'". It certainly doesn't "barf" on it.
ftw@masscomp.UUCP (Farrell Woods) (03/03/89)
In article <9774@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <774@masscomp.UUCP> I wrote: >>Go stand in the corner with those who still think 'x' is an int. >What IS this, anyway? 'x' IS an int. Yes, and I did post a brief followup where I changed "int" to "char". -- Farrell T. Woods Voice: (508) 392-2471 Concurrent Computer Corporation Domain: ftw@masscomp.com 1 Technology Way uucp: {backbones}!masscomp!ftw Westford, MA 01886 OS/2: Half an operating system
lfoard@wpi.wpi.edu (Lawrence C Foard) (03/04/89)
In article <9761@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>Standard UNIX C still barfs on things like p=-1 . > >No, it doesn't. Yes it does. The c compiler that came with the system VS Gnu-c Script started on Sat Mar 4 02:32:12 1989 % cat tmp.c main() { int p=2; p=-1; printf("%d\n",p); } % cc tmp.c "tmp.c", line 4: warning: old-fashioned assignment operator % a.out 1 % gcc tmp.c % a.out -1 % exit script done on Sat Mar 4 02:32:36 1989 Maybe WPI is just brain damaged :) but so far every UNIX system I have seen here has this problem, so far every PC C compiler has not. Atleast UNIX could have implemented the ANSI Prototypes and gotten rid of this bug. This summer I had to write a program that converted ANSI style C to old fashioned C so it could be run on an HP workstation, the time saved by using ANSI prototypes was worth the effort. Actually it doesn't matter if 'A' is a char or integer it will get casted into whatever is needed any ways. -- /----------------------------------------------------------------------------\ | My opinions are violently objected to by my employer. I was fired last year| | but they forgot to remove my account. Lawrence Foard (entropy) | \----------------------------------------------------------------------------/
ftw@masscomp.UUCP (Farrell Woods) (03/05/89)
In article <1187@wpi.wpi.edu> lfoard@wpi.wpi.edu (Lawrence C Foard) writes: >Yes it does [barf]. The c compiler that came with the system VS Gnu-c [example deleted] >Maybe WPI is just brain damaged :) but so far every UNIX system I have seen >here has this problem, so far every PC C compiler has not. Atleast UNIX could >have implemented the ANSI Prototypes and gotten rid of this bug. This summer I >had to write a program that converted ANSI style C to old fashioned C so it >could be run on an HP workstation, the time saved by using ANSI prototypes was >worth the effort. Actually it doesn't matter if 'A' is a char or integer it >will get casted into whatever is needed any ways. Two things: First, your script points out that whatever Unix compiler you're using supports the old-fashioned =op, and that gcc does not. Note that since the operators and operands are jammed together (i.e., no whitespace), the compiler has no clue that perhaps you really meant "p = -1;". The tokenizer grabbed the longest token first (in your case, it grabbed "=-" as a single token. At least you got a warning, but the behavior is not incorrect, since it is not pANS compliant. Second, prototypes have nothing to do with this, nor do they have anything to do with assignments of character constants (which we all know now ints ;-) ) to chars. This is just a narrowing assignment. -- Farrell T. Woods Voice: (508) 392-2471 Concurrent Computer Corporation Domain: ftw@masscomp.com 1 Technology Way uucp: {backbones}!masscomp!ftw Westford, MA 01886 OS/2: Half an operating system
gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/05/89)
In article <1187@wpi.wpi.edu> lfoard@wpi.wpi.edu (Lawrence C Foard) writes: >In article <9761@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>>Standard UNIX C still barfs on things like p=-1 . >>No, it doesn't. >Yes it does. The c compiler that came with the system VS Gnu-c When you said "still", I naturally assumed you were talking about the most recent release, not about some old-fashioned compiler you happen to have at your site.
guy@auspex.UUCP (Guy Harris) (03/05/89)
> The c compiler that came with the system VS Gnu-c >% cc tmp.c >"tmp.c", line 4: warning: old-fashioned assignment operator You have an old C compiler. Neither the System V version of PCC nor the one shipped with SunOS 4.0 support old-fashioned assignment operators; "x=-1" is interpreted by both as "assign -1 to x". >Atleast UNIX could have implemented the ANSI Prototypes and gotten rid >of this bug. I don't know what "the ANSI Prototypes" means here, but if it means "function prototypes" it wouldn't have made a bit of difference to the interpretation of "x=-1". If it were a full (p)ANS C compiler, it would have interpreted "x=-1" properly, but just implementing prototypes does not a full (p)ANS C compiler make. There are several different UNIX C compilers, not least because there are several different architectures that support UNIX. Not all of them have been "modernized" to the same degree. The BSD compiler doesn't seem to have been modernized in this regard.
Kevin_P_McCarty@cup.portal.com (03/07/89)
In article <774@masscomp.UUCP> ftw@masscomp.UUCP (Farrell Woods) writes: >In article <1109@wpi.wpi.edu> lfoard@wpi.wpi.edu (Lawrence C Foard) writes: >>Turbo C and probably other PC C compilers have supported ANSI prototypes for >>several years. >Have they now? Tell me again how many years Turbo C has been around. Tell >me again how how many years the dpANS and pANS have been available for >compiler vendors. What's your definition of "several years?" I have a copy of the August 1985 draft, and it includes function prototypes, so X3J11 has been talking about them for at least 3 1/2 years. Does that count as several years? Kevin McCarty
tneff@well.UUCP (Tom Neff) (03/10/89)
In article <9761@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >AT&T decided to wait until there is a C standard before releasing >a compiler that is claimed to conform to it. Since the details of >prototypes MIGHT have changed up until the very last minute, this >avoids customers starting to use the new features and then having >the rug pulled from under them when the features had to be changed. Well AT&T may have their conservative reputation to uphold, but speaking as a customer I wish they would get off the pot and release a draft ANSI conformant compiler SOON. Considering how un-cheap my development and support licenses are, it is more than faintly annoying to realize that a $99 PC compiler from the corner Radio Shack will handle programs written using prototypes (say, in 1987) while my compiler won't. I admit it took a long time for the committee to wade through all those drafts, but the changes have been minor for some time now and *specifically* not "compiler breakers" that I have seen. It occurs to me that some of this could be political. I hope not though, I just want the best compiler AT&T can release. -- Tom Neff tneff@well.UUCP or tneff@dasys1.UUCP