Re: build/6980: Copious build warnings

[tr...@apache.org]

[In order for any reply to be added to the PR database, you need]
[to include <ap...@Apache.Org> in the Cc line and make sure the]
[subject line starts with the report component and number, with ]
[or without any 'Re:' prefixes (such as "general/1098:" or      ]
["Re: general/1098:").  If the subject doesn't match this       ]
[pattern, your message will be misfiled and ignored.  The       ]
["apbugs" address is not added to the Cc line of messages from  ]
[the database automatically because of the potential for mail   ]
[loops.  If you do not include this Cc, your reply may be ig-   ]
[nored unless you are responding to an explicit request from a  ]
[developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]


Synopsis: Copious build warnings

State-Changed-From-To: open-analyzed
State-Changed-By: trawick
State-Changed-When: Fri Mar  2 10:37:17 PST 2001
State-Changed-Why:
I have looked through http://oss.sgi.com/projects/apache/out.2.0a9.

Some of these warnings will always exist... Examples:

===> lib/apr/shmem/unix
        cc -fullwarn -g -g  -D_POSIX_THREAD_SAFE_FUNCTIONS  -c -I../../include -Imm shmem.c
"shmem.c", line 64: remark(1174): parameter "cont" was declared but never
          referenced
  apr_status_t apr_shm_init(struct shmem_t **m, apr_size_t reqsize, const char *file, apr_pool_t *cont)

(because many APR functions have parameters which are not necessary
on all platforms; also many Directive processing functions have
parameters which are made available by the configuration code
but not used for particular directives)

"http_core.c", line 3289: remark(1209): controlling expression is constant
              AP_BUCKET_INSERT_BEFORE(eos, e);

(because we frequently use macro constructs which use constant controlling expressions)

(not an exhaustive list)

These probably won't go away until we know of a platform where it
is invalid and/or somebody wants to make the exports.c generation
more complex:

"exports.c", line 286: warning(1048): cast between pointer-to-object and
          pointer-to-function
  const void *ap_hack_apr_kill = (const void *)apr_kill;

Others have been fixed:

e.g., top_builddir warnings from make (at least they went
away on Tru64)

(not an exhaustive list)

Many others can't be investigated properly by somebody with no access 
to an SGI machine:

"htpasswd.c", line 668: remark(1196): function declared implicitly
      unlink(tempfilename);
      ^
"mpmt_pthread.c", line 188: remark(1196): function declared implicitly
      chdir(ap_coredump_dir);

(not an exhaustive list)

others I will fix right now and reference this bug:

"mpmt_pthread.c", line 190: remark(1506): implicit conversion from
          "unsigned int" to "long":  rounding, sign extension, or loss of
          accuracy may result
      kill(ap_my_pid, sig);

(I'll look for more which have obvious, risk-free solutions)

It is very possible that since 2.0a9 there are new warnings
on SGI.

There were some comments in the original problem report about 
Apache not caring about warnings.  This is simply not true.
For many months we have tracked any change to warnings or errors
from configure or build on a number of platforms.  Any change is 
attended to as soon as practical.  The unfortunate truth is
that we do not have access to all platforms on which our users
deploy Apache.  When this is the case, the best way for users
to deal with problems with warnings (IMHO) is to pick a single 
problem to solve, solve it, and post the patch to either 
new-httpd@apache.org or dev@apr.apache.org with an 
explanation.