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

71–80 of 123 posts

Re: Fixing C

#71

Post by ArkyBeagle »

veli_joza wrote: post #30
exprA wrote: post #19

Earlier quoted context omitted.

C arrays “know” their size. (String literals do too.)

You can sizeof them if the declaration is in scope. If you pass them as function argument, this information is not obtainable inside function. You have to pass length as well. This is not very elegant and sometimes you elect to process them without using functions just because you can iterate them easier.

So roll your own struct based solution to where the size is now state.

If you're talking about the old stdlib.h calls, don't use them with blind pointers where the size isn't known. I'd say use the "n" versions but you don't even have to do that.

'C' gets easier when you do faux RAII and make "objects" with internal state, at least think about not using dynamic allocation for everything and think a little bit about what might make the API usable by the extremely lazy.

Re: Fixing C

#72

Post by ArkyBeagle »

optforfon wrote: post #56

There are a million problem with C that come before curly braces. So many of the people that venerate C either live in a reality distortion bubble or don't actually writing C. I've always found C a disaster for generating good assembly. to start: https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/C-Extensions.ht... we see that bare C has: - no vectorization/SIMD support - no hinting at likely branches - no way to prefetch…

There's no veneration here. It's just eminently possible to use 'C' to get work done.

Re: Fixing C

#73

Post by adrianN »

ArkyBeagle wrote: post #70
pjc50 wrote: post #63

Earlier quoted context omitted.

.. until you pass them as a function argument. And strlen() only works if your null terminator is valid, and doesn't tell you anything about available space in the string buffer for adding to the string. This kind of thing keeps coming up in vulnerability reports.

This happens because people don't use the tools properly.

They should be using Ada instead of C, amiright /s

Re: Fixing C

#74

Post by bpchaps »

paulddraper wrote: post #67
rootlocus wrote: post #7

Removing curly braces? I have to paraphrase Torvalds on this: > The answer to that is that if you need > more than 3 levels of indentation, you're screwed anyway, > and should fix your program. Breaking the code into manageable chunks is a huge part in writing clear, maintainable software. A high amount of curly braces implies deep nested loops and/or branches, which also implies a high complexity (measured by cyclom…

YOUR ACTIONS SPEAK SO LOUD I CANNOT HEAR WHAT YOU ARE SAYING. git clone --depth=1 git@github.com:git/git.git find git -name '*.c' -type f | xargs grep -P '^( {4}|\t){4}' | wc -l 11375 git clone --depth=1 git@github.com:torvalds/linux.git find linux -name '*.c' -type f | xargs grep -P '^( {4}|\t){4}' | wc -l 732937 Stupid shitty broken software.

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

Re: Fixing C

#75

Post by rkangel »

Terribledactyl wrote: post #69
rkangel wrote: post #61

Earlier quoted context omitted.

> const != immutable so 'const' is relegated to being a keyword for generating compiler warning I'm not sure what you mean here. On embedded targets, static data declared 'const' will be put in with the program memory, and so will be definitely read-only. Casting the pointer and writing to it will cause a hard fault (or segfault, or whatever the equivalent is on your platform).

#include int main(int argc, char argv) { const int *b = 9; b = 10; printf("%d",b); } what does (should) this print? (It compiles with warnings on llvm 7.3 / clang703 OSX)

It will print 10. There's absolutely no issue there at all. You've changed the value of the pointer which is NOT const.

    const int \*b
Means a pointer to a thing that is const. The pointer itself (which is on the stack in this case) is NOT const.

    const int *b = 9;
    *b = 10;
^^^ This will NOT compile.

    const int b = 9;
    int main() {
       int *a = (int *)b;
       *a = 10;
    }
^^^ This will compile (possibly with warnings). If you run it on an embedded target, this will crash: b will have been put in flash, so trying to write to it is a hard-fault.

Yes, C allows you to do 'unsafe' things with pointers. You aren't going to fix that without throwing away C and starting again.

Re: Fixing C

#76

Post by nkurz »

Terribledactyl wrote: post #69
rkangel wrote: post #61

Earlier quoted context omitted.

> const != immutable so 'const' is relegated to being a keyword for generating compiler warning I'm not sure what you mean here. On embedded targets, static data declared 'const' will be put in with the program memory, and so will be definitely read-only. Casting the pointer and writing to it will cause a hard fault (or segfault, or whatever the equivalent is on your platform).

#include int main(int argc, char argv) { const int *b = 9; b = 10; printf("%d",b); } what does (should) this print? (It compiles with warnings on llvm 7.3 / clang703 OSX)

I like that you have an example, but I'm not getting the results you are. Perhaps there is some oddity with your odd use of pointers?

I switched the code to this:

  #include 
  int main(int argc, char **argv) {
    const int b = 9;
    b = 10;
    printf("%d",b);
  }
And I get a very clear "error" and nothing compiled with gcc, icc, and clang. Did you maybe have a left over binary from a previous compilation? I didn't try OSX, but it's possible the real moral would be to always pay attention to warnings.

Re: Fixing C

#78

Post by jandrese »

JulianMorrison wrote: post #26
rootlocus wrote: post #7

Removing curly braces? I have to paraphrase Torvalds on this: > The answer to that is that if you need > more than 3 levels of indentation, you're screwed anyway, > and should fix your program. Breaking the code into manageable chunks is a huge part in writing clear, maintainable software. A high amount of curly braces implies deep nested loops and/or branches, which also implies a high complexity (measured by cyclom…

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.

Re: Fixing C

#79

Post by nkurz »

ngrilly wrote: post #41

I wonder how this article has been able to make HN's home page... The main thing the author thinks about improving C is... replacing braces with keywords?

Perhaps because some many users upvote articles with a clear and concise thesis even if they disagree with it? An article can spur productive discussion even if the premise of the article is wrong. I frequently post articles that I disagree with, hoping to see whether someone can show me why I'm wrong. That said, in this case do I agree with the consensus: of all the things, why is he complaining about braces?

Re: Fixing C

#80

Post by jandrese »

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

Post reply on HN