peter@sugar.UUCP (Peter da Silva) (07/06/88)
In article <653@osupyr.mast.ohio-state.edu>, vkr@osupyr.mast.ohio-state.edu (Vidhyanath K. Rao) writes: > In article <2244@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > > My personal bitch is with compiler writers that implement part of the draft > > and surprise you. > Can ANSI copyright its name and prevent people from advertising 99.44% > compatibiltiy? I believe that this is done with TeX. > Shouldn't this discussion be moved to comp.languages.c or some such? Yeh, probably. Thing is, said compiler writer didn't advertise ANSI compatibility. They just put the features in as part of what I surmise is a gradual improvement effort. It could be they didn't even get them from ANSI. Oh well... It's a bummer when they put in structure passing without function prototyping, and you accidentally screw up and forget an & in passing a pointer to a structure. If you had function prototyping it'd say "hey, bonehead, you said the function took a pointer". If you didn't have structure passing it'd say "hey, bonehead, you can't pass a structure to a function". Instead it just happily takes the first couple of elements of the structure as a pointer and scribbles on memory. Oh well, I only made that particular mistake half a dozen times. I don't do it much any more. -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to /dev/null. -- "Running DOS on a '386 is like driving an Indy car to the Stop-N-Go"
mcdonald@uxe.cso.uiuc.edu (07/07/88)
> Can ANSI copyright its name and prevent people from advertising 99.44% > compatibiltiy? I believe that this is done with TeX. > Shouldn't this discussion be moved to comp.languages.c or some such? I think you'll find that, when ANSI C becomes real, very, very few people will actually USE real ANSI C compilers. They use the fixed version without trigraphs, with some sort of no-alias perversion, and a few non-standard (i.e. they modify the generated code) pragmas, and with, probably, a bit of name-space pollution. Most compilers will require a special command line switch to get full compatibility with the standard.
karl@haddock.ISC.COM (Karl Heuer) (07/12/88)
In article <225800042@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >I think you'll find that, when ANSI C becomes real, very, very few people >will actually USE real ANSI C compilers. I disagree. I think they'll use Standard-conforming compilers, with extensions (e.g. for POSIX) that don't collide with the Standard. >They use the fixed version without trigraphs, I don't think trigraphs should exist, but given their existence, I see no reason to use a trigraph-ignoring compiler. If I don't use strings that contain trigraphs, it's a moot point. If I (accidentally) do, then my code isn't portable to real ANSI compilers, and fixing that is more important to me than having the compiler silently do what I meant. >with some sort of no-alias perversion, Perhaps. But if it's spelled "#pragma noalias", or even "__noalias", it might still be ANSI. (The jury is still out on this issue.) >and with, probably, a bit of name-space pollution. Whatever for? It's simple enough to avoid. >Most compilers will require a special command line switch to get full >compatibility with the standard. I think I'd make full ANSI the default, and have a special command-line option to get bug-for-bug compatibility (e.g. Reiser cpp). Perhaps you mean that most compilers will require a special option to disable all extensions and compile only strictly conforming programs? Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
mcdonald@uxe.cso.uiuc.edu (07/13/88)
>>and with, probably, a bit of name-space pollution. >Whatever for? It's simple enough to avoid. Backward compatibility. Buyers will scream bloody murder if a vendor's new compiler won't compile programs their old one did. Remember memmove. >>Most compilers will require a special command line switch to get full >>compatibility with the standard. >I think I'd make full ANSI the default, and have a special command-line option >to get bug-for-bug compatibility (e.g. Reiser cpp). Perhaps you mean that >most compilers will require a special option to disable all extensions and >compile only strictly conforming programs? This is exactly what I meant. I am of the understanding that it will be very difficult to come up with "conforming" extensions other than by adding functions that begin with an underscore. Do you mean to say that, for example, added keywords like "far" or "near" or "asm" or "pascal" will be allowed? If Microsoft removed these, their sales would drop to zero overnight. Doug McDonald
karl@haddock.ISC.COM (Karl Heuer) (07/15/88)
In article <225800045@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >>>and with, probably, a bit of name-space pollution. >>Whatever for? It's simple enough to avoid. >Backward compatibility. Buyers will scream bloody murder if a vendor's >new compiler won't compile programs their old one did. Remember memmove. (See below about namespace.) What about memmove? I don't see the connection. >>>Most compilers will require a special command line switch to get full >>>compatibility with the standard. > >>...Perhaps you mean that most compilers will require a special option to >>disable all extensions and compile only strictly conforming programs? > >This is exactly what I meant. I am of the understanding that it will >be very difficult to come up with "conforming" extensions other >than by adding functions that begin with an underscore. Do you mean >to say that, for example, added keywords like "far" or "near" >or "asm" or "pascal" will be allowed? Okay, we have two types of namespace pollution here. I wasn't thinking of non-standard keywords (the compiler I normally use doesn't have any except asm, which I don't use); you're probably right that Microsoft will keep these as a non-conforming extension. It is possible, though, to support additional functions without colliding with the user's namespace. For example, the nonexistence of a read() in ANSI C implies that #include <stdio.h> int read(void) { int n; scanf("%d", &n); return n; } int main(void) { printf("%d\n", read()); return 0; } is a strictly conforming program; an ANSI compiler is obliged to compile it as if it had never heard of the UNIX read() system call. However, int main(void) { char buf[2]; read(0, buf, 2); return (buf[1]); } is a valid UNIX program, which (I claim) can be correctly compiled by a fully- -conforming ANSI C compiler on UNIX (or POSIX). One simple way to do this is to let libc.a have an entry point _sys_read(). Any ANSI functions which require the system call invoke it by this internal name. A separate library libposix.a contains the function int read(int fd, char *buf, int n) { return _sys_read(fd, buf, n); } which the user is allowed to call. When the compiler is invoked with its default options, both libposix.a and libc.a are loaded. For strictly conforming programs, there won't be anything to find in libposix.a. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint ________ For simplicity, I've written the above as if the correct prototype were int read(int, char *, int); which may not be right. I haven't checked the POSIX specs, but I wouldn't be surprised if it uses size_t.
bts@sas.UUCP (Brian T. Schellenberger) (07/20/88)
[tried EMail; it bounced.] Structure passing / returning / assigning and enums predate ANSI by many, many years (I have a copy of a paper descibing those features dated November 15, 1978), so it isn't fair to criticize compiler-writers for introducing these ten-year-old features without the ANSI (less than five-year-old) prototypes. -- --Brian, __________________________________________________ the man from |Brian T. Schellenberger ...!mcnc!rti!sas!bts Babble-On |104 Willoughby Lane work: (919) 467-8000 x7783 ____________________________|Cary, NC 27513 home: (919) 469-9389