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

Fixing C

embedded.com

Post reply on HN
Print view View original

111–120 of 123 posts

Re: Fixing C

#111

Post by burfog »

opk wrote: post #6

I'd make const the default, requiring a var keyword for variables. This makes it easier to get const correctness right because a missing var would break compilation while currently, a missing const doesn't. Next on my list would be := for assignment which is less easy to confuse with equality followed by variable declarations being name: type which is better once type names get long - admittedly they never are in pla…

It takes a lot more than that to get const correctness right. Consider the strstr function. The constness of the result really ought to match the constness of the first argument.

It can get much worse. Consider a function that takes two strings as arguments, then returns the longer one. Constness of the result ideally depends on the input. At the very least, when both inputs have the same constness you'd expect the result to also have that constness.

Re: Fixing C

#112

Post by jjnoakes »

gdwatson wrote: post #110
jjnoakes wrote: post #104

Earlier quoted context omitted.

Not all closures require heap allocation.

Enriquto asked for closures which remain valid after the enclosing function has returned — upward funargs. If the closed-over variables need to survive the parent’s stack frame, where else would you put them?

The variables could be static, or optimized away, or...

I'm not saying every closure can be done without allocation. I'm saying many useful ones can be though.

Re: Fixing C

#113

Post by jamessu »

Terribledactyl wrote: post #101
jamessu wrote: post #98

Earlier quoted context omitted.

His point was that you aren't interpreting the `const' the same way the compiler does. To the compiler, this: const int *a; a = NULL; // perfectly OK *a = 0; // does not compile Is a pointer to a constant int, not a constant pointer to an int. You're probably confusing it with this: int *const a; a = NULL; // does not compile *a = 0; // perfectly OK Which is a constant pointer to a regular int. Of course you can comb…

I think we're in violent disagreement. I fully understand what my code did, but people I've worked with and gone to school have been tripped up by statements like these. Stuff like this is all over exams.

I agree that we disagree. Your comment elsewhere:

> It's all about the underhanded trick(s) with the pointers, yours will never compile. I'm forcing clang to do horrible things.

Indicates, to me, that you see this as a strange behaviour that you're forcing the compiler into when in fact this is exactly the intended (and expected) semantics of const.

Re: Fixing C

#114

Post by jandrese »

joeld42 wrote: post #95
jandrese wrote: post #80

Earlier quoted context omitted.

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

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

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.

Re: Fixing C

#115

Post by Cpoll »

ludamad wrote: post #87
bpchaps wrote: post #74

Earlier quoted context omitted.

Oh, stop :p "$ find git -name .c -type f | xargs fgrep '{' | wc -l" 19288 "$ find linux -name .c -type f | xargs fgrep '{' | wc -l" 1408368

I'm confused, this is just counting starting braces no?

I think the idea is that Linux has two orders of magnitude more loops, so one order of magnitude more 4-level-indentations is actually an improvement over Git's code, by ratio.

It's not as if Torvalds wrote the entire codebase by himself, anyway.

Re: Fixing C

#116

Post by joeld42 »

jandrese wrote: post #114
joeld42 wrote: post #95

Earlier quoted context omitted.

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

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.

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

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.

Re: Fixing C

#117

Post by paulddraper »

Cpoll wrote: post #115
ludamad wrote: post #87

Earlier quoted context omitted.

I'm confused, this is just counting starting braces no?

I think the idea is that Linux has two orders of magnitude more loops, so one order of magnitude more 4-level-indentations is actually an improvement over Git's code, by ratio. It's not as if Torvalds wrote the entire codebase by himself, anyway.

?

Git and linux were both written (originally) by Torvalds.

And both use a fair amount of deep indentation.

Re: Fixing C

#118

Post by bpchaps »

paulddraper wrote: post #117
Cpoll wrote: post #115

Earlier quoted context omitted.

I think the idea is that Linux has two orders of magnitude more loops, so one order of magnitude more 4-level-indentations is actually an improvement over Git's code, by ratio. It's not as if Torvalds wrote the entire codebase by himself, anyway.

? Git and linux were both written (originally) by Torvalds. And both use a fair amount of deep indentation.

Right. I wasn't really commenting on whether git/linux were coded "correctly" in either case, just that it's not a very helpful metric for the larger conversation.

Re: Fixing C

#119

Post by paulddraper »

bpchaps wrote: post #118
paulddraper wrote: post #117

Earlier quoted context omitted.

? Git and linux were both written (originally) by Torvalds. And both use a fair amount of deep indentation.

Right. I wasn't really commenting on whether git/linux were coded "correctly" in either case, just that it's not a very helpful metric for the larger conversation.

Fair enough. And my (flippant) comment was on two very large, very successful projects written predominantly in C with thousands of contributors.

Whether >3 level of indentation is "good", IDK. But it happens a lot. And I'm a practical man.

Re: Fixing C

#120

Post by kbart »

That's why it's a good practice to comment closing curly braces for the long blocks:

    while (1)
    {
        
    } // end of while
Post reply on HN