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

The Unreasonable Effectiveness of C

damienkatz.net

Post reply on HN
Print view View original

341–350 of 394 posts

Re: The Unreasonable Effectiveness of C

#341

Post by chacham15 »

Locke1689 wrote: post #187
xyzzy123 wrote: post #178

Earlier quoted context omitted.

I'm a professional pentester and I have been a C programmer for over well over 5 years, but I acknowledge that my C is probably still pretty bad :) how about you? :) P.S: now I have figured you out (on a very basic level of course) and I have a lot of respect, but nonetheless, let's play :)

I've been writing kernel code in C for about 8 years, including a hardware virtualization subsystem for use on HPCs. I used to teach Network Security and Penetration, but I lost interest in security and moved on to programming language development. My code, in any language, is full of bugs. The difference is that in C my bugs turn into major security vulnerabilities. C is also a terrible language in that you never wr…

I think that your situation is pretty different from most programming projects in that you are way closer to the machine than most people need to be. Also, you are working on an OS which is particularly sensitive to compiler nuances. I would have a hard time imagining different compilers spitting out garbage with the standard "hello world". Now the almost mandatory caveat: I know that C has its flaws, but not all programming projects are the same. Projects which are not like your will have the "You write a specific compiler's implementation of C" problem in way smaller doses than you (possibly to the point of not having them at all, like hello world).

Re: The Unreasonable Effectiveness of C

#342

Post by carterschonwald »

w3pm wrote: post #286
michaelochurch wrote: post #188

Earlier quoted context omitted.

Fair point. At this point, it's a very leaky abstraction because not all levels of "random access" (e.g. L1 cache vs. main memory) are created equal.

True, and this is my biggest problem with writing optimized code in C -- it takes a lot of guessing and inspecting the generated assembler and understanding your particular platform to make sure you're ACTUALLY utilizing registers and cache like you intend. If there were some way of expressing this intent through the language and have the compiler enforce it, that'd be fantastic :) That said, there's really not a bet…

i'm actually spending much of my time these days having a go writing HPC codes in haskell.

So far, the generated assembly looks pretty darn awesome, and the performance pretty competitive with alternatives i have access too :)

Re: The Unreasonable Effectiveness of C

#343

Post by eugenejen »

geophile wrote: post #155
slurry wrote: post #148

Earlier quoted context omitted.

> Ignoring pre-history (BASIC, FORTRAN, PDP-11 assembler, Z80 assembler, Pascal) A side effect of C universalization, especially with open source, is that people forget all about that pre-history. Hacker culture now is mostly C/Unix with a dash of Lisp and Smalltalk heritage. But from what I remember of microcomputer culture in the early 80s, hackers in the field were doing line-numbered Basic and Assembly language -…

SNOBOL. I loved SNOBOL. A completely bizarre, very powerful language. I took two wonderful compiler classes from R. B. K. Dewar, who worked on the Spitbol implementation. He was also involved with the SETL language, which really impressed me.

And setl influenced ABC, then Python

Re: The Unreasonable Effectiveness of C

#344

Post by zvrba »

ehaliewicz wrote: post #339
zvrba wrote: post #288

Earlier quoted context omitted.

> OO buzzwords and programming fads that come and go in "higher-level languages" simply end up making a bigger mess of things as a project grows No, it's not the language features which make a mess. It's people lacking judgement and common sense. (Like, trying to apply patterns everywhere. Been domain-specific [crypto] consultant on such a project and watched it smash the schedule by more than 2x. It wasn't the langu…

In scheme, argument evaluation order is not specified. So, (pretending that set! returns the assigned value), (f (set! x (+ 1 x)) (set! x (+ 1 x)) ) is undefined and unpredictable as well. I don't think anyone would claim Scheme isn't high level.

"Undefined behavior" in C is much more insidious than merely "unspecified" or "unpredictable". All those security holes and exploits resulting from buffer overflows, stack overwrites, heap spraying, etc. are manifestations of UB made possible by a badly written program. (Or by the interaction between an invalid program and an optimistic compiler, as in the case of assuming strict pointer aliasing.)

Re: The Unreasonable Effectiveness of C

#345

Post by linuxhansl »

C is a fine language. So is Java, and so are Python, Perl, Javascript, as well as Lisp and Scheme.

Saying C is always effective without further qualification is like saying that high speed racing cars are always effective. You need vans, trucks, bulldozers, etc, etc.

Then there is the question of what is really meant by "effectiveness". Is the code execution speed, maintainability, collaboration, compile-execute cycle, extensibility, etc?

As always, it depends on what you want to do. In many cases C is the most logical choice. But in other case Java or other languages get the job done more "effectively".

Anybody who is limiting him/herself to a single language to "rule them all" is certainly not effective.

Edit: Usual spelling mistakes.

Re: The Unreasonable Effectiveness of C

#346

Post by sampo »

stephencanon wrote: post #106
madhadron wrote: post #53

Oh for heavens' sakes. Yet more ignorance. A more realistic view of C: - C is straightforward to compile into fast machine code...on a PDP-11. Its virtual machine does not match modern architectures very well, and its explicitness about details of its machine mean FORTRAN compilers typically produce faster code. The C virtual machine does not provide an accurate model of why your code is fast on a modern machine. The…

Fortran compilers sometimes produce faster code for a limited subdomain of problems because fortran's language semantics are less restrictive: all arrays are assumed to not alias and the compiler has more freedom to reassociate arithmetic and apply other unsafe arithmetic transformations that are disallowed by C's stricter model. C compilers let you specify that you want similarly relaxed semantics via compiler flags…

Also in Fortran you can get aliasing pointers, if you ask for it (mark the pointed variables or arrays as 'target').

Re: The Unreasonable Effectiveness of C

#347

Post by ericdschmidt »

betterunix wrote: post #236
xyzzy123 wrote: post #207

Earlier quoted context omitted.

Um. Read Bentley. Get back to me. Yesterday's old shit is last week's high level. Turns out clear thought in any language is the main thing.

"Turns out clear thought in any language is the main thing." No, the ability to express your thought clearly is the main thing -- and that is why languages matter. If your code is cluttered with pointer-juggling, error-checking conditional statements, and the other hoops C forces you to jump through, then your code is not clear. Try expressing your code clearly in BF, then get back to me about this "languages don't m…

Can both of you guys just get back to me later? Kinda busy now.

Re: The Unreasonable Effectiveness of C

#348

Post by chj »

emeraldd wrote: post #271
dspeyer wrote: post #192

Earlier quoted context omitted.

int i; float f = *(float*)&i; I'm not saying you should do this, but you can. Or to use an example the author didn't regret: struct foo { int a; int b; int c; }__attribute__((packed)); void print(foo* f) { int *p = f; int i; for (i=0; i

Here's one I used in a GC implementation a while back. That last 'uint_8t obj[]' is used to hold the object that was actually allocated. struct meta_obj { meta_obj_type *next; // next object in our list mark_type mark; size_t size; gc_type_def type_def; uint8_t obj[]; // contained object }; Or another (contrived) example: struct obj_type { obj_type_enum type; }; struct string_obj_type { obj_type_enum type; char *c; }…

Is this standard? I mean the unknown size field 'obj'.

Re: The Unreasonable Effectiveness of C

#349

Post by eru »

georgeorwell wrote: post #316
groby_b wrote: post #234

Earlier quoted context omitted.

Can't upvote this enough. Well, except that I'd replace "poorly" with "vaguely". "Implementation-defined behavior" is there for very good reasons in every single case it's there. Sidenote: With John's name, I'd be tempted on a daily basis to change the last two letters of my name to a single 'x' ;)

You mean like this? $ whoami | sed 's/hr/xx/'

No, he meant:

    $ whoami | sed 's/hr$/x/'

Re: The Unreasonable Effectiveness of C

#350

Post by pjmlp »

andrewcooke wrote: post #331
pjmlp wrote: post #246

Earlier quoted context omitted.

Yes. There are lots of refactorings that cannot be done by simple search and replace, even for C, because they require semantic knowledge of the language.

you know that the c/c++ plugin for intellij is broken? so what are you using that is smart enough to parse and refactor c? (serious question as i've had to switch to eclipse).

I seldom use C or C++ nowadays and when I do it is only C++.

I rarely do IDE refactorings when in C/C++ because of what you state.

QtCreator and CDT do offer some nice things, although still far from what is possible in another languages.

If JetBrains produced a proper C/C++ IDE I would probably buy it for C++ work.

Post reply on HN