Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Fri, 14 Jun 2024 03:13:32 -0500
Organization: A noiseless patient Spider
Lines: 96
Message-ID: <v4gu5q$2q8qp$1@dont-email.me>
References: <v2l828$18v7f$1@dont-email.me> <v38of2$1gsj2$1@dont-email.me>
 <v39v87$1n7bk$1@dont-email.me> <20240530170836.00005fa0@yahoo.com>
 <v3a3k5$1ntrn$1@dont-email.me> <20240530180345.00003d9f@yahoo.com>
 <v3chc4$27uij$1@dont-email.me> <20240531161937.000063af@yahoo.com>
 <20240531162811.00006719@yahoo.com> <20240531164835.00007128@yahoo.com>
 <v3cldt$28n91$2@dont-email.me> <20240531173437.00003bee@yahoo.com>
 <v3d3ct$2b5sl$1@dont-email.me> <v3d97c$2c6ea$1@dont-email.me>
 <22r6O.5934$xPJ1.2590@fx09.iad> <v3t6nu$1liet$1@dont-email.me>
 <v3tlmo$1o860$7@dont-email.me> <v3vvph$27spv$1@dont-email.me>
 <v40hum$2err2$1@dont-email.me> <v40oqa$2fjig$1@dont-email.me>
 <v4enr5$28m3j$1@raubtier-asyl.eternal-september.org>
 <v4fg41$2dh69$1@dont-email.me>
 <v4gpdb$2pbb6$1@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 14 Jun 2024 10:14:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0c68b24bee81243abea4013a80cbc313";
	logging-data="2958169"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18dgWsKNIzOBG2eEWbPsTc2MujBwVzahG8="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:JXUknhcM7UpVnDmClAmugchjFEw=
In-Reply-To: <v4gpdb$2pbb6$1@raubtier-asyl.eternal-september.org>
Content-Language: en-US
Bytes: 5395

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.

....