This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Checking format specifiers (Was: Re: Support for %d$c format specifier in diagnostics.c)


> But we do check in doc patches without running the testsuite

No, we don't. That is, if you do you violate the check-in requirements.


> We want to detect the problems _and get them fixed upstream_ but the worst
> _time_ for them to be detected is just when the release is being spun.
> If the checking script can be used (a) by the translator, (b) by the
> Translation Project, (c) when checking in to GCC and (d) in bootstrap, the
> checks (c) and (d) should never actually find any problems but still be
> there for safety.

That was the idea. The checker would be a stand-alone program that simply 
operates on the .po files. If the translation project would do a) and b), 
then c) and d) are only backups in case something wasn't caught before. It's 
the same as with the testsuite: ideally, people would write bug free code. In 
practice the don't, that's why we have a testsuite that prevents people from 
checking in code that doesn't always work.

I agree that steps [ab] should be taken, and without that [cd] doesn't make 
much sense. Someone with connections to the translation project is clearly 
needed here. But even if [ab] were in place, I would still argue for 
double-checks on our side.

W. 

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]