Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!uunet!zaphod.mps.ohio-state.edu!rphroy!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Newsgroups: comp.unix.bsd
Subject: Re: 386BSD's non-standard C library
Message-ID: <1992Oct2.210133.3625@fcom.cc.utah.edu>
Date: 2 Oct 92 21:01:33 GMT
References: <1992Sep24.031603.21009@minyos.xx.rmit.oz.au> <id.58NT.RE4@ferranti.com> <rcskb.718045970@minyos.xx.rmit.OZ.AU>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
Lines: 144
In article <rcskb.718045970@minyos.xx.rmit.OZ.AU> rcskb@minyos.xx.rmit.oz.au (Kendall Bennett) writes:
>peter@ferranti.com (peter da silva) writes:
>
>>It is. It's a standard K&R library.
>
>Well if it is, it is pre-historic.
>
>>Ah. That's your problem. You're using a newer standard.
>
>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
>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?
This is why you should always program in a subset of the features of C.
Bad assumptions (like not looking at library documentation, structure
packing order, bit fields, order of operation for expressions as parameters
to functions, and the option base for enumerated types) lead to bad programs.
Contrary to the people worried about benchmarking and having to have the
compiler know about the hardware it's on, ANSI only solved problems for
compiler writers; it creates problems for compiler users.
I can give you pages and pages about the incompatabiliteis between the
"ANSI compliant" compilers and "POSIX compliant" libraries and their
incompatabilities on AIX, SunOS 4.1.2, Solaris 2.0, SVR3, and SVR4.
>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.
Adherence to standards to insure a minimum *required* functionality is
not a bad thing; but instead of shooting for ANSI and POSIX conformance,
I like my code to run. Everywhere. Most people realize that in the real
world, not everyone can afford or chooses to buy new tools or OS revisions
the day after they come out. If you work long enough, you will wil probably
see equipment and software old enough to curl your toes.
>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.
I dare you to run you "ANSI compliant/POSIX compliant" after compiling it
(if you can get it to compile) on "ANSI Certified" VAX/VMS C on "POSIX
compliant 'Open VMS'". I'm betting it won't run ot it's trivial or both.
.
>>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?
You don't. Don't "buy" 386BSD if you don't like it. As bugs are reported,
people like Peter and myself will fix them. The only thing "__STDC_"
implies to me is that it will compile with at most warnings on an ANSI
compiler. Nothing else. The "__POSIX_SOURCE" mans that the author tried
to conform to POSIX. Nothing else. For a good laugh, tell me what happens
in POSIX 1003.1-1988 when a process recieves two SIGCLD signals while in
the signal handler beacause of a previous SIGCLD. Looks pretty ambiguous
to me.
>>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.
Have fun using you one chosen compiler under DOS, with all those "portable"
"near" and "far" calls...
>>Anyone with pretentions of writing portable code should be forced to port
>>their code to (say) Xenix-286.
Here here! ...Actually most of my code *should* still run there with only
minor changes. As I'm sure Peters probably will as well.
>Ha ha. Why not make people who write UNIX apps port their code to run
>under MSDOS? Nice and segemented like Xenix-286.
No challenge. Any Quiche-eater can program for an "OS" where you own
the machine.
>>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.
Suprise! The "horrible void" requirement came from ANSI where they thought
it might be nice to optimise the parameter passing mechanism without having
to update neanderthal linker technology. The only "#ifdef LINT" (hmmm..
your "lint" is lower case -- could this be the problem?) problem I ever
run into is the "sccs_id" string not beinmg used in the scope of a module.
As far as tools go, I haven't seen *anything* in the DOS worlds to compare
to "Codecenter", "Battlemap", "SCCS", "CVS","Softbench" and the other myrid
of software engineering tools under UNIX. IDE and Cadre Technologies both
have *very* nice packages (sorry; I forget their names).
>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...
CodeCenter (formerly Sabre-C) does precisely this.
I have to tell you that I'd have a problem hiring someone who'd only
done DOS developement. I've actually had people like this come to me for a
job and I had to turn them away as unqualified. The majority of the jobs
today are in multitasking environments (like UNIX) or pseudo-multitaking
environments (like MS-Windows). One learning environment with no real
obstacles is just not real-world.
Sorry, but what Microsoft did to my favorite computer language is a
soapbox of mine. 8-).
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------