Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!gatech!darwin.sura.net!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!cbnewsc!cbfsb!att-out!pacbell.com!decwrl!world!ksr!dean From: dean@ksr.com (Dean Anderson) Newsgroups: comp.unix.bsd Subject: Re: 386BSD's non-standard C library Message-ID: <16591@ksr.com> Date: 6 Oct 92 18:12:03 EDT References: <1992Sep24.031603.21009@minyos.xx.rmit.oz.au> <id.58NT.RE4@ferranti.com> <rcskb.718045970@minyos.xx.rmit.OZ.AU> Sender: news@ksr.com Organization: Kendall Square Research Lines: 118 In article <rcskb.718045970@minyos.xx.rmit.OZ.AU> rcskb@minyos.xx.rmit.oz.au (Kendall Bennett) writes: >Oh? That is my problem? I assume that since this is a new standard (first >proposed back in what - 1983?), and it is not supported on all systems The standard was not accepted until 1989 or so. My unapproved draft copy is dated December 1988. >I should not use it, but write my code in pre-historic K&R C with lotsa >#defines since non K&R system is ever comapatable with another? If you want to be portable(ie, run on lots of systems), this is what you have to do. Maybe you should just stick with DOS. There are a lot of those systems. >Well I hate to inform you, but this is the totally wrong approach. I >write all of my C code so that it is ANSI conforming, and any UNIX >stuff I write I try to make it POSIX conforming. Now if it so happens >that my code does not run on your system because your compiler and >runtime library and ancient - well you will simply have to update you >compiler and runtime library. Go ahead and write ansi and posix only code. It will be a while before it will run on vast numbers of systems. I personally don't like ansi C because it violated its charter to document the existing language as a standard. I don't think that all the decisions were correct, and I don't think the community was permitted to test out the ideas well enough. Innovation by committee usually produces very bad results. >Take a look at the code for the GNU standard C library. It is written >to work under K&R C compilers, and I pity having to write code like this. >But I shouldn't have to. Once you have and ANSI C compiler (like gcc) >and an ANSI C runtime library up and running, you wont need to resort >to this type of code. Appropriate header files have taken care of most of the problems I have encountered using K&R and ansi systems. The point here is that not everyone has an ansi compiler. Very little code will work with an exclusively ansi compiler. Some people cannot have both -traditional and -ansi built into their compiler. >>Not shortcuts, exactly. The library *predates* the standard. For example, >>the ANSI standard changed the behaviour of tolower for most compilers. > >Well, you see the runtime library has the __STDC__ and __POSIX_SOURCE >macro definitions all over the place - this made me assume it was >attempting to be ANSI/POSIX conformant. Condidering that the implemenation >of tolower in the 386BSD library does not match what the man pages say, >how an I to know without looking at the code that the rest of the >library does what it is supposed to do? Things are moving towards ansi C and posix. It will not happen overnight. In the meantime, things have to be added in non-destructively. >>Portable code should be written in the expectation that there are still >>a lot of old compilers out there. The portable version of your code is: > >I'll leave this type of 'portable' coding up to you - me, I'll stick to >the standards and wait for the vendors to get with it. > >>Anyone with pretentions of writing portable code should be forced to port >>their code to (say) Xenix-286. > >Ha ha. Why not make people who write UNIX apps port their code to run >under MSDOS? Nice and segemented like Xenix-286. That is what ansi C and posix is for. Someday, it will happen. It hasn't yet though. >>Fix your code. Run lint over it until it lints clean. > >This is something I have never been able to do. I do most of my >development under MSDOS, since the best programming development >systems I have ever used run under MSDOS. Good DOS compilers like >Borland C++ will pick up just about anything lint will pick up, and >you dont need to put horrible #ifdef lint and (void)printf(...) stuff >throughout your code just so lint wont barf. Well, perhaps you should develop under unix and port to Dos. This is easy since dos supports ansi C and posix, right? ;-) It should just compile ;-) >Sometimes I really wonder when the UNIX world will catch up with >the technology that is currently available on DOS based systems for >program development. Believe me, integrated development environments >are incredibly usedful when you are trying to _teach_ people about >programming, allowing students to actually hand execute code interactively >watching how things change. I have yet to see anything that comes >anywhere near as close on UNIX platforms... I guess you haven't seen saber-C and ups, xdbx, gdb (are there more?). As for teaching, I thought UCSD pascal on the mac was pretty cool and it was way before anyone else. The problem you fail to see is that every time someone innovates, they become different from the people around them. You won't get very far with a POSIX and ansi C only program. At least, not without reinventing a lot of what has already been invented by others but not standardized. Avoiding reinventing the wheel is what engineering is all about. Unfortunately, it takes time to determine the value of a tool and which way works best in what situations. Standards can substantially break the engineering process by picking bad solutions and then forcing it upon everyone. Writing portable code requires that one understand this and have knowledge about all the competing ways to do various things. It has very little to do with using a standard. On the other hand, perhaps you should stick with MSDOS. Have fun storming the castle! --Dean -- Dean Anderson dean@ksr.com | I'm not voting because the KSR Computing Facilities | lack of a candidate has Kendall Square Research | co-opted me out of the process