csg@pyramid.pyramid.com (Carl S. Gutekunst) (10/06/89)
In article <352@massey.ac.nz> ARaman@massey.ac.nz (A.V. Raman) writes: >Why do I have to explicitly declare malloc, calloc and other such things in >my C source in a ucb universe, whereas I can just include malloc.h in the att >universe and have it done automatically. Pyramid OSx does not declare malloc(3) in a header file in the ucb universe because Berkeley 4.3BSD doesn't. It *is* declared in a header file in the att universe, because AT&T SVR3 does do that. In general, it is Pyramid's policy to not add new features to the universes that cause portability problems, even if they would be useful or sensible. Now, if you want to know why *Berkeley* didn't put a declaration of malloc(3) in some convenient header file, I haven't any idea. But I agree it would be a good idea. <csg>
chris@CS.UMD.EDU (Chris Torek) (10/07/89)
4.4BSD has (well, will have) an ANSI <stdlib.h>, which includes declarations for malloc, calloc, and free. Chris
jsloan@handies.ucar.edu (John Sloan,8292,X1243,ML44E) (10/07/89)
From article <86743@pyramid.pyramid.com>, by csg@pyramid.pyramid.com (Carl S. Gutekunst): > Now, if you want to know why *Berkeley* didn't put a declaration of malloc(3) > in some convenient header file, I haven't any idea. But I agree it would be a > good idea. Here's a guess: What would you declare it as? The only possible choice would be "char *malloc" since it returns a pointer. But even though perhaps 75% of the time you are allocating a character string, 25% of the time you're allocating some other data type, most likely a structure. So to keep cc from complaining, you gotta cast the output of malloc into another type, e.g. "(struct node *)malloc". That's all well and good, but what if you're developing something big in which ALL malloc's are for some structure other than a character string. Now on all instances of malloc you gotta cast it to the correct thing. Wouldn't it be simpler just to declare malloc to be "struct node *malloc" in some master header file? But you can't do that, 'cause cc will complain about the redeclaration. Without any specified declaration in some malloc.h, you can declare malloc to be anything you want, and cast it only when necessary. It's a lame excuse, I admit. What you need is something like C++'s "void *", where you mean "It's a pointer, darn it, just an address, don't bug me about it". John Sloan NCAR/SCD NSFnet: jsloan@ncar.ucar.edu P.O. Box 27588 P.O. Box 3000 NCAR Mesa Lab, Room 42A Lakewood CO 80227 Boulder CO 80307 +1 303 497 1243 Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.
csg@pyramid.pyramid.com (Carl S. Gutekunst) (10/08/89)
>>Now, if you want to know why *Berkeley* didn't put a declaration of malloc(3) >>in some convenient header file, I haven't any idea. But I agree it would be a >>good idea. > >Here's a guess: What would you declare it as? You'd declare it as a its declared type: char *. Anything else would be wrong. >But even though perhaps 75% of the time you are allocating a character >string, 25% of the time you're allocating some other data type, most likely >a structure. So to keep cc from complaining, you gotta cast the output of >malloc into another type, e.g. "(struct node *)malloc". Yup. And that is the *ONLY* correct way to do it. Those of us living on nice contiguous memory, byte-addressable architectures have gotten terribly spoiled by the fact that pointers are the same, no matter what they are pointing to. But that ain't the case everywhere. malloc(3) returns a char *. If you are on the wrong machine (Sperry 2200 and Cyber come to mind), and you simply declare malloc() are something else, you software will crash and burn. <csg>