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

91–100 of 174 posts

Re: Stupid Smart Pointers in C

#91

Post by amjoshuamichael »

flohofwoe wrote: post #81
amjoshuamichael wrote: post #36

Earlier quoted context omitted.

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 the…

My argument is that using these non-standard extensions to do important things like memory management in a C library is malpractice—it effectively locks down the library to specific C compilers. I'm sure that's fine if you're writing to clang specifically, but at that point, you can just write C++. libfreetype & stb_* are used and continue to be used because they can be relied on to be portable, and using compiler-specific extensions (without ifdefs) defeats that. If I relied on a clang-specific `defer`, I'm preventing my library from possibly being compiled via a future C compiler, let alone the compilers that exist now. To me, that's the point of writing C instead of C++ for a library (unless you're just a fan of the simplicity, which is more of an ideological, opinion-based reason).

Re: Stupid Smart Pointers in C

#92

Post by mac3n »

this is way overkill

the way i do this in C looks like

    initialize all resource pointers to NULL;

    attempt all allocations;

    if all pointers are non-NULL, do the thing (typically calling another routine)

    free all non-NULL pointers
realloc(ptr, 0) nicely handles allocations and possible-NULL deallocations

Re: Stupid Smart Pointers in C

#93

Post by bsenftner »

qwertox wrote: post #85
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`…

That m_binarySize should have been removed, nothing referenced it beyond it's own code. I knew it did not affect the free() call and left it. That entire KVS lib is a fine example of KISS, it's so small I can hold it in my head, and issues like that m_binarySize field are just left because they end up being nops.

Re: Stupid Smart Pointers in C

#94

Post by mac3n »

mac3n wrote: post #92

this is way overkill the way i do this in C looks like initialize all resource pointers to NULL; attempt all allocations; if all pointers are non-NULL, do the thing (typically calling another routine) free all non-NULL pointers realloc(ptr, 0) nicely handles allocations and possible-NULL deallocations

if you must have a `free_on_exit()` (for example, if you allocate a variable number of pointers in a loop) then build your own defer stack registering pointers using memory that you allocate

Re: Stupid Smart Pointers in C

#95

Post by rwmj »

adamrezich wrote: post #89
KerrAvon wrote: post #86

Earlier quoted context omitted.

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?

Yeah it's reasonable. Unfortunately if you do it, and you run tools like Coverity, it'll produces reams of complaints about how you're leaking memory :-( There was one project which was genuinely a short-lived program that never needed to free memory, but in the end I gave in and added free() statements everywhere. Otherwise we could never have got it into RHEL.

Re: Stupid Smart Pointers in C

#96

Post by UncleMeat »

bsenftner wrote: post #47
UncleMeat wrote: post #31

Earlier quoted context omitted.

I downvoted because in my mind you are winging it. "Just give it back" works well for simple cases, I suppose. We observe that engineering teams struggle to write correct code without tools helping them. This is just an unavoidable fact. Even with tools that are unsound we still see oodles of memory safety bugs. This is true for small projects run by individuals up to massive projects with hundreds or thousands of de…

I'm advocating to design, and then follow the design, and when the design is found lacking redesign to include the new understanding. This writing of software career is all about understanding, and automating that understanding. Due to market pressures, many companies try to make due with developers that take shortcuts, these shortcut takers the majority of developers today, skewing the intellectual foundations of th…

And I'm telling you that designing an application with a coherent memory management plan still leads to teams producing errors and bugs that are effectively prevented with sound tools. Soundness is not a shortcut.

Re: Stupid Smart Pointers in C

#97

Post by masklinn »

EPWN3D wrote: post #71
masklinn wrote: post #37

Earlier quoted context omitted.

> we hope will be added to the C spec one day defer seems to be making significant progress (having a passionate and motivated advocate in Meneide, and a full TS)

defer is nice, but I really want the cleanup attribute since it could in theory by applied to the return type of a function. In other words you could have malloc return a pointer with the cleanup attribute that automatically frees it at end of scope if it's non-NULL. (And if you want to persist the pointer just assign to a different variable and zero out the one malloc gave you.)

> In other words you could have malloc return a pointer with the cleanup attribute that automatically frees it at end of scope if it's non-NULL.

That is not, as far as I know, how __attribute__((cleanup)) works. It just invokes the callback when the value goes out of scope. So you can't have malloc return an implicitly cleanup'd pointer unless malloc is a macro, in which case you can do the same with a defer block.

Re: Stupid Smart Pointers in C

#98

Post by adamrezich »

rwmj wrote: post #95
adamrezich wrote: post #89

Earlier quoted context omitted.

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

Yeah it's reasonable. Unfortunately if you do it, and you run tools like Coverity, it'll produces reams of complaints about how you're leaking memory :-( There was one project which was genuinely a short-lived program that never needed to free memory, but in the end I gave in and added free() statements everywhere. Otherwise we could never have got it into RHEL.

Why not just put all the free()s at the end of main() behind an #ifdef DEBUG or something?

Re: Stupid Smart Pointers in C

#99

Post by legohead »

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 are your issues with the memory requirements being small? One of the programs was a MUD that consumed a couple hundred megabytes, and I never had issues with it.

I mentioned gigabytes because of how mine specifically worked. It allocated chunks in powers of 2, so there was some % of memory that wasn't being used. For instance, If you only need 20 bytes for a string, you got back a pointer for a chunk of 32 bytes. Being just a game, and side project, I never gave it much thought, so I'm curious to hear your input.

Re: Stupid Smart Pointers in C

#100

Post by icedchai »

alextingle wrote: post #70
jcranmer wrote: post #52

Earlier quoted context omitted.

We have 50 years of experience of code telling us that, no, programmers are not consistently capable of avoiding memory safety just by being good about it. Saying that it's just a failing of lesser programmers is the height of extreme arrogance, since I guarantee you that you've written memory safety vulnerabilities if you've written any significant amount of C code. The problem is not that the rules are hard to foll…

Is your function body really 600+ LOC?? If so, then I think I might have found your problem...

I one worked on a commercial product, a mix of C++ calling our own C libraries, that had 4000+ LOC in a single case statement. This was one of my first jobs out of school so I was shocked.
Post reply on HN