3 ms·

To elaborate on this... malloc and free aren't even a part of C itself. Other than static (globals and "static" the keyword) and automatic (stack) allocation

by smorrow 13y ago

To elaborate on this... malloc and free aren't even a part of C itself. Other than static (globals and "static" the keyword) and automatic (stack) allocation there isn't any memory management in C itself. malloc and free are library functions wrapping system calls. That's something to do with the operating system - the machine itself has NOTHING like malloc and free. I and many people know C but know fuck all about assembly programming. (for now)

smorrow 13y ago
P.S: Read "Deep C Secrets - Expert C Programming", and once you've understood the chapter on memory, go back and read the malloc implementation in the back of K & R.
spc476 13y ago
malloc() and free() (not to mention realloc() and calloc()) are part of the Standard C Library, and must be provided for a C compiler to be certified as ANSI compliant. Granted, you don't have to use any Standard C Library functions, but a C compiler must have them (or else, it can't claim ANSI compliance).
- smorrow 13y ago
  I knew they were part of the standard library and the specification -- I mean, even the stdio stuff is, right? -- I had no idea the compiler had any involvement in that, though. I know gcc provides them for you if you don't specify the right includes, but that's gcc, like. I think I'm going to go on considering them not technically part of C itself, until I have more information. Thanks.
  - spc476 13y ago
    (I'm not sure if you'll see this or not, but it's worth a shot) Like I said, before a compiler can be certified ANSI C, it must provide the Standard C Library (for whatever platform the compiler is for). As a programmer, you don't have to use the supplied functions, but they are there, and they do comprise a part of the C Standard. And because the functions are defined, the compiler writer can do some pretty neat things. For instance, include string.h, and that informs the compiler you want to use the string and memory functions defined by the C Standard. The compiler can then generate code directly for, say, memcpy() instead of generating a call to said function (it can inline it, even though C89 made no standard method of inlining a function). Or the function sin() if you include math.h (some CPUs support a single instruction for the sin function). Don't include string.h, and well ... what happens is up to the compiler. Most just give a warning about an undefined function, assume it's defined as "int unknownfunction()" and leave it up to the link phase to either find it or not. Yes, there is a distinction between the C language, and the C library, but both must be provided if a C compiler wants to conform to the C Standard.
    - smorrow 13y ago
      That is quite informative, and also quite bizarre (for C). TIL.
blahbl4hblahtoo 13y ago
The way that C memory management works is a design decision. that design decision had criteria that informed it...it's no more or less valid than other design decisions that are made in the face of other criteria. It's no more "low level" that lot's of other methods that have been/are being used. ufo got my point. the modern microprocessor is vastly different than the view of the world that is exposed through C. The fact that C still works is more of a testament to hardware designers than it is something "intrinsically true" about C and its design decisions.

by smorrow 13y ago

smorrow 13y ago

P.S: Read "Deep C Secrets - Expert C Programming", and once you've understood the chapter on memory, go back and read the malloc implementation in the back of K & R.

spc476 13y ago

malloc() and free() (not to mention realloc() and calloc()) are part of the Standard C Library, and must be provided for a C compiler to be certified as ANSI compliant. Granted, you don't have to use any Standard C Library functions, but a C compiler must have them (or else, it can't claim ANSI compliance).

smorrow 13y ago
I knew they were part of the standard library and the specification -- I mean, even the stdio stuff is, right? -- I had no idea the compiler had any involvement in that, though. I know gcc provides them for you if you don't specify the right includes, but that's gcc, like. I think I'm going to go on considering them not technically part of C itself, until I have more information. Thanks.
- spc476 13y ago
  (I'm not sure if you'll see this or not, but it's worth a shot) Like I said, before a compiler can be certified ANSI C, it must provide the Standard C Library (for whatever platform the compiler is for). As a programmer, you don't have to use the supplied functions, but they are there, and they do comprise a part of the C Standard. And because the functions are defined, the compiler writer can do some pretty neat things. For instance, include string.h, and that informs the compiler you want to use the string and memory functions defined by the C Standard. The compiler can then generate code directly for, say, memcpy() instead of generating a call to said function (it can inline it, even though C89 made no standard method of inlining a function). Or the function sin() if you include math.h (some CPUs support a single instruction for the sin function). Don't include string.h, and well ... what happens is up to the compiler. Most just give a warning about an undefined function, assume it's defined as "int unknownfunction()" and leave it up to the link phase to either find it or not. Yes, there is a distinction between the C language, and the C library, but both must be provided if a C compiler wants to conform to the C Standard.
  - smorrow 13y ago
    That is quite informative, and also quite bizarre (for C). TIL.

blahbl4hblahtoo 13y ago

The way that C memory management works is a design decision. that design decision had criteria that informed it...it's no more or less valid than other design decisions that are made in the face of other criteria. It's no more "low level" that lot's of other methods that have been/are being used. ufo got my point. the modern microprocessor is vastly different than the view of the world that is exposed through C. The fact that C still works is more of a testament to hardware designers than it is something "intrinsically true" about C and its design decisions.