On 08.08.24 05:32, Peter Hutterer wrote:
I feel fairly strongly about removing that warning, i.e. allowing declarations after statements. There's a reason all modern languages allow this. It makes the code clearer and less buggy in many instances, esp. in regards to variables that don't need to exist until various checks have been performed.
ACK. And I'm really in favor of - if some function is being touched anyways, such kind of cleanup should be done first. That way BTW the motivation behind many of the patches in my recent MRs, which are preparations for #1701 (which itself, in turn is preparation for even bigger things, like full multithreading, shmem transport, Xgallium, etc, etc, ...).
And it allows those variables to be initialized immediately, so one source of bugs less.
Actually, I'd even go futher and try to use scoped fields - or split out pieces into separate functions. And more stack instead of heap (yes, I know, some of my recent patches had been over eager here, because it's often hard to tell whether their sizes might be unbound or attacker- controlled ... if anybody has an idea for helpful compiler checks, just let me know)
Doubly so with __attribute__((cleanup)) but that's a conversation for another day...
Great idea ! If we can agree to use that, this would be a big help, also for many of my patches where I'm replacing malloc() by stack: those aren't really about the little penalty of malloc (that's just a nice colleteral use), but simplifying code flow, not having to care about memleaks risks. (an actual GC would be even better, but we're not there yet) Using __attribute__((cleanup)) plus a bit macro magic gives us a little taste of golang's defer. Is there any strong reason for not using it ? --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
