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

81–90 of 123 posts

Re: Fixing C

#81

Post by hatsunearu »

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…

howto-c has a bunch of problematic opinions which aren't liked by the community. The crap about never using ints, longs, etc has been debunked over and over.

Re: Fixing C

#82

Post by jandrese »

mfukar wrote: post #38
veli_joza wrote: post #30

Earlier quoted context omitted.

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.

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

That's because C tosses out all of that array state information at the drop of a hat once you start passing them around to functions.

Worse, it's an easy way to get burned on the sizeof() function, especially if you at some point refactor the code and put that chunk in a function separate from the original declaration.

This is why C programmers get gunshy about relying on that information and instead just treat strings like pointers all of the time.

Re: Fixing C

#83

Post by noir_lord »

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.

If different people keep chopping into themselves with a power tool it's probably wise to consider a safety guard.

Re: Fixing C

#85

Post by Terribledactyl »

nkurz wrote: post #76
Terribledactyl wrote: post #69

Earlier quoted context omitted.

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

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

Re: Fixing C

#86

Post by Terribledactyl »

rkangel wrote: post #75
Terribledactyl wrote: post #69

Earlier quoted context omitted.

#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 i…

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.

Re: Fixing C

#87

Post by ludamad »

bpchaps wrote: post #74
paulddraper wrote: post #67

Earlier quoted context omitted.

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

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

Re: Fixing C

#88

Post by gdwatson »

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.

Re: Fixing C

#89

Post by gravypod »

Ace17 wrote: post #84

C's biggest mistake: http://www.drdobbs.com/architecture-and-design/cs-biggest-mi...

That would fix so many errors and the notation is extremely simple.

That's definitely the best idea I've seen.

Re: Fixing C

#90

Post by dcohenp »

I'm gonna go with Tony Hoare here and say if I could pick just one it'd be NULL pointers.

(Braces though? Really?!?)

Post reply on HN