You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Justin Erenkrantz <je...@apache.org> on 2002/09/13 10:16:48 UTC
Sun forte compiler warnings
I tried compiling apr/apr-util with Sun's forte and two files in
the repository are a bit troublesome and may need some thought as
to how to fix them so that we don't emit warnings.
- apr/shmem/unix/shm.c - lots of code fragments result in unreachable
code because we use #ifdef's and then after all the #ifdef's we
return APR_ENOTIMPL. Therefore, this results in the final return
being unreachable (all code paths return before we hit the final
APR_ENOTIMPL). We really should be able to catch this not-impl
case at pre-processor time, but some of the conditions are really
convoluted.
- apr-util/ldap/apr_ldap_compat.c - On machines with LDAPv3 libraries,
this file essentially becomes a no-op which causes forte to return
'empty translation unit.' Eek.
Thoughts? -- justin
Re: Sun forte compiler warnings
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Sep 13, 2002 at 01:16:48AM -0700, Justin Erenkrantz wrote:
> - apr/shmem/unix/shm.c - lots of code fragments result in unreachable
> code because we use #ifdef's and then after all the #ifdef's we
> return APR_ENOTIMPL. Therefore, this results in the final return
> being unreachable (all code paths return before we hit the final
> APR_ENOTIMPL). We really should be able to catch this not-impl
> case at pre-processor time, but some of the conditions are really
> convoluted.
I can take a look at this, I know the code pretty well.
-aaron
Re: Sun forte compiler warnings
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Sep 13, 2002 at 02:34:49PM -0700, Greg Stein wrote:
> The #if logic is awfully hair. I'd recommend creating some internal symbols
> that describe the semantics of what you're checking for.
>
> For example:
>
> #if !defined(SOMETHING) && !defined(OR_OTHER)
> #define NO_SHARED_MEM
> #endif
> ...
>
> #ifdef NO_SHARED_MEM
> ...
I considered that, but thought that might cause some confusion if we
ever need to add more symbols to the set, but on second thought it's
probably not a big deal even if we do.
I'll work on something cleaner this afternoon.
-aaron
Re: Sun forte compiler warnings
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Sep 13, 2002 at 09:23:37AM -0700, Aaron Bannert wrote:
> On Fri, Sep 13, 2002 at 01:16:48AM -0700, Justin Erenkrantz wrote:
> > - apr/shmem/unix/shm.c - lots of code fragments result in unreachable
> > code because we use #ifdef's and then after all the #ifdef's we
> > return APR_ENOTIMPL. Therefore, this results in the final return
> > being unreachable (all code paths return before we hit the final
> > APR_ENOTIMPL). We really should be able to catch this not-impl
> > case at pre-processor time, but some of the conditions are really
> > convoluted.
>
> I can't remember my password or which key I used on nagoya, so I
> don't have access to any Forte machines, but here's a patch that
> doesn't break anything for me on Darwin. Let me know if it does
> the trick and I'll commit it.
The #if logic is awfully hair. I'd recommend creating some internal symbols
that describe the semantics of what you're checking for.
For example:
#if !defined(SOMETHING) && !defined(OR_OTHER)
#define NO_SHARED_MEM
#endif
...
#ifdef NO_SHARED_MEM
...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Sun forte compiler warnings
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Sep 13, 2002 at 01:16:48AM -0700, Justin Erenkrantz wrote:
> - apr/shmem/unix/shm.c - lots of code fragments result in unreachable
> code because we use #ifdef's and then after all the #ifdef's we
> return APR_ENOTIMPL. Therefore, this results in the final return
> being unreachable (all code paths return before we hit the final
> APR_ENOTIMPL). We really should be able to catch this not-impl
> case at pre-processor time, but some of the conditions are really
> convoluted.
I can't remember my password or which key I used on nagoya, so I
don't have access to any Forte machines, but here's a patch that
doesn't break anything for me on Darwin. Let me know if it does
the trick and I'll commit it.
-aaron
Index: shmem/unix/shm.c
===================================================================
RCS file: /home/cvs/apr/shmem/unix/shm.c,v
retrieving revision 1.18
diff -u -r1.18 shm.c
--- shmem/unix/shm.c 16 Apr 2002 20:25:57 -0000 1.18
+++ shmem/unix/shm.c 13 Sep 2002 16:22:07 -0000
@@ -124,7 +124,12 @@
#endif
}
+/* If this system doesn't use any of our supported SHM types, then it's
+ * going to fall through to this. Otherwise we bailed out above, and
+ * this boolean equation is to avoid obnoxious compiler warnings. */
+#if !APR_USE_SHMEM_SHMGET && !APR_USE_SHMEM_MMAP_SHM && !APR_USE_SHMEM_MMAP_TMP && !APR_USE_SHMEM_SHMGET_ANON && !APR_USE_SHMEM_MMAP_ZERO && !APR_USE_SHMEM_MMAP_ANON
return APR_ENOTIMPL;
+#endif
}
APR_DECLARE(apr_status_t) apr_shm_create(apr_shm_t **m,
@@ -413,7 +418,12 @@
#endif /* APR_USE_SHMEM_SHMGET */
}
+/* If this system doesn't use any of our supported SHM types, then it's
+ * going to fall through to this. Otherwise we bailed out above, and
+ * this boolean equation is to avoid obnoxious compiler warnings. */
+#if !APR_USE_SHMEM_SHMGET && !APR_USE_SHMEM_MMAP_SHM && !APR_USE_SHMEM_MMAP_TMP && !APR_USE_SHMEM_SHMGET_ANON && !APR_USE_SHMEM_MMAP_ZERO && !APR_USE_SHMEM_MMAP_ANON
return APR_ENOTIMPL;
+#endif
}
APR_DECLARE(apr_status_t) apr_shm_destroy(apr_shm_t *m)
@@ -444,7 +454,9 @@
#endif
}
+#if !APR_USE_SHMEM_MMAP_TMP && !APR_USE_SHMEM_MMAP_SUM && !APR_USE_SHMEM_SHMGET
return APR_ENOTIMPL;
+#endif
}
APR_DECLARE(apr_status_t) apr_shm_attach(apr_shm_t **m,
@@ -569,7 +581,9 @@
#endif /* APR_USE_SHMEM_SHMGET */
}
+#if !APR_USE_SHMEM_MMAP_TMP && !APR_USE_SHMEM_MMAP_SUM && !APR_USE_SHMEM_SHMGET
return APR_ENOTIMPL;
+#endif
}
APR_DECLARE(apr_status_t) apr_shm_detach(apr_shm_t *m)
Re: Sun forte compiler warnings
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Justin Erenkrantz wrote:
> I tried compiling apr/apr-util with Sun's forte and two files in
> the repository are a bit troublesome and may need some thought as
> to how to fix them so that we don't emit warnings.
>
> - apr/shmem/unix/shm.c - lots of code fragments result in unreachable
> code because we use #ifdef's and then after all the #ifdef's we
> return APR_ENOTIMPL. Therefore, this results in the final return
> being unreachable (all code paths return before we hit the final
> APR_ENOTIMPL). We really should be able to catch this not-impl
> case at pre-processor time, but some of the conditions are really
> convoluted.
That prevents the "empty translation unit" error messages :-)!
>
> - apr-util/ldap/apr_ldap_compat.c - On machines with LDAPv3 libraries,
> this file essentially becomes a no-op which causes forte to return
> 'empty translation unit.' Eek.
>
> Thoughts? -- justin
>
>