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: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]


On Mon, Aug 12, 2002 at 06:59:28PM -0700, Devang Patel wrote:
> 
> On Monday, August 12, 2002, at 06:25  PM, Richard Henderson wrote:
> 
> >On Mon, Aug 12, 2002 at 05:00:05PM -0700, Devang Patel wrote:
> >>>If the argument is that this warning comes from third-party header
> >>>files, the counter-argument is that the third party probably put
> >>>it in there for a reason, and that if you ignore the warning you
> >>>may well not understand the input constraints of the package.
> >>>
> >>
> >>What if it is coming from system headers ?
> >
> >That still fits the description of third party from my point
> >of view: not the compiler and not the programmer.
> 
> It is different from third-party header. You may have freedom to use
> particular version of third-party component but not system headers.
> 
> In Software release cycle, there are times when you're not allowed to
> touch your source for a given release. They are frozen at a time.
> Now imagine Mr. X
> 
> - Mr X is a software developer and develops software Z.
> - Z is part of one particular OS released
>   targeted for particular date.
> - Z is frozen as of today for OS release and it uses math library.
> - Some other component in OS needs higher precision math and it is an
>   important component so system gets new math library.
> - Math library provider puts a #warning message about new functions.
> - Z uses -Werror and now it does not build.
> 
>   You may argue that X needs to fix Z to use new APIs, but in real life
>   if there are 1000 such projects and fixing and testing each of them
>   may take couple of months to stabilize everything.

That's not a valid reason, in my opinion.  The new math library should
have #warning only off on a dev branch somewhere if it's sneaking in at
a time when components can not be upgraded to match!  That's release
management; you don't deprecate interfaces at the last minute.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


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