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

61–70 of 123 posts

Re: Fixing C

#61

Post by rkangel »

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…

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

Re: Fixing C

#62

Post by oneeyedpigeon »

> My vote is to get rid of the curly braces. All of us have suffered from bugs and compiler complaints from deeply-nested blocks of code where we get mixed up about how many closing braces are needed, and where they should be placed.

I cannot remember the last time this happened to me.

> I’d prefer requiring matching begin and end blocks, with the end statement indicating which block is being closed.

So you can close an outer block before closing inner blocks? Or you can omit closing of a block altogether? Why - doesn't this create loads of nasty ambiguity?

> Sure, careful indentation tells us the same thing, but so much code today has been modified by so many people that the original engineer’s careful indenting often becomes hopelessly mangled.

"Often"? Just fix that problem if, indeed, it IS a problem.

> I often put an indication of which brace is closing which block in the comments.

As others have pointed out, if you need to do this, you have bigger problems.

I do actually like Python's approach, although I don't have enough experience with it to judge if it's a big improvement.

Re: Fixing C

#63

Post by pjc50 »

okasaki wrote: post #18
adrianN wrote: post #13

C has many, many problems. Curly braces are really not one of them. If I could wave a magic wand and fix C I'd make arrays and strings know their size. Edit for the nitpickers: Yes, arrays decay to pointers and that's the real problem. Sorry.

Good news. Arrays have sizeof(arr)/sizeof(arr[0]) elements and strings have strlen(str) letters.

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

Re: Fixing C

#64

Post by pjc50 »

cturner wrote: post #17

When I was reading I was thinking - if you like that kind of grammar just use Ada. And then later down he specifically mentions Ada. So - why not just use that? With Ada, it is straightforward to create the kind of tight, fast code you'd write in C. You can control your own garbage collection and it has a fabulous type system. And - unless you need templates - it can do pretty much everything C++ can do as well. I do…

So, could we have the semantics of ADA with a different syntax?

Re: Fixing C

#65

Post by antome »

pjc50 wrote: post #64
cturner wrote: post #17

When I was reading I was thinking - if you like that kind of grammar just use Ada. And then later down he specifically mentions Ada. So - why not just use that? With Ada, it is straightforward to create the kind of tight, fast code you'd write in C. You can control your own garbage collection and it has a fabulous type system. And - unless you need templates - it can do pretty much everything C++ can do as well. I do…

So, could we have the semantics of ADA with a different syntax?

I for one would love the strength of SPARK with a more newfangled, perhaps rusty syntax. Call it Oxidise.

Re: Fixing C

#66

Post by mfukar »

veli_joza wrote: post #59
mfukar wrote: post #38

Earlier quoted context omitted.

Now, at one point, you stopped talking about arrays and started talking about pointers.

Exactly. When array is passed into function, you lose length information and array construct is reduced to pointer. Array syntax is just synthetic sugar for dereferencing pointer with offset.

This discussion won't get very far if all you think arrays are is syntactic sugar. The array type is useful - think in terms of a static analyser if it helps - in different ways than pointers.

Re: Fixing C

#67

Post by paulddraper »

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.

Re: Fixing C

#68

Post by ue_ »

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…

>https://matt.sh/howto-c

I think Keith Thompson's (not related to Ken Thompson) critique of the link you posted is an even better read: https://github.com/Keith-S-Thompson/how-to-c-response

Re: Fixing C

#69

Post by Terribledactyl »

rkangel wrote: post #61
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…

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

Re: Fixing C

#70

Post by ArkyBeagle »

pjc50 wrote: post #63
okasaki wrote: post #18

Earlier quoted context omitted.

Good news. Arrays have sizeof(arr)/sizeof(arr[0]) elements and strings have strlen(str) letters.

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