111–120 of 225 posts
Earlier quoted context omitted.
> In a word, simplicity. For fun, go to /usr/include and try to understand the system .h files.
This is why I've kinda built my own libc on the bare minimum that the system gives me. The POSIX and Windows API's are garbage; C the language is great.
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.
I am a C programmer. For me the language is a means to an end. I prefer to work on problems where both performance and code size is paramount. The kinds of problems where it makes economic sense to spend months or years of engineer time designing and implementing a solution that will compile to a 50kB binary. I think primarily about the kind of machine code I want to generate, and pick a language that best approximat…
I'd consider myself the former: I use C because it's the only viable option for what I'm doing - but most of the time it's nothing to do with C itself, but the various extensions and builtins of GCC. It's the inline asm, the control of registers, placement of code and data, control of inlining, etc, which are missing from all of the C "replacements". The replacements assume you are building a user application on top…
we don't have standard ABIs for either C or C++; we have conventions.
https://wiki.osdev.org/System_V_ABI
The System V ABI is closer to being a standard than some official standards are.
C++ gets odd with name mangling, but the platform's C ABI is typically the tune every other language must dance to for its FFI.
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…
> 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…
yet c code is inarguably more error-prone than basically any other language
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…
And yet C code runs the world. You might be right in theory but in practice C is the most successful programming language in history. At work we routinely deploy million+ lines of C in production running large international airlines and airports. And it works.
"it works" is factually not true, look at ~any CVE
Earlier quoted context omitted.
In fact, 10 in any base represents the base number.
Good point, but not in base 1.
Earlier quoted context omitted.
This is why I've kinda built my own libc on the bare minimum that the system gives me. The POSIX and Windows API's are garbage; C the language is great.
i have written a fair bit of code using the windows and posix APIs, and they are OK - what features of these, often written by talented programmers, do you despise so much?
Microsoft wrote "A fork() in the Road" [1] describing the problems with fork(), and they are right: fork() is too simple, it doesn't scale, it is inefficient, and error handling becomes next to impossible.
(In my code, I have the child process return exit codes from 255 on down for error handling. It assumes, probably wrongly but right enough, that most programs won't use those exit codes.)
But CreateProcess() has the exact opposite problem: it's too complex and limited because it takes a large, fixed set of arguments. It takes many lines of code to set up for it, and once you actually start the process, you have no control over it, which sucks if you need to do something with the new process that CreateProcess() cannot do on creation.
Windows does have ways of modifying running processes, which is great and sort of makes up for the limits, but heaven help you if you need to use one of those functions on the new process because you have no control. The only thing you can do is to suspend the start thread of the new process right away, do your thing to it, and resume the thread, praying that the new process hadn't created a new runaway thread before it was suspended.
(And all of that is not even mentioning that the Windows way of passing a command-line is to pass a string to be parsed, not a list of strings. My code has a function literally to take a list of strings and turn it into a Windows-compatible command-line string with all of the juicy backslashing that implies.)
The right API is in the middle: a zero-argument function to create a new, blank process (not a copy of the current process), but to create it in a suspended state, so you know it's not going to run away from you.
Then, you use Windows-style functions to change the process, before it even starts, to set it up. Once you're done, unsuspend it.
That end result gives you as much power as fork(), with the better scalability of CreateProcess(), and better ease-of-use than both. You could even have functions to map in a copy of the current process if you so wish, to implement fork() for process checkpointing!
In other words, talented programmers can implement things and make them work, yes, but it doesn't imply that they are good at design.
[1]: https://www.microsoft.com/en-us/research/uploads/prod/2019/0...
Earlier quoted context omitted.
> it's not possible for human beings to write correct C code, measured over time I don't disagree [1], but remember that Rust can be unsafe too. Async is not a panacea, and it's confusing. And the `unsafe` escape hatch is still unsafe. > you have a professional obligation to use a higher-level language, with stronger guarantees Oh? So we have professional obligations now? For FOSS? News to me. I don't get paid for my…
Ask any experienced C developer and they'd all say "I write excellent C compared to all C programmers out there."
Of course, feel free to judge for yourself.