On Thu, 2009-11-05 at 20:57 +0200, Daniel Shahaf wrote:
> Julian Foad wrote on Thu, 5 Nov 2009 at 18:50 -0000:
> > I think the ultimate analysis here is that the compiler doesn't know
> > whether APR_EOL_STR ever has a different value. It warns because, in the
> > current translation unit, that code will never be executed; but it
> > doesn't know that sometimes we might ask it to compile with a different
> > APR_EOL_STR
>
> Hmm. dannas mentioned yesterday that apr.h defines APR_EOL_STR
> unconditionally as "\n" (for him; as "\r\n" for me) --- i.e., not
> wrapped in any #if.
I think "apr.h" is generated by the APR build to match the platform it's
built on.
> Perhaps the warning would go away if apr.h chose between >=2 definitions
> for APR_EOL_STR?
>
> [[[
> --- include/apr.h
> +++ include/apr.h
> @@ -N,M +N,M @@
> +#ifdef WILL_NEVER_BE_DEFINED
> +#define APR_EOL_STR "\r\n\p\l\u\s\p\a\d\d\i\n\g"
> +#else
> #define APR_EOL_STR "\n"
> +#endif
> ]]]
>
> ?
I don't think GCC would notice.
> > So, the problem here is that the warning is based on
> > insufficient information. Maybe the next version of GCC will have a way
> > to indicate that, or maybe it will stop issuing that warning in cases
> > like this, or ... Anyway, if the warning is not very good, not very
> > helpful, then we should disable it rather than twisting the code to
> > avoid triggering it. After all, with your patch to pass the string as a
> > parameter, a whole-file-optimiser could optimise out your transformation
> > and still generate the same warning.
BTW, I am not saying any of these things are likely, just that they are
theoretically possible.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2414889
Received on 2009-11-05 20:24:09 CET