Comment by blahbl4hblahtoo | Hacker News Reader

Comment by blahbl4hblahtoo | Hacker News Reader

blahbl4hblahtoo

Lots of people confuse learning to code in C with learning how hardware works. Its close in some ways but not all.

EDIT: WOW. I'm amazed at how many people think that C is "how memory works". Just wow. This is one of those things where you're confusing the map for the territory and ascribing value to something because its "hard". C is a fairly high level abstraction for interacting with a computer...i know that everyone has heard that c is close to being assembler...but what you are forgetting is that assembler is also an abstraction over operands. The reason i think its important to point this out is that malloc and free arent magical. Othér techniques are just as valid and the notion of "low level" is misleading. C makes tradeoffs that actually give rise to all of the vulnerabilities and stability problems in all the software that you have ever used. Those tradeoffs are REAL and just because lots of you get this macho nonsense about not using safe collection types everyone on the planet has to deal with malware. So many of you buy your own bullshit at an astonishing level...its really breathtaking to see how many of you cant see the built in assumptions in what you are saying.

At this point, the only thing that still keeps C close to the hardware is that they need to keep the hardware close to C model because of all the legacy code in the world. Most recent hardware innovations, like pipelining, speculative code execution, SIMD, etc are not easily expressed in C. Additionally, C was written in a time where accessing the memory was cheap and had a uniform cost - nowadays memory access times vary immensely depending on if its cached or not.

right on my knowledgeable homie...

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)

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.

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

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.

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

That is quite informative, and also quite bizarre (for C). TIL.

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.

Reply on news.ycombinator.com