Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stupid Smart Pointers in C

blog.kevinalbs.com

Post reply on HN
Print view View original

81–90 of 174 posts

Re: Stupid Smart Pointers in C

#81

Post by flohofwoe »

amjoshuamichael wrote: post #36
dietr1ch wrote: post #29

Earlier quoted context omitted.

> relying on compiler vendor extensions kind of defeats the purpose of that. Let's be honest, how many compilers are available, and how many of those would you actually use? The answer isn't more than 4 and the 2 compilers you are most likely to use among those already support this and probably won't stop supporting without a good alternative. I like standardisation, but you have to be realistic when it helps you wit…

For me, the point of writing something in C is portability. There were C compilers 30 years ago, there are C compilers now, and there will almost certainly be C compilers 30 years from now. If I want to write a good, portable library that's going to be useful for a long time, I'll do it in C. This is, at least, the standard in many gamedev circles (see: libsdl, libfreetype, the stb_* libraries). Under that expectatio…

For accessing any post-1970s operating system feature (e.g. async IO or virtual memory) you already cannot use standard C anymore (and POSIX is not the C stdlib).

The libraries you listed are all full of platform-specific code, and also have plenty of compiler-specific code behind ifdefs (for instance the stb headers have MSVC specific declspec declarations in them).

E.g. there is hardly any real-world C code out there that is 'pure standard C', if the code compiles on different compilers and for different target platforms then that's because the code specifically supports those compilers and target platforms.

Re: Stupid Smart Pointers in C

#82

Post by qwertox »

Not to mention that any future CPU microcode update released in order to mitigate some serious CVE might break the entire product you've been shipping, just because it relied on some stack manipulation wizardry.

Re: Stupid Smart Pointers in C

#83

Post by PeterWhittaker »

1) 2018

2) I recently discovered the implementation of free_on_exit won't work if called directly from main if gcc aligns the stack. In this case, main adds padding between the saved eip and the saved ebp, (example). I think this can be fixed some tweaking, and will update this article when it is fixed.

I do not believe the article was updated, suggesting that the "tweaking" was far more complex than the author expected...

...which doesn't surprise me, because the overall tone is one of a clever but far-less-experienced-than-they-think programmer having what they think is a flash of insight and realizing thereby they can solve simply a problem that has plagued the industry and community for decades.

Re: Stupid Smart Pointers in C

#84

Post by AnimalMuppet »

bsenftner wrote: post #73
AnimalMuppet wrote: post #51

Earlier quoted context omitted.

You can consider whatever you want. That doesn't make it accurate. The reason I downvoted was for unnecessary inflammatory language. Your point would have been better without it (more likely to be heard by the people you claim to be talking to, at a minimum). If you're actually trying to talk to people, if you're not just here to say "I'm smart and you're stupid" to gratify your ego, then why talk in a way that makes…

You are correct, and I seriously need to work on my language usage.

Well, see, I never give in to the temptation of using inflammatory language. Never... um, never today... um, so far... I think...

We've all been there. (Well, maybe dang hasn't. Most of the rest of us have, though.)

Re: Stupid Smart Pointers in C

#85

Post by qwertox »

bsenftner wrote: post #6

[flagged]

You can have situations like

https://github.com/bsenftner/kvs/blob/master/kvs/kvs.cpp#L72...

where it's then not clear why there is no call to

`kv.m_binarySize = byte_size`

after calling

`kv.mp_binaryData = (uint8_t)malloc( sizeof(uint8_t) byte_size );`

because it seems like `kv.mp_binaryData` will now have a different size than it had before. That is, there will be a mismatch. Though it should not affect the `free` call.

I hope I'm missing something because I just dealt with the code for around 5 minutes.

Re: Stupid Smart Pointers in C

#86

Post by KerrAvon »

legohead wrote: post #77
rwmj wrote: post #5

Really, don't do this, it's a portability and safety nightmare (aside from C not being memory safe already). C programmers are better off with either of these two techniques: * Use __attribute__((cleanup)). It's available in GCC and Clang, and we hope will be added to the C spec one day. This is widely used by open source software, eg. in systemd. * Use a pool allocator like Samba's talloc ( https://talloc.samba.org/…

My C programs never consumed gigs of memory. So I (like many others I assume) made a memory manager and never freed anything. You'd ask it for memory and it kept a list of various sizes it allocated and returned what you needed to be re-used. Freeing and allocating is slow, and error prone, so just avoid it!

A venerable and completely reasonable approach for resource-constrained environments and/or programs with very small memory requirements (kilobytes).

Re: Stupid Smart Pointers in C

#88

Post by DanielHB »

dietr1ch wrote: post #64
DanielHB wrote: post #34

Earlier quoted context omitted.

There are quite a lot of embedded code that relies on obscure C compilers created and maintained by the CPU manufacturer. But then again you are probably not doing a whole lot of heap management in embedded code.

That sounds like the kind of code that you want to be done with and never touch again. You can only dream of it not being buggy or catching up with the newest standard.

No it is more like the 10000 lines of code running in your washing machine, you will probably be updating it in the next year revision of the product.

It is quite common for this code to have all variables be global and just not have any heap allocations at all. Sometimes you don't even have variables in the stack either (besides the globals).

Re: Stupid Smart Pointers in C

#89

Post by adamrezich »

KerrAvon wrote: post #86
legohead wrote: post #77

Earlier quoted context omitted.

My C programs never consumed gigs of memory. So I (like many others I assume) made a memory manager and never freed anything. You'd ask it for memory and it kept a list of various sizes it allocated and returned what you needed to be re-used. Freeing and allocating is slow, and error prone, so just avoid it!

A venerable and completely reasonable approach for resource-constrained environments and/or programs with very small memory requirements (kilobytes).

What makes you think that this approach is only useful for resource-constrained circumstances?

Re: Stupid Smart Pointers in C

#90

Post by pajko »

rwmj wrote: post #5

Really, don't do this, it's a portability and safety nightmare (aside from C not being memory safe already). C programmers are better off with either of these two techniques: * Use __attribute__((cleanup)). It's available in GCC and Clang, and we hope will be added to the C spec one day. This is widely used by open source software, eg. in systemd. * Use a pool allocator like Samba's talloc ( https://talloc.samba.org/…

There's a complete implementation available at https://github.com/Snaipe/libcsptr
Post reply on HN