4 ms·

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 co

by 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.

by spc476 13y ago

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.