Re: valgrind
>> But it's less a lack of interest and more an unwillingness to ignore >> the licensing issues. `Modern' GCC is licensed under the GPLv3. > try clang, which usually has newer/better sanitizers. clang is - or at least was last I checked - under the impression that nested functions are little-used and thus are not worth supporting. That may be - presumably is; the clang people are not stupid - correct as applied to the C ecosystem at large. It definitely is not correct as applied to my code. Unless/until they change their collective mind and implement nested functions, clang is a nonstarter for me. Also, at work, I had occasion to do a clang build-from-source. The resulting executables were multiple _giga_bytes: [Pavilion] 14> ls -l bin/clang-10 -rwxr-xr-x 1 root 2535346040 Aug 10 2020 bin/clang-10 That too is a showstopper for me. They're turned off at the moment, but I have two machines, one in live use when I'm working on what I set it up for and the other a live use desktop until COVID-19 put paid to my working outside my home, for which that one file would take up more than half the machine's total available disk space. I've been making very-spare-time progress on building my own compiler on and off for some years now; perhaps I'll eventually get somewhere. (It's something I want to do regardless; there are some directions I'd like to take the language to see what results) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
re: valgrind
> But it's less a lack of interest and more an unwillingness to ignore > the licensing issues. `Modern' GCC is licensed under the GPLv3. I try clang, which usually has newer/better sanitizers.
Re: valgrind
>> Perhaps I just need a better approach > I know you've previously expressed a lack of interest in such things > when we've talked previously, but I've found the built-in sanitizers > in modern GCC useful for approximating the functionality of valgrind > on NetBSD. To some extent, perhaps. But it's less a lack of interest and more an unwillingness to ignore the licensing issues. `Modern' GCC is licensed under the GPLv3. I have tried twice to understand that license and people tell me I've still missed major pieces. If I have to hire a lawyer to figure out the license, it's not suitable for my purposes - in my opinion not suitable for any open-source work, actually - no matter what it turns out to permit. (As this implies, my experience with valgrind has, of course, been entirely at work.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: valgrind
On Wed, Mar 09, 2022 at 08:39:06PM -0500, Mouse wrote: > Perhaps I just need a better approach I know you've previously expressed a lack of interest in such things when we've talked previously, but I've found the built-in sanitizers in modern GCC useful for approximating the functionality of valgrind on NetBSD. For example, -fsanitize=leak can log leaks at runtime.
