ron@nbife.NBI.COM (Ron Schweikert) (06/13/89)
There are numerous excellent books to cover Unix internals and the C programming language, data structures etc. Much of that is discussed in these newsgroups (thanks to the fluent C programmers who assist those of us 'silent' but consistent readers). What I am interested in is a book on 'C internals'. Having never taken college computer science classes I am unaware of the texts available and have been unsuccessful in finding those types of books in local stores (B Dalton, Software Etc.). There are many excellent discussions in these newsgroups on how-tos rules and 'whys'. The aforementioned books show nice square blocks on top of each other (stack frames) and nice little arrows (pointers) which is enough to learn the language, but not enough to be 'fluent'. Kind of like the difference between being an airplane *driver* who physically manipulates flight controls because the books says to do it that way -- vs. a *pilot* who understands the dynamics (cross post to rec.aviation :-). BTW, the local university continuing education classes that I've taken on the subject basically do the same thing, draw boxes, so I have pursued this and am not 'shooting from the hip'. Specific *types* of questions I would appreciate text references for: - Pointer conversion and info. What is the internal representation of pointers as we cast them from one type to another, ie. the change that takes place internally in a cast from a malloc return. For example: struct junk *ptr; (and then later...) ptr = (struct junk *)malloc(n * sizeof(struct junk)); How about (char *)&(var) for a function that needs a char pointer. What does the compiler do with this? What changed? Where and how does the compiler keep track of the change? - I know that function arguments are 'pushed' as stack frames onto the user's stack, but I'd like a good text reference (ala. computer science textbook) that explains the whole procedure more clearly than drawing two perfect little square boxes on top of each other. Bach's books (Unix Internals) gets closer. How big can a stack grow in a recursive function? Is it dangerous to use recursion and risk having the system stop the function because the stack grew into another area? You get the idea. Sorry for being so verbose, probably could have asked the question in two sentences for computer science textbook references, but I wanted to let you know what kind of information I was looking for. Thanks in advance to all who respond. If there is interest, I'll post the information sent to me, or email responses to those who request. Ron Schweikert