Earlier quoted context omitted.
Thankfully the ongoing cybersecurity laws will change that mindset.
No, I don't think they will.
You will be surprised.
https://www.eff.org/deeplinks/2023/05/eus-proposed-cyber-res...
Neverflow: C macros that guard against buffer overflows
101–110 of 150 posts
Re: Neverflow: C macros that guard against buffer overflows
#102Earlier quoted context omitted.
So it was worth your time to reply twice, but not to explain anything?
Yes, because I don't expect you to understand anyway and ELI5 would take a bit, much longer than these dumb comments. Hint, someone else got it.
I'm starting to think you didn't understood the message or you wouldn't be avoiding explaining yourself while trying to insult people.
Re: Neverflow: C macros that guard against buffer overflows
#103Earlier quoted context omitted.
No, I don't think they will.
You will be surprised. https://www.eff.org/deeplinks/2023/05/eus-proposed-cyber-res...
None of this is going to meaningfully impact C/C++ software. If it comes to pass at all, it'll be used at the margins to replace more C code with Rust.
Re: Neverflow: C macros that guard against buffer overflows
#104Earlier quoted context omitted.
People using C will not change to your language-du-jour, please stop.
> People using C will not change to your language-du-jour, please stop. Two years ago, your argument would have implied that Rust would never be allowed into the Linux kernel, and yet here we are.
There are all kinds of weird stuff in the kernel, many of them will just die.
Re: Neverflow: C macros that guard against buffer overflows
#105Earlier quoted context omitted.
One common trick in safer C libraries is to encode the length of the string one word prior to the beginning of the string. So "hello world" in memory would be 11 'h' 'e' 'l' 'l' 'o' ' ' 'w' 'o' 'r' 'l' 'd' '\0' ptr ^ C could be upgraded to do this in future versions, without too much backwards incompatibility.
> C could be upgraded to do this in future versions, without too much backwards incompatibility. But I'd hope that doing that would always be optional. There are numerous situations where that would seriously get in the way.
Could you mention one of them?
Re: Neverflow: C macros that guard against buffer overflows
#106The following error prone: it can be mistakenly applied to a pointer: #define LEN(NAME) (sizeof NAME / sizeof( NAME)[0]) I think gcc has a warning for this pattern now: when the size of a pointer is divided by the size of its referent type. More importantly, it has an odd extra level of indirection. The traditional definition is: #define LEN(ARRAY) (sizeof ARRAY / sizeof (ARRAY)[0]) This means that to use LEN on an a…
It's so funny, but i actually had this in 0.0.1 for exact same reason. I removed it in 0.0.2 today after complains that it complicates things and a bit confusing. It made harder to pass VLAs to functions. Maybe if i find a better way i will return name mangling again, but for now being able to pass arrays to functions and maintain same flexibility is more important imo
Re: Neverflow: C macros that guard against buffer overflows
#107Earlier quoted context omitted.
> People using C will not change to your language-du-jour, please stop. Two years ago, your argument would have implied that Rust would never be allowed into the Linux kernel, and yet here we are.
There are all kinds of weird stuff in the kernel, many of them will just die.
What other programming languages are used in Linux kernel code?
Re: Neverflow: C macros that guard against buffer overflows
#108Earlier quoted context omitted.
> C could be upgraded to do this in future versions, without too much backwards incompatibility. But I'd hope that doing that would always be optional. There are numerous situations where that would seriously get in the way.
Could you mention one of them?
Sure. For instance, there are times when you need to pack strings tightly together. Adding an extra byte or two before the start of the string would get in the way. You could work around it in many cases, but it makes the code uglier and harder to understand/maintain.
One of the things that makes C particularly suitable for certain sorts of tasks is that it's mostly WYSIWYG when it comes to the relationship between data structures and the actual memory layout. Having "hidden" things like a length value before the string steps on that.
Re: Neverflow: C macros that guard against buffer overflows
#109Earlier quoted context omitted.
Those are syntactic sugar for the same thing though. Array[5] is just shorthand for *(Array + 5), which is why 5[Array] also works (because addition is commutative). Note that C does have strong conventions, such as that strings are terminated by a zero byte. Nothing in the language demands that, it’s just a convention! C could adopt better conventions.
> Note that C does have strong conventions, such as that strings are terminated by a zero byte Stated the same on HN earlier, but someone pointed out that literal strings are ASCIIZ.
> literal strings are ASCIIZ.
If only. In C, it’s a (95+5)-item character set that happens to be a subset of ascii. See https://en.cppreference.com/w/c/language/charset:
“The basic literal character set consists of all characters of the basic character set, plus the following control characters”
That page also explicitly says:
The following characters are not in basic execution character set, but they are required to be encoded as a single byte in an ordinary character constant or ordinary string literal.
Code unit Character Glyph
U+0024 Dollar Sign $
U+0040 Commercial At @
U+0060 Grave Accent `”*
Of course, C++ is different. Like C, it makes a distinction between the encoding of source files (nowadays called the “basic character set”) and the encoding that the compiler converts literals to (nowadays called the “basic literal character set”), but it seems to put even fewer restrictions on them (in my cursory reading)
Also (https://en.cppreference.com/w/cpp/language/charset):
“Mapping from source file (other than a UTF-8 source file) (since C++23) characters to the basic character set (until C++23) translation character set (since C++23) during translation phase 1 is implementation-defined, so an implementation is required to document how the basic source characters are represented in source files.”*
If I understand that correctly, you can’t portably write an euro sign in C++ source files in C++ foe C++23
Also, chances are this changed in subtle ways between C and C++ versions.
Re: Neverflow: C macros that guard against buffer overflows
#110Earlier quoted context omitted.
If one is ready to switch languages, then the clear winner is rust over C++, and I say that as someone who avoided diving into Rust for years because it seemed completely overhyped and with too much cryptic syntax. C still wins by far when writing libraries that will be used by lots of other people. Doesn't matter what language they are using, they will be able to add in a library written in C very easily. However, C…
Availability of C++ tooling is much, much closer to availability of C tooling (often it's the same tool!) compared to Rust. Adopting Rust isn't the same category of conversion at all. For new side projects, pick what you want to use of course. But for existing codebases and projects that aspire to have maximum impact, I recommend fully considering tradeoffs instead of thinking in terms of "clear winners".
This is nonsense. Rust is based off of LLVM, which is what Clang is based off of. Name one modern, actually used, non-archaic system that LLVM doesn't run on. Beyond that, Cargo and all associated tooling run pretty much everywhere. So I'm not sure what outdated trope you're on about here.