tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Many new warnings since yesterday


From: Thomas Preud'homme
Subject: Re: [Tinycc-devel] Many new warnings since yesterday
Date: Fri, 15 Feb 2013 11:03:29 +0100
User-agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )

Le vendredi 15 février 2013 07:11:58, Christian Jullien a écrit :
> Yesterday, Grischka applied my patch to remove last warning (thanks
> Grischka), tcc compiled with NO warning at all.
> 
> This morning, with no changes on my config (same compiler, same options,
> same script to fetch mod and compile), I get many more warnings on RPi as
> well as on Fedora 18 x86_64

I'm curious to see what warning you have on Fedora. I don't have any on Debian 
x86_64.

> 
> Please note that RPi uses default unsigned char which is different than
> x86, so sign warnings may be annoying

I know :)

> 
> To me, a release build should be warning free. Warning free does not mean
> that build is free of ALL possible warnings (for example using extra -Wxx,
> using llvm or splint - I recommend splint) it means release manager is
> aware of suspicious code and either, by order of priority:
> 
> - fix it
> - patch it in order to make build happy
> - remove offending warning flag for release (and reintroduce this flag in
> trunk right after the official release)

I'm sorry but I disagree. Trying to fix these bugs now might result in 
breakages and would delay the release longer. Trying to make the perfect 
release might lead us to delay by many months at best, or never release in the 
worst case. There is still several things broken: variadic function are 
unusable with libgcc for instance.

Yes you're right, warning indicates possible coding errors but there is also 
false positive. Hence we should definitely look at these warnings and fix what 
is programming error and leave the other ones. Masking them (with compiler 
switch) would also mask other legitimate warnings so it's better to let false 
positive be reported and hope for static analysis in compilers to improve.

In other words, I suggest we look (you're welcome to look at it yourself if 
you want things to be fixed faster) at it just after the release and target 
another release not so long time from now. It would be nice to have a release 
a year I think. It would allow for fixes to flow in stable release faster.

> 
> Btw, I don't see what recent change produces those new warnings.

Me neither.

Thomas

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]