Re: C23 thoughts and opinions

On 6/14/2024 1:53 AM, Bonita Montero wrote:

Am 13.06.2024 um 21:07 schrieb BGB:
 

A lot of people release debug builds but with the debugging data absent (say, to try to reduce risk of decompilation and similar).

 I don't believe that since this code isn't optimized and much larger.
 

For many programs, a binary that is 5x the size and half the speed, may go unnoticed.
Like, how many users will notice the difference between a 1MB EXE and a 5MB EXE?...
And, if the program isn't CPU bound, users may not notice that the code runs more slowly...

One possible justification (albeit a weak one) is that if one recompiles the program with optimizations turned on, in many cases this may subtly change the behavior of the program (particularly in relation to things like the contents of uninitialized variables and dangling pointers, etc...). ...

 If you rely on that you're misusing the language anyway.
 

It is a poor practice, but seemingly does occur in the wild (intentional or not).
If the code is poor, and debugging effort minimal, then having separate builds using "/O2" rather than "/Zi" or similar, may not be seen as worth the hassle or risk.
Generally the same types whose "debugging" strategy is to mostly fill the program with an ever increasing number of "make it work" hacks than to figure out why a bug has occurred and try to fix it properly.
Or, say where fixing all of its out-of-bounds memory accesses, makes substantive changes to the behavior of the program, which may or may not be seen as undesirable.
Like, for example, when I ported ROTT to my ISA project, I ended up fixing a "lot" of out-of-bounds memory accesses and similar. Some of these seemingly ended up changing fundamental aspects of the behavior of the 3D engine; but as a consequence causes the original demo files to desync and the demo desync issues are still not entirely resolved.
But, OTOH, I added a noclip cheat, and now one can use noclip to go outside the main playable part of the map without the engine immediately crashing (because, once the OOB issues were fixed, the world wraps on the edges, rather than raycasts which leave the map marching off into other parts of memory, ...).
But, for many people, the desync'ed demos would be seen as a bigger issue than the fix of the engine no longer crashing if one has a "noclip" and then goes outside main walls of the map.
Many people would more just care that some feature is broke, rather than to fix the feature ended up needing to untangle some edge case involving the relative interactions between integer overflow and implicit type promotion.
Say:
   int x, y;
   long z;
   z=x+y;
And, then finding the program broke if the compiler performed it as-if it were:
   z=((long)x)+((long)y);
Rather than:
   z=(long)(x+y);
In some edge-case where the addition of x and y caused a signed integer overflow.
Or, say, code which happens to only work a certain way because the function prototype was missing, but then "breaks" if the prototype in present (say, because the implicit int caused modulo behavior, but the proper version returns long and does not give a modulo answer, etc...).
Or, finding lots of code that breaks when built of ARM because of it treating "char" as unsigned by default, and which had an implicit dependency on 'char' being signed nu default.
All fixable, granted. But, sometimes, finding the bug is a lot harder than the fix itself.
...