Deutsch   English   Français   Italiano  
<v4rjs8$19f9c$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Tue, 18 Jun 2024 11:26:32 +0200
Organization: A noiseless patient Spider
Lines: 75
Message-ID: <v4rjs8$19f9c$1@dont-email.me>
References: <v494f9$von8$1@dont-email.me>
 <v49seg$14cva$1@raubtier-asyl.eternal-september.org>
 <v49t6f$14i1o$1@dont-email.me>
 <v4bcbj$1gqlo$1@raubtier-asyl.eternal-september.org>
 <v4bh56$1hibd$1@dont-email.me> <v4c0mg$1kjmk$1@dont-email.me>
 <v4c8s4$1lki1$4@dont-email.me> <20240613002933.000075c5@yahoo.com>
 <v4emki$28d1b$1@dont-email.me> <20240613174354.00005498@yahoo.com>
 <v4okn9$flpo$2@dont-email.me> <v4p37r$k32n$1@dont-email.me>
 <v4pei3$m5th$2@dont-email.me> <v4plsk$nn9o$2@dont-email.me>
 <v4pnq6$o4fs$1@dont-email.me> <v4qi7g$vnuv$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 18 Jun 2024 11:26:33 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="000ac22a82b477e7b73d30c4bbbc814d";
	logging-data="1359148"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+64+PrugamB34ds0wq2nbX2p/AcROYbQM="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:OFvbd1siZvRSLqJHpH+DFgM46kg=
In-Reply-To: <v4qi7g$vnuv$1@dont-email.me>
Content-Language: en-GB
Bytes: 5389

On 18/06/2024 01:52, James Kuyper wrote:
> On 6/17/24 12:21, David Brown wrote:
> ...
>> Having a distinction in optimisation between "debug" and "release"
>> builds is simply /wrong/.  Release what you have debugged, debug what
>> you intend to release.
> 
> I fully agree that you should debug what you intend to release; but I
> can't agree that it always makes sense to release what you've debugged.
> There are ways to debug code that make it horribly inefficient - they
> are also good ways to uncover certain kinds of bugs. 

Yes, as I said I sometimes change things while chasing particular bugs - 
with sanitizers mentioned as an example.  And I might compile a 
particular file with low optimisation, or disable particular 
optimisations to make debugging easier.

Most often, I do this with additions to the source code in question - 
marking some functions as "noinline" (a gcc attribute) to make 
breakpoints easier, or marking some variables as "volatile" to make it 
easier to see them with a debugger, or simply adding some extra 
printf's.  You do what you need to do in order to find the bugs, and how 
you do that depends on the bugs and the type of tools you use and the 
kind of program you have.  But I do not change the rest of the build.


Of course it is correct in a sense that you don't release what you 
debug, because you debug code that is not working, and you don't release 
it until it is fixed!

But you should not (IMHO) be using special debug modes for the main part 
of your debugging and testing, you should be aiming to have as realistic 
a scenario as you can for the code.  While optimisation does not change 
the effect of correct code (other than perhaps different choices for 
unspecified behaviour), few programmers are perfect.  Sometimes code 
errors will, by luck, give the desired behaviour with no optimisation 
but erroneous behaviour with high optimisation.  I have no interest at 
all in having my code pass its tests with -O0 and fail with -O2 - I want 
to go straight to seeing the problem.


> There should be a
> debug mode where you enable that inefficient code, and track down and
> remove any bugs that you find. Then you go to release mode, and test it
> as thoroughly as possible with the code as it is intended to be
> released, which is never as much can be possible in debug mode. Do not
> release until the final version of the code has passed both sets of
> tests. If release testing uncovers a bug that requires a code change,
> that means that debug testing also needs to be redone.

There are different development strategies appropriate for different 
types of program, and different types of development teams.  Splits 
between development, debugging and testing can vary.


Perhaps my attitude here is unusual, and due to the type of work I do. 
For me, a "project" consists of all my own source code, all the 
libraries, headers, microcontroller SDK's, all the third-party source 
code, the build process (normally a makefile and often a few scripts, 
including all compiler flags), the toolchain, and the library.

The binary that goes into the product is thus entirely reproducible.  I 
don't deliver a collection of C files to the customer, I provide the 
whole build system - and the code is debugged, tested and guaranteed 
only with that toolchain and build settings.  It is important that if 
the customer finds a problem years later, I am working with /exactly/ 
the same binary as was delivered.

Of course I try to make the code as independent of the details of the 
toolchain, libraries and SDK's as reasonably possible, and I will move 
over to new versions if appropriate - but that means full re-testing, 
re-qualification, and so on.