61–70 of 174 posts
Or rather, given that every relevant C compiler is also a c++ compiler, just compile as c++ and use std::unique_ptr? I love C but I just can't understand the mental gymnastics of people that prefer this kind of hacks compared to just using C++
Earlier quoted context omitted.
For me, the point of writing something in C is portability. There were C compilers 30 years ago, there are C compilers now, and there will almost certainly be C compilers 30 years from now. If I want to write a good, portable library that's going to be useful for a long time, I'll do it in C. This is, at least, the standard in many gamedev circles (see: libsdl, libfreetype, the stb_* libraries). Under that expectatio…
The bad news is that C23 broke a lot of existing code[1]. We had to do a lot of work in Fedora to fix the resulting mess. [1] https://gcc.gnu.org/gcc-15/porting_to.html#c23
I would consider the union initializer change (require adding -fzero-init-padding-bits=unions for old behavior) much more hidden and dangerous, which is not directly related to ISO C23 standard.
Earlier quoted context omitted.
> relying on compiler vendor extensions kind of defeats the purpose of that. Let's be honest, how many compilers are available, and how many of those would you actually use? The answer isn't more than 4 and the 2 compilers you are most likely to use among those already support this and probably won't stop supporting without a good alternative. I like standardisation, but you have to be realistic when it helps you wit…
If this is the argument then the actual standardisation is useless. I primarily use windows so I’m affected by one of the major compilers that doesn’t support this feature. This is no different to saying “chrome supports feature X, and realistically has y% market share so don’t let the fact that other browsers exist get in the way”. Call it a posix extension, fair enough. But if your reason for writing C is that it’s…
It's the same thing with the web and browser vendors, there's a constant mismatch, browsers propose and implement things and they may get standardized, and the standard dictates new requirements which might get implemented by all vendors.
The point of standardisation is defining behaviour for the things that are implemented as exploratory improvements and should be implemented on the more conservative compilers.
It's your choice whether to target the standard or a few selected compilers, there's a cost for both options between being late to improvements vs the possibility of needing to revisit your code around each of the "extensions" you decided to depend on.
If in certain projects portability is somehow of upmost importance, then any discussion around looking through the standard's black box to reach out for new stuff is kind of useless.
Earlier quoted context omitted.
> relying on compiler vendor extensions kind of defeats the purpose of that. Let's be honest, how many compilers are available, and how many of those would you actually use? The answer isn't more than 4 and the 2 compilers you are most likely to use among those already support this and probably won't stop supporting without a good alternative. I like standardisation, but you have to be realistic when it helps you wit…
There are quite a lot of embedded code that relies on obscure C compilers created and maintained by the CPU manufacturer. But then again you are probably not doing a whole lot of heap management in embedded code.
[flagged]
We have 50 years of experience of code telling us that, no, programmers are not consistently capable of avoiding memory safety just by being good about it. Saying that it's just a failing of lesser programmers is the height of extreme arrogance, since I guarantee you that you've written memory safety vulnerabilities if you've written any significant amount of C code. The problem is not that the rules are hard to foll…
I still follow KISS, and if you're writing 600+ line functions, it is little surprise you forget things in the tightly written logic of code.
Earlier quoted context omitted.
What do you mean defer isn't scope based in Go? (not super experienced Go developer)
In Go, defers are function scoped not block scoped.
Adding `func() {}()` scopes won't break existing code usually, though if you use 'break' or 'continue' you might have to make some changes to make it compile, like so:
https://go.dev/play/p/_Gq4QYtyMmp
see, no other issues, works exactly like you'd expect
Earlier quoted context omitted.
> we hope will be added to the C spec one day defer seems to be making significant progress (having a passionate and motivated advocate in Meneide, and a full TS)
Last time I looked this was (golang-like) function scoped, not { } scoped, which means it's a bad idea. My feedback was the committee should simply standardize the existing attribute / behaviour, as that is widely used already. (EDIT: I'm wrong, see reply)
Might have been the previous attempt from years ago, because being block scoped (unlike go) literally has its own section in https://thephd.dev/c2y-the-defer-technical-specification-its...
Earlier quoted context omitted.
The bad news is that C23 broke a lot of existing code[1]. We had to do a lot of work in Fedora to fix the resulting mess. [1] https://gcc.gnu.org/gcc-15/porting_to.html#c23
For the cases in linked doc, does adding -std=gnu17 to packages not suffice? I would consider the union initializer change (require adding -fzero-init-padding-bits=unions for old behavior) much more hidden and dangerous, which is not directly related to ISO C23 standard.
[flagged]
We have 50 years of experience of code telling us that, no, programmers are not consistently capable of avoiding memory safety just by being good about it. Saying that it's just a failing of lesser programmers is the height of extreme arrogance, since I guarantee you that you've written memory safety vulnerabilities if you've written any significant amount of C code. The problem is not that the rules are hard to foll…