Comment by dllthomas | Hacker News Reader

Comment by dllthomas | Hacker News Reader

Parent Full thread

"One problem is, in C at least, the compiler has no way to know that the contents pointed to by p have reached their end of life. All these examples use malloc() and free(), but these two names are purely convention, and any names and memory management methods can be used with different names."

This seams wrong, unless by "purely convention" you mean in some sense that the entire standard is "purely convention". The clearly defines the lifetime of an allocated object to be from allocation to deallocation, and clearly labels free (and realloc, in some circumstances) as deallocating. I am not sure whether a conforming implementation can introduce new functions that also, in the sense of the standard, deallocate, but in either case the provided code is still technically incorrect per the standard.

"Such as, sizeof(int) being the native hardware size of an integer. 8, 16, 24, 32, 36, 48, 64, I've suffered from them all."

Nit, and I'm sure you're aware, but perhaps worth noting for others: the values you're listing are (I infer) number of bits, which is not the same as what's returned by sizeof. sizeof gives number of chars, which on some architectures has actually been other than 8 bits!

But does not define them in terms of hardware.

My numbers referred to the native widths of the hardware words. sizeof(int) would of course return those numbers divided by 8, but machines are almost universally referred to by bit width, not byte width. Intel 64 bit chips, not Intel 8 byte chips, for example. So sizeof(int) is still a function of hardware width, and hardware width is defined in terms of bits.

Perhaps I should have been a bit more specific, instead of leaping over fully internalized transforms without explanation? Here? In a discussion about hardware? And note that 36 bits is not a multiple of 8, which actually breaks sizeof() anyway.

"Perhaps I should have been a bit more specific, instead of leaping over fully internalized transforms without explanation?"

I don't know about "should" - my post wasn't really meant as criticism. I just thought we had an opportunity to dig in a little deeper and do so a little clearer.

"Here? In a discussion about hardware?"

There are a whole lot of people here who have only done web dev or high-level x86 application development, and many who are only passingly familiar with C or HW.

"And note that 36 bits is not a multiple of 8, which actually breaks sizeof() anyway."

Oh, a 36 bit architecture without a char size of 9? Interesting! How did that work? Can that be standard conforming?

"should": a problem with lengthy experience and age is just how many steps between A and Z get chunked into merely A to B since it is "obvious". Which, in my case, is why I do not teach. Ive forgotten too many derivations. SO digging deeper would be a good exercise for me. Thanks.

36 bits was a custom DSP architecture. Could not use C to get at the extra 4 bits, had to use ASM.

Storage units is also inconstant. I've had fun with another DSP who used 16 bit instead of 8, could not address bytes at all. No C at all so I don't know what it would have done with sizeof(int). Had to exchange stream data with a conventional architecture via DMA. Fun times.

In some ways I am a little dissappinted in the arc of our technology. It may have become constrained overly by what compiler tech can do easily and can not do so easily. I really should not be able to understand how a quad-core architecture is put together and works, not after some 50 years of development, but I do. Not because I'm a genius, but because it is essentially the same stuff I worked with in the 60's with a lot of emvblishments, short cuts, and optimizations, but not fundamental change.

Reply on news.ycombinator.com