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

Two types of C programmers

utcc.utoronto.ca

Post reply on HN
Print view View original

131–140 of 225 posts

Re: Two types of C programmers

#131

Post by kragen »

tialaramex wrote: post #123
kps wrote: post #98

C programmers are implicitly converted to the required type. Implicit conversions are one thing I don't like about C, or at least the way it ended up as int grew (maybe it would have been better if ANSI had picked unsigned-preserving, but maybe that's just grass-is-greener thinking). I also don't like how UB turned into “a license for the compiler to undertake aggressive optimizations that are completely legal by the…

> I also don't like how UB turned into “a license for the compiler to undertake aggressive optimizations that are completely legal by the committee's rules, but make hash of apparently safe programs.” You can have a language where all the behaviour is defined but in my experience most programmers who whine about this in C are just as unhappy because what they actually wanted was DWIM. In a language with defined behav…

4u - 5u is not undefined behavior in c; unsigned arithmetic overflow is defined to wrap around, in both directions

assigning -1 to an unsigned variable has never been undefined behavior either, but implementation-defined behavior (see §6.2.1.2p3 in iso c90 or §6.3.1.3 in c99 and c11); decent compilers like gcc define it to do the obviously correct thing (see https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.h...), not produce mysterious program behavior. in the new c++20 standard it's no longer even implementation-defined, but fully define behavior in the standard, but in standard c it's still implementation-defined

as a programmer who whines about the kind of ub exploitation at issue here, and who (as established above) has a much clearer idea than you do of what behavior is and is not defined, specifically what i am whining about is that it's harder to debug my code if doing things like dereferencing a null pointer doesn't reliably crash it, but instead triggers the silent removal of apparently unrelated logic from my program, or subtle semantics changes in it, in the name of optimization

also it sucks to have existing security-sensitive code acquire new security holes, and i don't really care if that's a learning opportunity for the guy who wrote it 20 years ago

this didn't happen 20 or 30 years ago, and in those 20 or 30 years the impact of introducing fresh security holes into existing well-tested c code has greatly increased, while the usefulness of c compiler optimizations has greatly decreased

Re: Two types of C programmers

#132

Post by gavinhoward »

tialaramex wrote: post #130
kps wrote: post #104

Earlier quoted context omitted.

> it's not possible for human beings to write correct C code It's not possible for human beings to write correct code. The hardest bug I ever found in a C program, one that took cumulative weeks of work until a tractable reproduction was found, came down to a ‘ Yes, different languages have different levels of expressiveness, and can preclude or expose different kinds of errors. You'll never have a stray pointer in P…

I assume this was a logic error, that is, the code as written was a valid C program that didn't do what you meant. In that case this could have been caught with more careful unit tests, which would have exercised the erroneous condition, and potentially with fuzzing to excite corner cases. C is... not great for either of these.

I don't know why you say that C is bad for exercising error conditions or fuzzing. In my experience, it's the best at those.

Re: Two types of C programmers

#133

Post by kps »

tialaramex wrote: post #123
kps wrote: post #98

C programmers are implicitly converted to the required type. Implicit conversions are one thing I don't like about C, or at least the way it ended up as int grew (maybe it would have been better if ANSI had picked unsigned-preserving, but maybe that's just grass-is-greener thinking). I also don't like how UB turned into “a license for the compiler to undertake aggressive optimizations that are completely legal by the…

> I also don't like how UB turned into “a license for the compiler to undertake aggressive optimizations that are completely legal by the committee's rules, but make hash of apparently safe programs.” You can have a language where all the behaviour is defined but in my experience most programmers who whine about this in C are just as unhappy because what they actually wanted was DWIM. In a language with defined behav…

The original intent was that “Undefined behavior gives the implementor license not to catch certain program errors that are difficult to diagnose.” If you wrote ‘a + b’, you could expect your hardware's add instruction, and if that happened to trap on overflow, that wasn't the compiler's fault.

Re: Two types of C programmers

#134

Post by fsckboy »

cat_plus_plus wrote: post #94
galaxyLogic wrote: post #18

Earlier quoted context omitted.

Good points. I like C, I think simplicity and hardware alignment make it very useful. Simplicity wins in the end.

C is not aligned with modern hardware and optimizing compilers are severely hampered by things like undeclared pointer aliasing.

so then, add a declarator or two to solve the problem, don't just throw the baby out with the bathwater. The population of C programmers who understand how C works is the population of people who can understand how hardware works. The reverse has never been true, hardware designers have never understood software, and academic software experts have spent too much time babysitting college freshman who can't code and spend all their time dreaming about languages that freshmen could learn well enough to TA the course. But that's probably not a language good enough for systems programmers to adopt.

Re: Two types of C programmers

#135

Post by rileymat2 »

tonyedgecombe wrote: post #8

It's interesting that C has managed to remain relatively stable whilst everything else has ballooned in size. I spend most of my time writing C# and it has become quite large. I wouldn't want to pick it up from scratch now.

At the same time, people have expectations for ability now.

A beginner might want to make a web request, good luck doing anything beyond mimicry with C from code samples if they get that far.

With python, they could pull it off quickly.

Re: Two types of C programmers

#136

Post by williamcotton »

preseinger wrote: post #96
williamcotton wrote: post #23

C with libdispatch and clang blocks is the most fun I’ve had programming in quite some time! Here’s a web framework (complete with ORM) modeled on ExpressJS written in C: https://github.com/williamcotton/express-c The finished product is There’s also a lot of examples of the (basically required) support tooling like Valgrind, AdSan, etc. Check it out!

this project makes assumptions about received input (specifically encoding) which aren't guaranteed fine for a toy project, not something that can be used in anger

Are you referring to the req->sendf as seen in the README?

Yeah, I definitely wouldn’t use that approach for user input! There’s also support for mustache templates and JSON-API endpoints as well.

Or are you referring to something else?

But yes, please don’t use this for anything serious!

Re: Two types of C programmers

#137

Post by winrid »

preseinger wrote: post #99
winrid wrote: post #32

Earlier quoted context omitted.

It looks cool. The DB library is appreciated. However, you would get about the same idle memory and docker size with Go's Fibers framework :)

go-fiber is a weird, non-idiomatic, and non-serious project, fine for a proof of concept, but definitely not something anyone should be using in prod but your point is sound, any reasonable go http server will have the same level of memory usage at idle

Wow, really? The project has 25k github stars and 300 contributors. They are on v2.44. Why is it not serious? What makes any software "serious" to you?

Re: Two types of C programmers

#138

Post by fsckboy »

kps wrote: post #98

C programmers are implicitly converted to the required type. Implicit conversions are one thing I don't like about C, or at least the way it ended up as int grew (maybe it would have been better if ANSI had picked unsigned-preserving, but maybe that's just grass-is-greener thinking). I also don't like how UB turned into “a license for the compiler to undertake aggressive optimizations that are completely legal by the…

> C programmers are implicitly converted to the required type.

stop trying to coerce me

Re: Two types of C programmers

#139

Post by worthless443 »

> They feel strongly drawn to C's virtues, often explicitly in contrast to other languages

Can someone point me to which set of virtues you are talking about here? Simplicity? Value semantics and imperatives, little abstractions over what the computer OS is actually doing? Manual control over almost everything being done? Are such "virtues" safe and dignifying under an universal context of computer programming? Isn't it a bit dangerous to let such Virtues take over in modern programming dealing with heavy abstraction layers because of the yield in complexity of modern hardware?

Re: Two types of C programmers

#140

Post by preseinger »

asveikau wrote: post #129
preseinger wrote: post #91

Earlier quoted context omitted.

it's not possible for human beings to write correct C code, measured over time this is not a controversial statement, it's the clear conclusion from any evaluation of available evidence it's fine that you like messing with assembler, but you can't do that safely -- if the programs you write don't need to be correct then carry on, but if they do need to be correct, then you have a professional obligation to use a high…

What you mean to say is you have no shot at correct C, and so the language scares you, and you believe since you can't do it nobody does. It's true that the community at large writes lots of bugs. But that doesn't mean some people aren't productive with the language and write a relatively low number of bugs. There are some projects with better track records at this than others.

no, that is not what i mean to say

at scale, it is not possible for humans to hand-write C programs that are free of segmentation fault class errors

this is not controversial or in any way arguable

Post reply on HN