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

101–110 of 123 posts

Re: Fixing C

#101

Post by Terribledactyl »

jamessu wrote: post #98
Terribledactyl wrote: post #86

Earlier quoted context omitted.

No I don't want to throw it out, I kinda like C. And you can also do seemingly weird things with it. I was trying to bring some light to how const and immutable could be conflated. A lot of people see const and think, no aspect of this is changeable.

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.

Re: Fixing C

#102

Post by na85 »

jandrese wrote: post #78
JulianMorrison wrote: post #26

Earlier quoted context omitted.

If it's embedded code, it's quite possible you can't just decompose code into little bitty chunks to avoid nesting, because your maximum stack depth is fixed and very small.

It is also definitely possible to go overboard with chopping up your code. I'm sure everyone has read that file where damn near every single line ended up in its own little function (in its own file with some big framework around it) and you're jumping all over the place trying to figure out what its actually doing. Everything should be made as simple as possible, but not simpler.

>I'm sure everyone has read that file where damn near every single line ended up in its own little function (in its own file with some big framework around it) and you're jumping all over the place trying to figure out what its actually doing.

Sounds like node and its moronic packaging ecosystem.

Re: Fixing C

#103

Post by Terribledactyl »

rkangel wrote: post #91
Terribledactyl wrote: post #86

Earlier quoted context omitted.

No I don't want to throw it out, I kinda like C. And you can also do seemingly weird things with it. I was trying to bring some light to how const and immutable could be conflated. A lot of people see const and think, no aspect of this is changeable.

If you think that though, you haven't got a clear picture of what pointers are and how they work. The pointer itself and thing it is pointing to are two completely different variables in memory. Being unclear about the difference is likely to cause lots of problems when coding C. Using a pointer to iterate through a string/array/other data structure, that is stored in const is a completely standard thing to do.

I do get what's going on here, maybe poor example. I was trying to show off some confused ways I've seen pointers and const used together, in attempt to confuse people. Some corollary of Poe's law maybe at play.

Re: Fixing C

#104

Post by jjnoakes »

gdwatson wrote: post #88
enriquto wrote: post #23

Closures. This is the only thing that I miss in C. I always want to declare local functions, and return pointers to them.

That would require implicit heap allocation, which is a lot to ask for in a language where malloc is a library function.

Not all closures require heap allocation.

Re: Fixing C

#105

Post by jjnoakes »

veli_joza wrote: post #36
huhtenberg wrote: post #20

Earlier quoted context omitted.

There you go: struct much_improved_c { ... }; struct much_improved_c an_api_that_doesnt_suck() { ... };

This is the only way it can be done in statically typed language. You cannot have multiple returns without defining how many there are what are their types.

The definition of what they are and how many could just as easily be done at the function declaration. There is no requirement that multiple return types in a static language have to be declared separately and verbosely. That is just how C does it.

Re: Fixing C

#106

Post by userbinator »

jandrese wrote: post #80
adwn wrote: post #54

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

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…

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

Re: Fixing C

#107

Post by foota »

I'm surprised not to see lua on the chart, it seems to be fairly popular from what I've seen in limited resources environments.

Re: Fixing C

#108

Post by yitchelle »

When I read this, I wasn't sure if it was a joke article or not. I have read Jack's article for many years and this has to be one of his weakest yet. Complaining about curly braces...

Why don't we get rid of the semi-colon and delimit the line of code via the symbol EOL, or maybe use the carriage return.

Re: Fixing C

#109

Post by adwn »

userbinator wrote: post #51
tronje wrote: post #8

C, to me, requires a lot of discipline about good coding style and conventions. I personally like that a lot, even though, of course, it sometimes causes one to shoot oneself in the foot. But, and I can't point to exactly why, I don't think I want to change anything. Maybe Rust or something new will come along sometime soon to fix all the issues that exist with C. Oh, and for those who haven't seen it, there was a co…

I personally like that a lot, even though, of course, it sometimes causes one to shoot oneself in the foot. But, and I can't point to exactly why, I don't think I want to change anything. I feel much the same way, and I think it's the general principle of freedom over security that makes it fun . You can do lots of things that other languages wouldn't allow, and despite not needing to most of the time, the fact that…

> [...] I think it's the general principle of freedom over security that makes it fun.

That's okay, just please don't have this attitude while writing production code. If my system is compromised because of yet another buffer overflow exploit in some C library, I don't care if you felt the wind in your hair while programming it.

Re: Fixing C

#110

Post by gdwatson »

jjnoakes wrote: post #104
gdwatson wrote: post #88

Earlier quoted context omitted.

That would require implicit heap allocation, which is a lot to ask for in a language where malloc is a library function.

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?
Post reply on HN