Xref: utzoo comp.lang.misc:6126 alt.lang.cfutures:292 Path: utzoo!utgpu!cs.utexas.edu!sdd.hp.com!usc!apple!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!tuvie!vmars!hp From: hp@vmars.tuwien.ac.at (Peter Holzer) Newsgroups: comp.lang.misc,alt.lang.cfutures Subject: Re: Changes to C... Message-ID: <2010@tuvie> Date: 21 Nov 90 15:54:51 GMT References: <1990Nov18.033622.1517@murdoch.acc.Virginia.EDU> <1990Nov20.220526.24202@ingres.Ingres.COM> <1990Nov21.020928.13858@murdoch.acc.Virginia.EDU> Sender: news@tuvie Followup-To: comp.lang.misc Lines: 73 gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) writes: >What does C need? Well, if I could declare that a, b, c, and d were >arrays of size n, the compiler would have all the info it needs to do >a *simple* run-time check for aliasing, no matter how nasty the index >expressions are. Should that look like foo( float a[n], float b[n], float c[n], float d[n], int n ) ? Neat idea. Although it will promote the pointer/array confusion even further. It is already hard enough to explain to C-beginners why `int f (int * a)' is the same as `int f (int a [])' but `extern int * b' is not the same as `extern int b []'. IMHO argument rewriting should be abandoned in some future version of C (together with old-style declarations and definitions) > And it would optionally be able to insert >bounds-checking, should I want it. Some compilers (e.g. Saber C) do that even now. I suppose every pointer is really a tripel (address, lowest valid address, highest valid address) to them. >Of course, I'd also want true N-dimensional arrays In what sense are C arrays not true n-dimensional? >and a stronger >library. Me too. Especially file, process and exception handling is rather weak. I understand that the people working on the standard wanted to create the greatest common denominator, but there should at least be a set of optional functions defined for rather common actions as * changing the working directory, * executing another program, * disable specific exceptions (FP overflow comes to mind), * indexing files (IMHO one of the main reasons why COBOL is still successfull is the fact that it has STANDARDIZED indexed files). Apart from that many library functions do not quite what you want (eg. strncat) or are not consequent in their parameter ordering (The stdio family). >library. This is only a first step. The major question is: would you >end up with a simple language at the end? I hope that the end product >would be easier to optimize, but it would certainly be bigger than >before. There were K&R-C compilers that ran perfectly well in 64k Text and 64k Data+Stack. GCC already needs a few megabytes. >> The real solution >>is to start over and design something you feel solves the problems you >>encounter or corrects percieved deficits with C. >I'm stuck using lots of machines, and it would be expensive for me to >write compilers for all of them. Your real solution is great for >research, but not so great if you're an end-user. Extending C is not easy either. Whenever I write a C program people come running complaining that they cannot compile it. Most compilers called 'cc' are not C compilers nowadays, but compile the language that was called C 10 years ago. I do not expect non-conforming compilers to disappear for at least another 5 years (We will probably have the next standard by then so there won't be any conforming compilers again :-) -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |