Date: Wed, 7 May 1997 10:54:28 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: michaelh@cet.co.jp (Michael Hancock) Cc: terry@lambert.org, rb@gid.co.uk, bde@zeta.org.au, hackers@FreeBSD.ORG, jkh@time.cdrom.com, nadav@barcode.co.il, gclarkii@main.gbdata.com Subject: Re: /usr/include/ftpio.h is not C++ safe Message-ID: <199705071754.KAA21604@phaeton.artisoft.com> In-Reply-To: <Pine.SV4.3.95.970507114121.14444A-100000@parkplace.cet.co.jp> from "Michael Hancock" at May 7, 97 11:57:41 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Why do I feel the ANSI people are selling the history of the UNIX > > culture down the river? > > I write little programs called foo.c in K&R all the time and probably > always will. > > For production quality code for use by others for new development I want > compiler help in enforcing correct use of my interfaces. Most modern > compilers are by default 'ANSI minus astonishing ANSI' which usually > leaves what we want. For production quality code for use by others for new developement, I use a compiler which "decorates" symbols. Yeah, it's stupid to do that, but what can you do when the compiler idiots won't put any attribution fields in the object format's symbol table? Answer: you decorate instead of attribute. Then the linker *strongly* and *loudly* enforces both calling conventions and return values. Not only that, if I get a commercial linker instead of relying on hacker-ware, it will undecorate the names and tell me things like: Error: invert.c: line 78: lseek called with 2nd argument type 'int' when type 'quad' was expected. ...or, if I turn off fatality for this type of error: Warning: invert.c: line 78: lseek called with 2nd argument type 'int' when type 'quad' was expected; an argument conversion stub function has been supplied. and the code works. Personally, I want my calling conventions enforced, even when I fail to have a prototype in scope. A standard ANSI compiler won't bitch about linking objects with bogus prototypes (kernel vs. user land function calling conventions, etc.), and it won't bitch about linking K&R compiled code with ANSI compiled code, with argument and return value mismatches. That's because all it has knowledge of are the symbols themselves, not their proper and actualy use. It *SHOULD* bith in these cases. I'd *welcome* a compiler that warned the bejesus out of me when I linked K&R to ANSI code -- and then produced runnable code *anyway*. I'd link the ANSI code with the stub creation warning on, and I'd link the K&R code with it off. And get running code, which is more important than unpuckering some standard committee's anus, IMO. ANSI prototypes buy me nothing over smart linker technology, other than implying type conversion (as the warning case, above), when doing so is probably an error (why the hell was the type 'int' when it should have been 'off_t' ['quad'] in the calling code? With type coercion from an in scope prototype, I'm silently losing precision -- precision I may *need*. And you think 2 digit date fields are a problem...). We all know ANSI prototypes were invented to hide "far" calls in the Windows 3.1 API... let's be honest with ourselves. They are yet another Microsoft'ism designed to make it easier for Microsoft while forcing all of the rest of the word to update their compilers... "Updating anyway? Why not update to Microsoft?". Bletch. Their only redeeming value is that C++ is overly strict about function declaration (even when there is a prototype in scope to make it "do the right thing" -- all information is equally available with both declaration styles), so you can compile the code in a C++ compiler, which should work for normal function declarations as long as there is an in scope prototype (C++ can require this) anyway. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705071754.KAA21604>