Path: utzoo!utgpu!water!watmath!clyde!rutgers!ukma!gatech!mcnc!decvax!decwrl!sun!pitstop!sundc!seismo!uunet!nuchat!sugar!peter
From: peter@sugar.UUCP (Peter da Silva)
Newsgroups: comp.lang.c
Subject: Re: A bad design decision early on in ANSI C.
Message-ID: <1373@sugar.UUCP>
Date: 7 Jan 88 12:51:57 GMT
References: <1322@sugar.UUCP> <1942@ho95e.ATT.COM>
Organization: Sugar Land UNIX - Houston, TX
Lines: 54

In article <1942@ho95e.ATT.COM>, wcs@ho95e.ATT.COM (Bill.Stewart) writes:
A bit about how taking this stuff out would break programs. I agree, so
it's too late to go back... let's go forward.

> 1) If you mess up a function call (add/delete &) you've got a real mess.
> 	True, but this is what "lint" is good for.  Actually, it's safer
> 	to mess up one of these than a more normal variable, because
> 	the results are so ugly you'll *probably* notice them.

Yes, the usual result on anything but a good protected operating system like
UNIX is a complete system crash.

> 2) Sometimes your stack overflows if you use them.
> 	Only if the program was too big for the machine anyway.  While
> 	the ability to pass structures encourages people to put more on
> 	a stack than necessary, it's easy to see what they've done and
> 	modify it if your machine is too small.  Does your machine have
> 	a big data space but a 64K stack size, or are mallocs just as unsafe?

It's sad but true that personal computers don't usually have automatically
expanded stack frames. You need hardware that can recover from page faults
to implement this... in fact there exist micro-based UNIX boxes that don't
give you this ability.  My machine has 4.5 megabytes of RAM in it, but I have
to keep in mind that if I go over 4K of stack I have to take special
precautions like increasing the stack size dynamically or telling the machine
to increase its default stack size.

> 3) They don't really add anything.
> 	But they do - they add data hiding.  A library can provide
> 	types such as time_t and addr_t for data that is generated by
> 	some library routines and used by others, and *you* don't have
> 	to know what the type is.  If the variable won't fit in a
> 	scalar on your machine (either because it's too big, or because
> 	you've got a segmented architecture or perverse operating system),
> 	and you've disallowed structure assignment, *you* may have to
> 	know what the structure looks like inside.

If you want to do *anything* but pass these values around or assign them you
still have to know what they look like. Ah, you say, you can always call
a library routine to compare them... but you can also call a library routine
to copy them and pass pointers. IF you're going to have structure assignment
and passing, you should also define "(time_t) < (time_t)". It's tricky, isn't
it? 

But if you're going to do a job, you should do it right.

So, what's the point? The point is that:

	(1) 'C' is not isomorphic to UNIX 'C'.
	(2) If you're not going to deal with X as a first-class object in
	    the language, don't make half efforts.
-- 
-- Peter da Silva  `-_-'  ...!hoptoad!academ!uhnix1!sugar!peter
-- Disclaimer: These U aren't mere opinions... these are *values*.