3 ms·

Of all the things in C that cause problems and that could be fixed by waving a magic wand, the author chose "curly braces"?! That betrays an immense lack of ima

by adwn 11y ago

Of all the things in C that cause problems and that could be fixed by waving a magic wand, the author chose "curly braces"?! That betrays an immense lack of imagination! Worse, it shows that the author isn't even aware of the actual causes of lost productivity and bugs in C programs. What about buffer overflows (it happens to the best of us)? Mounds of undefined behavior exploited by optimizing compilers (even in seemingly correct code)? A type system that is strict enough to get in one's way, but not strict/powerful enough for strong guarantees? Some years ago I read a post on a forum for electronics/embedded programming, which basically said "The system of C header files is actually very good, because without it you would have to manually declare all functions you use." This article reminded me of that.

rkangel 11y ago
Yes - the smallest change to C that I'd make is to make it strongly typed. The implicit coercions seem so at odds with the rest of the design of C (where everything is explicit).
jandrese 11y ago
I've always wanted a heap inspection function. Give it a pointer and it returns the amount of data allocated to it. I mean free() can figure it out, why can't I see it? I'm sure there are some good technical reasons that make this difficult/expensive, but there aren't even any half measures available. Not even something that requires the pointer be at the start of the originally malloc()ed memory and can return an error code if the pointer is somewhere in the middle of the heap or off in lala land. A function like that would at least make defensive programming possible and not require people to manually pass in the size of their buffer all of the time.
- joeld42 11y ago
  So write your own allocator... EDIT: That might sound snarky, it's not meant to be. I just mean that you can do something like this: https://gist.github.com/joeld42/74f67cde97a789467a2f681961b89c27 https://gist.github.com/joeld42/74f67cde97a789467a2f681961b8... people complain about C's memory manager, but really it's one of the most flexible out there because you can do stuff like this. Well written C libraries will provide hooks to use a custom allocator if needed.
  - jandrese 11y ago
    You're missing the point though. Unless you can take over the world (and the C stdlib!) with this allocator it is of limited use. You have to rewrite everything to use it to get any value out of it. So it's great for your own internal code, but of pretty limited value once you start pulling in libraries.
    - joeld42 11y ago
      No, I've plugged in custom allocators into codebases that had millions of lines of C (and even C++). Very few functions in the C stdlib allocate memory. Most that do (like strdup) are convenience wrappers. Most decent 3rd party libraries will allow you to plug in your own allocators, and if they don't, they should. Typically you do something like #define LIBFOO_ALLOC my_alloc before including things, or they have some kind of function like setAllocator().. For example, here's how to do it for Freetype (a pretty large 3rd party library). http://www.freetype.org/freetype2/docs/design/design-4.html http://www.freetype.org/freetype2/docs/design/design-4.html If a 3rd party library didn't let me do this, I would probably refuse to use it (or patch it). And you can always search/replace malloc and free if you're using some 3rd party code that doesn't do that. It really doesn't take that long. Also, malloc and free are specified to be weakly linked, so you can implement your own and replace the cstdlib ones even if you don't have the source available. This isn't a great option, but it works, especially if you're just using it for a diagnostic build. If you're talking about C++, that's yet another thing the STL screwed up. You can usually find ways to work around it but yeah, it's a bigger problem.
- userbinator 11y ago
  There is such a function, it's just not been standardised (and I agree that it is a rather large oversight on the part of the standards committee to have not realised that this is useful information which all implementations of malloc() would already have in some form): http://stackoverflow.com/questions/1281686/determine-size-of-dynamically-allocated-memory-in-c http://stackoverflow.com/questions/1281686/determine-size-of...

by adwn 11y ago

rkangel 11y ago

Yes - the smallest change to C that I'd make is to make it strongly typed. The implicit coercions seem so at odds with the rest of the design of C (where everything is explicit).

jandrese 11y ago

I've always wanted a heap inspection function. Give it a pointer and it returns the amount of data allocated to it. I mean free() can figure it out, why can't I see it? I'm sure there are some good technical reasons that make this difficult/expensive, but there aren't even any half measures available. Not even something that requires the pointer be at the start of the originally malloc()ed memory and can return an error code if the pointer is somewhere in the middle of the heap or off in lala land. A function like that would at least make defensive programming possible and not require people to manually pass in the size of their buffer all of the time.

joeld42 11y ago
So write your own allocator... EDIT: That might sound snarky, it's not meant to be. I just mean that you can do something like this: https://gist.github.com/joeld42/74f67cde97a789467a2f681961b89c27 https://gist.github.com/joeld42/74f67cde97a789467a2f681961b8... people complain about C's memory manager, but really it's one of the most flexible out there because you can do stuff like this. Well written C libraries will provide hooks to use a custom allocator if needed.
- jandrese 11y ago
  You're missing the point though. Unless you can take over the world (and the C stdlib!) with this allocator it is of limited use. You have to rewrite everything to use it to get any value out of it. So it's great for your own internal code, but of pretty limited value once you start pulling in libraries.
  - joeld42 11y ago
    No, I've plugged in custom allocators into codebases that had millions of lines of C (and even C++). Very few functions in the C stdlib allocate memory. Most that do (like strdup) are convenience wrappers. Most decent 3rd party libraries will allow you to plug in your own allocators, and if they don't, they should. Typically you do something like #define LIBFOO_ALLOC my_alloc before including things, or they have some kind of function like setAllocator().. For example, here's how to do it for Freetype (a pretty large 3rd party library). http://www.freetype.org/freetype2/docs/design/design-4.html http://www.freetype.org/freetype2/docs/design/design-4.html If a 3rd party library didn't let me do this, I would probably refuse to use it (or patch it). And you can always search/replace malloc and free if you're using some 3rd party code that doesn't do that. It really doesn't take that long. Also, malloc and free are specified to be weakly linked, so you can implement your own and replace the cstdlib ones even if you don't have the source available. This isn't a great option, but it works, especially if you're just using it for a diagnostic build. If you're talking about C++, that's yet another thing the STL screwed up. You can usually find ways to work around it but yeah, it's a bigger problem.
userbinator 11y ago
There is such a function, it's just not been standardised (and I agree that it is a rather large oversight on the part of the standards committee to have not realised that this is useful information which all implementations of malloc() would already have in some form): http://stackoverflow.com/questions/1281686/determine-size-of-dynamically-allocated-memory-in-c http://stackoverflow.com/questions/1281686/determine-size-of...