On Wed, 13 Dec 1995, Tel Janin Aellinsar wrote: > > Well if your compiler purports to be an ANSI compiler and supports some > > other operator presednce then it is broken and you should complain > > to the vendor. Do you want to claim that because some compilers are > > broken you can't write ansi complient code? > > > > No, I want to claim that some compilers support "extensions" that you > have to shut off to get anything even remotely ANSI-complaint. Of > course, there is the occasional broken compiler, too. From what BCC > says, and I mostly agree, there are four style: Kerighan and Ritchie, > however their names are spelled; ANSI C; UNIX C; and "everything > else." K&R C is not, AFAIK, ANSI C, and UNIX C sure as hell ain't ANSI > C. That isn't bad, because the ANSI C standard doesn't include some > things that it should. What shall UNIX C be? There is no such thing. You'll encounter similar library functions on different unix machines, maybe more similar than libraries on other platforms, but thats it. There's the old K&R I standard, which still is used by some compilers, but modern machines, should have an ANSI C compiler available too, after all this standard exist long enough now. Even Kernighan & Ritchie describe ANSI-C in the 2nd edition of their book "The C Programming Language". ANSI-C was just a more or less logical development of the original C language by K&R. That isn't bad, because the ANSI C standard doesn't include some > things that it should. hmm, name one. =) (Btw. please reply to that special question by private mail, since this is really off topic) > > I'll admit that vendors tend to vary in how they handle "undefined" > > behaviour and yes you will run into problems if you get in the habit > > of passing null pointers to strcmp etc. because the DEC compiler let you. > > > > Well, I've never used a DEC compiler, but using pointers under DOS can > sure get messy unless you're careful or use a 32-bit compiler. Why not just use a 32-bit compiler then? :) Not too many people with less than a 80286 nowadays i think. On Wed, 13 Dec 1995, Edward Almasy wrote: > This is ridiculous. I've been writing strict ANSI-compliant code with > gcc for the last five years, and I have yet to run into any code that > doesn't behave under gcc as dictated by the ANSI spec. > > If you write ANSI-compliant code then 99.99999% of the time your code > will compile fine under gcc or any other ANSI-compliant compiler. If > you don't agree with this then please cite an example of (normal MUD) > code where this isn't true. Certainly nothing I've seen in the current > discussion falls into this category. Why limit this to normal MUD code? Feel free to show me any ANSI C code, that doesn't compile under gcc. (Actually if you find such a beast, we can crosspost this to the gnu guys as a bug report. :-) ) Ok, ok this is a mud list, so if you have a nonmud piece of code, mail me directly, instead of mailing here. :-) > Discouraging novice C programmers from trying to adhere to the ANSI C > standard does everyone here a disservice. Yep, thats the reason why writing here, instead of private mail. (Feel free to stop me know, if you think thats not a good idea though. =) ) My advice. Use ANSI as long as possible. If not possible, or by some special reason not practical, use POSIX next. Use machine dependand code only if other things fail, or lead to bad code for some reason. Of course a mud can't be fully ANSI anyway, so as always in programming, there's more than one way to do something. As a counterexample, i think it's ok to assume int as 32 bit on any dikumud, even if ANSI only guarantees 16 bit. There are much more such examples, so don't stick on what i saied above. :-) Herbert __ [on public request 12 lines of signature deleted] *snip* ;)
This archive was generated by hypermail 2b30 : 12/07/00 PST