rbj@icst-cmr (root) (04/10/86)
> In article <824@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: > > >In article <41@cbmvax.cbmvax.cbm.UUCP>, daveh@cbmvax.UUCP writes: > >> > >>C, LISP, Pascal, BASIC, etc., all have standard built-in functions. > > > >C has standard built-in functions???? > > > >Gee, that's a new one on me. EVERY function called from C is an external > >function, or at least it was when C began. This includes things like write(), > >read(), printf(), math functions, etc. There's no such thing as, for example, > >a C builtin equivalent to the FORTRAN MAX() or the Basic INPUT which does the > >right thing no what the arguments' types are, or where the returned result is > >stored. ... > > That may be the original practice, but the X3J11 (ANSI C) drafts, now quite > clearly say that all functions defined in the library are reserved (ie, you > can't redefine them), and may be builtin to the compiler. I believe that the > /usr/group standard (& probably P1003) reserved every function from all major > UNIX* variants. It may be that redefining these reserved library functions > will continue to work in *YOUR* implementation, but it's not guaranteed. > > Michael Meissner, Data General > ...{ decvax, ihnp4 }!mcnc!rti-sel!dg_rtp!meissner > > *UNIX is a trademark of AT&T in the U.S.A. and other countries. Before I flame at the bogosity of this proposed madness, I will entertain suggestions as to why this decision was made. Fire away. However, most builtin funxions will accept user redefinitions. Will this be allowed, or must we resort to #defines to avoid hacking up the sources to change every funxion we wish to redefine. And will this even work? It's conceivable that the preprocessor could be integrated with the compiler proper and not a separate pass/program in some implementations. On another note, `sizeof' is NOT a builtin funxion. It is merely a funny way of writing an implementation defined constant. ASM *is* a builtin in many implementations. (Root Boy) Jim Cottrell <rbj@cmr>
gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/10/86)
In article <2524@brl-smoke.ARPA> rbj@icst-cmr (root) writes: >Before I flame at the bogosity of this proposed madness, I will entertain >suggestions as to why this decision was made. Fire away. > >However, most builtin funxions will accept user redefinitions. Will this >be allowed, or must we resort to #defines to avoid hacking up the >sources to change every funxion we wish to redefine. And will this even >work? It's conceivable that the preprocessor could be integrated with >the compiler proper and not a separate pass/program in some implementations. In a hosted (ONLY) implementation, some library functions are likely to call on other library functions; if you redefine library functions yourself, you may well break other apparently unrelated library functions. The only relatively safe redefinition would be one with a standard- conforming interface, but then why not just use the one provided? In a free-standing implementation, of course, you can define all your own functions similar to those provided in a hosted environment.
rbj@icst-cmr.ARPA (root) (04/11/86)
Doug Gwyn responds: > In article <2524@brl-smoke.ARPA> rbj@icst-cmr (root) writes: > >Before I flame at the bogosity of this proposed madness, I will entertain > >suggestions as to why this decision was made. Fire away. > > > >However, most builtin funxions will accept user redefinitions. Will this ^^^^^^^^^^^^^^^^^^^^^^^^ > >be allowed, or must we resort to #defines to avoid hacking up the > >sources to change every funxion we wish to redefine. And will this even > >work? It's conceivable that the preprocessor could be integrated with > >the compiler proper and not a separate pass/program in some implementations. > > In a hosted (ONLY) implementation, some library functions > are likely to call on other library functions; if you > redefine library functions yourself, you may well break > other apparently unrelated library functions. The only > relatively safe redefinition would be one with a standard- > conforming interface, but then why not just use the one > provided? > > In a free-standing implementation, of course, you can > define all your own functions similar to those provided > in a hosted environment. Some of us know what we're doing. One sees lots of redefinitions of things like `putc' in {VM,}UNIX code. It is often desirable to use high level funxions (printf) while hacking up a lower level one. While I can appreciate any `help' the compiler/optimizer might offer (converting strcpy's, etc) I damn well demand the ability to force redefinitions of library funxions if I so choose. Interesting! We used to have sed scripts to convert our strcpy's to efficient instruxions. In the future we may have script to go the other way to undo the optimization! (Root Boy) Jim Cottrell <rbj@cmr>
greg@utcsri.UUCP (Gregory Smith) (04/13/86)
In article <2524@brl-smoke.ARPA> rbj@icst-cmr (root) writes: >> That may be the original practice, but the X3J11 (ANSI C) drafts, now quite >> clearly say that all functions defined in the library are reserved (ie, you >> can't redefine them), and may be builtin to the compiler. I believe that the >> /usr/group standard (& probably P1003) reserved every function from all major >> UNIX* variants. It may be that redefining these reserved library functions >> will continue to work in *YOUR* implementation, but it's not guaranteed. >> >Before I flame at the bogosity of this proposed madness, I will entertain >suggestions as to why this decision was made. Fire away. > >On another note, `sizeof' is NOT a builtin funxion. It is merely a funny >way of writing an implementation defined constant. > Many thoughts. First of all, when I read the suggestion that sizeof might be a builtin function, I definitely took that as a gag, and I am tired of reading about why it isn't. Secondly, Jim, you may be interested to know ( if you don't know already ) that, in Britain, the correct spelling of 'connection' is 'connexion'. :-) Why should library functions be reserved? I haven't seen X3J11 so I don't know which or how many functions they are going after, but on the surface it seems a good idea to reserve things like getc and printf and fopen and so forth. It will make it easier to port stuff - but on the other hand, like any standard, it may well stifle improvement. I don't think it would be smart to reserve the whole friggin' library, though - this is just silly. Does this include things like getenv and getppid and symlink that may not have meaning on a non-UN*X system? Suppose you had an OS where getc(f) could be done by sticking f in a register and executing a processor trap. A compiler recognizing built-ins could generate in-line code for this. On related point ( I'll explain why ), do y'all remember "Weird C behaviour"? One of the problems being that printf was being passed the wrong types? Well, lint can't catch this sort of thing because it is told by /*VARARGS*/ to keep its cotton-picken hands off any call of printf. Anyway, in order to check this, it needs to know (1) that printf,fprintf, sprintf are special cases, (2) how to interpret printf format strings. The format may be known only at run-time: printf(fmt_string,...). However, in view of the facts that printf's are frequent, and that mistakes in parameter types are fairly common, and that 95% of printf calls have string constants for formats, I would like to see lint do this. If the format parameter was not a string constant, you would be on your own of course. The following is a borderline case: printf( c<' '|| c>'\176'? "\\%3o":"%c", c); It would probaby be asking too much for lint to recognize what was going on, and then check *both* format strings - but it would be nice. I do the above sort of thing once in a while. Anyway, so whaddya think? Of course, the same sort of thing can be done for scanf - although this is used less commonly. If 'printf' and friends were to become *quote* built-in *unquote* functions, this addition to lint would be even more justified. Can you imagine redefining printf and then having lint tell you that your format string was out to lunch? Now for something completely different... From: g-rh@cca.UUCP (Richard Harter) > Grumble, grumble. Sorry, this is a real practical problem. > Let me give some context. Suppose you are doing a high speed > sort of character strings. Being a clever fellow you have > read the glossed over parts of the literature and have seen > that a math sort is O(n) rather than O(n log n). You also > notice that it is cheaper to compare 4 bytes at once with > an 32-bit integer compare than to make 4 byte compares. I'm not sure on this - isn't it ridiculous to do a mathsort of 32-bit ints? In O(n) above ( for the mathsort) doesn't n become 2^32 rather than the list size? If so, it would of course be even sillier for larger ( i.e. reasonably-sized ) char strings. 'Bye for now... -- "If you aren't making any mistakes, you aren't doing anything". ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg
faustus@cad.UUCP (Wayne A. Christopher) (04/15/86)
In article <2564@brl-smoke.ARPA>, rbj@icst-cmr.ARPA (root) writes: > Some of us know what we're doing. One sees lots of redefinitions of > things like `putc' in {VM,}UNIX code. It is often desirable to use > high level funxions (printf) while hacking up a lower level one. Of course, you realize that redefining putc will have no effect on printf... Wayne
greg@utcsri.UUCP (Gregory Smith) (04/16/86)
In article <170@cad.UUCP> faustus@cad.UUCP (Wayne A. Christopher) writes: >In article <2564@brl-smoke.ARPA>, rbj@icst-cmr.ARPA (root) writes: >> Some of us know what we're doing. One sees lots of redefinitions of >> things like `putc' in {VM,}UNIX code. It is often desirable to use >> high level funxions (printf) while hacking up a lower level one. > >Of course, you realize that redefining putc will have no effect on printf... > > Wayne The above statement is non-portable, isn't it? If the new standard says that putc() has to be a macro, then I'm wrong but.. If (a) putc is a real function and (b) printf calls it, then printf will be affected by a redefinition of putc. And (a) almost implies (b). This weirdness seems to be a plus point for reserving any library functions that may or may not be macros. -- "If you aren't making any mistakes, you aren't doing anything". ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg
gwyn@BRL.ARPA (04/18/86)
Actually, whether redfining putc() affects printf() or not is implementation-dependent. This reinforces the point that users should not redefine standard library functions.
rbj%icst-cmr@smoke.UUCP (04/18/86)
In article <2564@brl-smoke.ARPA>, rbj@icst-cmr.ARPA (root) writes: > Some of us know what we're doing. One sees lots of redefinitions of > things like `putc' in {VM,}UNIX code. It is often desirable to use > high level funxions (printf) while hacking up a lower level one. Of course, you realize redefining putc will have no effect on printf... Wayne Silly me! I *axually* believed the UNIX documentation! I quote from man 3 printf: ... Characters generated by printf are printed by putc(3S). Well, that may have been once true, and the effect is mostly the same. Okay, so I picked a bad example. Lets go one level up. I could redefine printf to remove all that floating point stuff I don't want or need, and maybe add a few formats of my own (You hear a faint cry of anguish (about portability) in the background). THEN, I am free to redefine putc, perhaps to print unprintable chars as ^X for control X, etc. In fact I did this to `more'. Thanx for setting me straight (Root Boy) Jim Cottrell <rbj@cmr>
zben@umd5.UUCP (04/19/86)
>>> Some of us know what we're doing. One sees lots of redefinitions of >>> things like `putc' in {VM,}UNIX code. It is often desirable to use >>> high level funxions (printf) while hacking up a lower level one. >> Of course, you realize redefining putc will have no effect on printf... > I could redefine printf to remove all that floating point stuff I > don't want or need, and maybe add a few formats of my own (You hear > a faint cry of anguish (about portability) in the background). > THEN, I am free to redefine putc, perhaps to print unprintable > chars as ^X for control X, etc. In fact I did this to `more'. At first blush one might think this a very lazy thing to do. Pity the poor dude who gets this program after you leave - and has to deal with one of the inter-library-routine calling sequences subtly shifting in 4.7 BSD*. If you're going to redefine the world, what's wrong with 1,$s/putc/myputc/g and 1,$s/printf/myprintf/g and be done with it - then the fact that you have hacked things up is "manifestly obvious". *This is an out-of-the-hat example - do *NOT* write me asking for distapes. -- "We're taught to cherish what we have | Ben Cranston by what we have no longer..." | zben@umd2.umd.edu ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben
david@ukma.UUCP (David Herron, NPR Lover) (04/21/86)
In article <2554@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes: >In article <2524@brl-smoke.ARPA> rbj@icst-cmr (root) writes: >>... >... >On related point ( I'll explain why ), do y'all remember "Weird C >behaviour"? One of the problems being that printf was being passed the >wrong types? > >Well, lint can't catch this sort of thing because it is told by >/*VARARGS*/ to keep its cotton-picken hands off any call of printf. >Anyway, in order to check this, it needs to know (1) that printf,fprintf, >sprintf are special cases, (2) how to interpret printf format strings. >The format may be known only at run-time: printf(fmt_string,...). >However, in view of the facts that printf's are frequent, and that mistakes >in parameter types are fairly common, and that 95% of printf calls have >string constants for formats, I would like to see lint do this. If >the format parameter was not a string constant, you would be on your >own of course. ... Ok, there *is* a way to do this. One of the europeans (that guy that had been doing Hack) posted a tool for aiding lint last year sometime. It read through C programs looking for printf() calls. It looked at the format string and for the associated arguments it inserted a function call, something like: int retint(i) int i; { return i; } /* ... more similar functions ... */ f() { ... printf("i is %d\n", retint(i)); ... } Now, if i is not an int then lint will know that it should be and bitch. Also the retint() calls can be gotten rid of with: #define retint(i) (i) >... The following is a borderline case: > > printf( c<' '|| c>'\176'? "\\%3o":"%c", c); I dunno what it would do with this case... One thing that occurs to me... do char's always get casted to ints when they're arguments to functions????? -- David Herron, cbosgd!ukma!david, david@UKMA.BITNET, david@uky.csnet
rbj@icst-cmr.ARPA (root) (04/22/86)
> From roger@ll-sst Sun Apr 20 15:31:29 1986 > > In article <2564@brl-smoke.ARPA>, rbj@icst-cmr.ARPA (root) writes: > > Some of us know what we're doing. One sees lots of redefinitions of > > things like `putc' in {VM,}UNIX code. It is often desirable to use > > high level funxions (printf) while hacking up a lower level one. > > Of course, you realize redefining putc will have no effect on printf... > > Wayne > > > Silly me! I *axually* believed the UNIX documentation! I quote from > > man 3 printf: > > > > ... Characters generated by printf are printed by putc(3S). > > "*Axtually* the documentation is correct!" [The sound of one defending > sacred writ from the unfaithful.] But, well, it's true. Printf does > call putc, but [I quote from man 3 putc]: > > ... BUGS > Because it is implemented as a macro, \fIputc\fR ... > > [a great place to find it documented, no?] and, better, but still not > in a place it will jump out at you, [man 3s intro]: > > ... The in-line macros \fIgetc\fR and \fIputc\fR(3S) handle characters > quickly. The higher level routines [list including printf] all use > \fIgetc\fR and \fIputc\fR ... > > Once putc has been expanded in-line, redefining it elsewhere won't have > full effect. Just as in your better example, you'd have to recompile > printf (and then where's portability? ...). > > Yrs, Roger <roger@ll-sst.arpa> Silly me! I *axually* goofed! I got confused between `putc' and `putchar', which altho defined as a macro, is also a real funxion as well because it predated the stdio library. Sigh. Allow me to start from square one and appeal to the higher principles I was attempting to demonstrate by my errant example. I don't want the compiler taking the liberty of expanding ANY funxions inline unless I direct it do do so via a macro or some kind of #pragma that specifys inline expansion! Compilers DO NOT know about specific funxion calls! Someone suggested that `putc' could put the char into a register and make a system call. So could `putc.s'. As for portability, I SUPPLIED the funxion with my code, so it does EXACTLY what I say it does. If it is legal portable C, it ports! As to my friend Ben Cranston's suggestion that I should use `myprintf' and `myputchar', this is a very good idea, lest we forget what the funxion really does. However, this may not always be an option where objects but no source is available. Hiya Ben! (Root Boy) Jim Cottrell <rbj@cmr> "One man gathers what another man spills"
zben@umd5.UUCP (Ben Cranston) (04/24/86)
In article <205@brl-smoke.ARPA> rbj@icst-cmr.ARPA (root) writes: >As to my friend Ben Cranston's suggestion that I should use >`myprintf' and `myputchar', this is a very good idea, lest we >forget what the funxion really does. However, this may not always >be an option where objects but no source is available. Hiya Ben! Oh, good, I had so hoped you would not be offended by my implicit criticism of your earlier posting. I had taken precautions against my being taken too seriously, but the postnews software removed my precaution from the header of the message: Organization: Great Eastern Cow College Home for the Terminally Analytical Remember, "When Source is outlawed, only outlaws will have Source"... > (Root Boy) Jim Cottrell <rbj@cmr> -- "We're taught to cherish what we have | Ben Cranston by what we have no longer..." | zben@umd2.umd.edu ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben
Unknown@hplabs.UUCP (04/25/86)
This message is empty.
guido@boring.uucp (Guido van Rossum) (04/25/86)
In article <3186@ukma.UUCP> david@ukma.UUCP (David Herron, NPR Lover) writes: >>[plea for lint to check printf formats] >Ok, there *is* a way to do this. One of the europeans (that guy that >had been doing Hack) posted a tool for aiding lint last year sometime. >[rough explanation of the idea] This code is still available; I can mail it to interested parties. The author is called Andries Brouwer (and currently not at our institute but in Denmark). I've also heard that system 5 lint has this built-in; there's even a directive /*PRINTFLIKE*/ so you can define your own. >>... The following is a borderline case: >> printf( c<' '|| c>'\176'? "\\%3o":"%c", c); >I dunno what it would do with this case... It gives up here. There is a limit to what you can check. >One thing that occurs to me... do char's always get casted to ints >when they're arguments to functions????? Yes, definitely. And so do shorts. This is supposed to be standard knowledge amongst posters to this group! (At least posters that answer questions.) -- Guido van Rossum, CWI, Amsterdam <guido@mcvax.UUCP>
herndon@umn-cs.UUCP (04/25/86)
I feel compelled to go on record as being VERY MUCH AGAINST having reserved procedure names in C. For those of us who have ever written stand-alone code for PDP-11s, VAXen, ..., it is a simple matter, as things stand, to compile our programs, and then have them linked with our own versions of 'putc', 'read', etc. stashed in stand-alone libraries. One of the (in my opinion) great strengths of the C language is that it does not have 'built-in' functions. As a result, it has somehow managed to avoid the imbroglio that Pascal has gotten into. If one user doesn't like the interface that 'printf' provides, or a whole bunch of users don't, they are free to write their own functions and use those instead. In addition, porting the C compiler to a different OS on the same machine only requires that the libraries be re-written (almost always). Building those functions into the language implies that there will be much code for special casing those functions. On the flip side, the language may not be as efficient. If the compiler writers want to allow these procedures to be built-in to allow in-line procedures, I think this should be an option (DEFAULT=OFF), and then the capabilities of the language will be compromised as little as possible.
mjs@sfsup.UUCP (M.J.Shannon) (05/01/86)
In article <1700010@umn-cs.UUCP> herndon@umn-cs.UUCP writes: > > I feel compelled to go on record as being VERY MUCH AGAINST >having reserved procedure names in C. For those of us who have >ever written stand-alone code for PDP-11s, VAXen, ..., it is >a simple matter, as things stand, to compile our programs, >and then have them linked with our own versions of 'putc', >'read', etc. stashed in stand-alone libraries. > ... >In addition, porting the C compiler to a different OS on the >same machine only requires that the libraries be re-written >(almost always). Building those functions into the language >implies that there will be much code for special casing those >functions. Nowhere is it required that the compiler have any special knowledge of the reserved names in the library. Yes, *some* compilers will undoubtedly have *some* special knowledge of *some* of those names, but the ANSI spec does *NOT* *require* the compiler to know anything about any reserved library names. Please, do NOT flame about statements that are not made in the spec. There are enough statements that ARE made in the spec that may be worth flaming about (although I hope that rational discusssion, rather than flames, result). If you don't have a copy of the current state of the proposed standard, GET ONE! I'm sure that any number of members of the committee (many of whom read this newsgroup) can either provide the proper procedure for obtaining it, and possibly an official copy. (I don't have this information, so please don't reply to me for it. Perhaps Larry Rosler can repost the appropriate information.) Marty Shannon UUCP: ihnp4!attunix!mjs Phone: +1 (201) 522 6063 Disclaimer: I speak for no one. "If I never loved, I never would have cried." -- Simon & Garfunkel -- Marty Shannon UUCP: ihnp4!attunix!mjs Phone: +1 (201) 522 6063 Disclaimer: I speak for no one. "If I never loved, I never would have cried." -- Simon & Garfunkel
gwyn@BRL.ARPA (VLD/VMB) (05/02/86)
X3J11 was not proposing to permit built-in functions in a stand-alone conforming C implementation. They would be permitted in a hosted implementation, however.
franka@mmintl.UUCP (Frank Adams) (05/03/86)
In article <1700010@umn-cs.UUCP> herndon@umn-cs.UUCP writes: > On the flip side, the language may not be as efficient. >If the compiler writers want to allow these procedures to >be built-in to allow in-line procedures, I think this should >be an option (DEFAULT=OFF), and then the capabilities of >the language will be compromised as little as possible. I agree that if one is going to consider certain functions as built-in, there should be an option to make them external calls, instead. I don't agree that the default should be to make them external. Most users are interested in the efficiency; the additional effort, however much it is, should be put on the smaller group. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
grr@cbmvax.cbm.UUCP (George Robbins) (05/04/86)
In article <498@brl-smoke.ARPA> gwyn@BRL.ARPA (VLD/VMB) writes: >X3J11 was not proposing to permit built-in functions in a >stand-alone conforming C implementation. They would be >permitted in a hosted implementation, however. Are you sure that the X3J11 committee hasn't been infiltrated by unsatiated ADA persons? :-) This business of including the runtime routines in the language standard brings out an awful log of worried frowns on the faces of knowledgeable c/unix people. Look at the problems that the Pascal and Modula2 people are having with their 'offical' runtime routines/libraries... To minimize this criticism, the committee seems to be making a big distinction between hosted and non-hosted environments that doesn't map well into the real world. Most of the people trying to develop compilers for non-unix microcomputer operating systems are trying to be as unix-like as possible, but just can't make all the way because of operating system brain damage. I would be much happier if there were two separate documents, so that a vendor could clearly say that his compiler is fully X3J11 conforming, and his runtime support conforms to XJXXX with the following exceptions. One of the better things to come out of the COBOL standards efforts was the notion of specifying a minimum core language, then defining optional modules that were pretty close to the way the big boys (IBM) had actually implemented their extensions. This makes it fairly easy for a vendor to communicate to a user just what his compiler supports. -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/05/86)
In article <182@cbmvax.cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >To minimize this criticism, the committee seems to be making a >big distinction between hosted and non-hosted environments that >doesn't map well into the real world. Most of the people trying >to develop compilers for non-unix microcomputer operating systems >are trying to be as unix-like as possible, but just can't make >all the way because of operating system brain damage. Although based on a subset of the UNIX implementation, the X3J11 hosted C specification does not require support functions that cannot be implemented on almost any popular operating system. For example, I am sure that a conforming hosted implementation is possible on my Apple //e. There aren't many more primitive systems than that! >I would be much happier if there were two separate documents, so >that a vendor could clearly say that his compiler is fully X3J11 >conforming, and his runtime support conforms to XJXXX with the >following exceptions. "Exceptions" are pointless when the hosted runtime support is implementatble on essentially every system. All the library functions pertain to the hosted environment only. Only the "raw" C language is required in the stand-alone environment. It didn't take X3J11 long to agree that it was as important to standardize the hosted environment library functions as to standardize the raw language. I think that is essential; most C porting problems I've encountered have been library and header interface incompatibilities, not raw language problems. >One of the better things to come out of the COBOL standards efforts >was the notion of specifying a minimum core language, then defining >optional modules that were pretty close to the way the big boys (IBM) >had actually implemented their extensions. This makes it fairly >easy for a vendor to communicate to a user just what his compiler >supports. That is easier for a language with built-in I/O facilities. In the case of C, either an implementation is a conforming hosted ditto or it is a conforming stand-alone ditto (no library functions) or it is nonconforming. That's about the right number of levels as far as I am concerned. There's no need for more (although it would be nice to have standardized library additions for a variety of things; however, the X3J11 document describes the minimum useful language, not a superset of everybody's wish lists).
henry@utzoo.UUCP (Henry Spencer) (05/06/86)
> One of the better things to come out of the COBOL standards efforts > was the notion of specifying a minimum core language, then defining > optional modules that were pretty close to the way the big boys (IBM) > had actually implemented their extensions... Whether this is a good idea or not is very much a matter of opinion. As I recall, X3J11 representatives said at the very beginning that they had explicitly renounced this approach, because there are something like 4096 distinct languages that meet the COBOL "standard", and this is a real obstacle to portability. In practice, of course, what happens is that implementations converge on a few widely-agreed preferred points in this large space of possibilities. So why not identify those points in advance? Maybe one could even... pick just one of them! This is what X3J11 is trying to do, although it looks like it's ending up as 1.5 rather than 1.0. -- Join STRAW: the Society To Henry Spencer @ U of Toronto Zoology Revile Ada Wholeheartedly {allegra,ihnp4,decvax,pyramid}!utzoo!henry
rbj@icst-cmr (Root Boy Jim) (05/08/86)
In article <1700010@umn-cs.UUCP> herndon@umn-cs.UUCP writes: > > I feel compelled to go on record as being VERY MUCH AGAINST >having reserved procedure names in C. For those of us who have >ever written stand-alone code for PDP-11s, VAXen, ..., it is >a simple matter, as things stand, to compile our programs, >and then have them linked with our own versions of 'putc', >'read', etc. stashed in stand-alone libraries. > ... >In addition, porting the C compiler to a different OS on the >same machine only requires that the libraries be re-written >(almost always). Building those functions into the language >implies that there will be much code for special casing those >functions. Nowhere is it required that the compiler have any special knowledge of the reserved names in the library. Yes, *some* compilers will undoubtedly have *some* special knowledge of *some* of those names, but the ANSI spec does *NOT* *require* the compiler to know anything about any reserved library names. Please, do NOT flame about statements that are not made in the spec. There are enough statements that ARE made in the spec that may be worth flaming about (although I hope that rational discusssion, rather than flames, result). He didn't say it would be *required*. Neither did I. We don't want it even allowed, unless we can turn it off. I would even go one step further and require that you explicitly turn it on for each function. If you don't have a copy of the current state of the proposed standard, GET ONE! Yeah, fork over another $20 for an out-of-date copy. Possibly the one you already have. They should be free, posted to net.sources, and distributed by the NIC or some such. See quote at end of article. Marty Shannon UUCP: ihnp4!attunix!mjs Phone: +1 (201) 522 6063 Disclaimer: I speak for no one. "If I never loved, I never would have cried." -- Simon & Garfunkel "Well I've paid all the dues I want to pay" -- S & G (Root Boy) Jim Cottrell <rbj@cmr> "One man gathers what another man spills"