You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@worldgate.com> on 1998/01/17 02:52:50 UTC
warnings on Solaris
"mod_imap.c", line 768: warning: argument #2 is incompatible with prototype:
prototype: pointer to array[2] of const double : "mod_imap.c", line 198
argument : pointer to array[2] of double
same as in pr#<mumble>.
SC4.2.
This is valid code, no? You can always pass a non-const to a const,
can't you? Why does gcc 2.8 and IRIX's cc complain about the same
thing?
Guess would should just end up removing const... changing it to
be pointers in the function definition doesn't help.
Re: warnings on Solaris
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
>
> No no Ben or someone already mentioned that I messed up the prototypes,
> and whoever said it is right. The right prototype is a head scratcher and
> not worth putting in there.
That may be true, but it doesn't alter my point :-)
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: warnings on Solaris
Posted by Dean Gaudet <dg...@arctic.org>.
No no Ben or someone already mentioned that I messed up the prototypes,
and whoever said it is right. The right prototype is a head scratcher and
not worth putting in there.
Dean
On Wed, 21 Jan 1998, Rodent of Unusual Size wrote:
> Ben Laurie wrote:
> >
> > Sigh. I'm sure I've said this several times, but I'll say it again. The
> > problem is with double indirection; although it is valid to pass an "x
> > *" to a "const x *" it is not valid to pass an "x **" to a "const x **".
> > This is why I had to add the _nc variants for a pile of stuff in
> > utils.c. I haven't quite decided whether I believe this restriction is
> > justified, but it certainly exists in many compilers. I suspect it is
> > actually a compiler bug, but would welcome informed opinion.
> >
> > BTW, the xlc compiler on AIX also complains about this, I'm told.
>
> The bundled ANSI cc on Digital UNIX (V3.2 at least) also gritches. I'm
> not so sure it can be called a compiler bug if so many of them with no
> likely common back end code complain about it.
>
> #ken P-)}
>
Re: warnings on Solaris
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ben Laurie wrote:
>
> Sigh. I'm sure I've said this several times, but I'll say it again. The
> problem is with double indirection; although it is valid to pass an "x
> *" to a "const x *" it is not valid to pass an "x **" to a "const x **".
> This is why I had to add the _nc variants for a pile of stuff in
> utils.c. I haven't quite decided whether I believe this restriction is
> justified, but it certainly exists in many compilers. I suspect it is
> actually a compiler bug, but would welcome informed opinion.
>
> BTW, the xlc compiler on AIX also complains about this, I'm told.
The bundled ANSI cc on Digital UNIX (V3.2 at least) also gritches. I'm
not so sure it can be called a compiler bug if so many of them with no
likely common back end code complain about it.
#ken P-)}
Re: warnings on Solaris
Posted by Ben Laurie <be...@algroup.co.uk>.
Gregory A Lundberg wrote:
>
> On Sat, 17 Jan 1998, Ben Laurie wrote:
>
> > This is the same as const x **. Did you mean something like const x
> > const ** (or do I mean const x * const *?)?
>
> I always find parenthesis good at this point. If you mean a pointer,
> which I cannot change, to a pointer which I can change, try:
> const (x *) * or x * const *
> I think the first is more correct, but on some compilers I've had trouble
> with it and found they wanted the second form. Since we're worried about
> portability, I'd suggest clarifying the issue with some typedefs.
>
> typedef const int cint; /* const int */
> typedef cint * cintptr; /* var ptr to const int */
> typedef const cintptr cintcptr; /* const ptr to const int */
> cintcptr * x ; /* var ptr to const ptr to const int */
> const cintcptr * y; /* const ptr to const ptr to const int */
>
> Unrolling this yields
> const const int * * x;
> const const const int * * y;
> which _should_ work but confuses some compilers (and most programmers) so
> let's stick with typedefs.
I don't really buy this, for several reasons, but the simplest is that
it is not possible to declare a const ptr to a var ptr to a const int in
an unambiguous way.
I've been reviewing K&R Ed 2, and Stroustrup Ed 1 (really ought to get
up to date on that one!), and they essentially say that you can put
const before a simple type declarator, such as char, int, etc. but to
apply it to a pointer, it comes after the *. So, you get:
const int * const x; /* const ptr to const int */
const int * const * const x; /* const ptr to const ptr to const int */
const int ** const x; /* const ptr to var ptr to const int */
Of course, typedefs are treated like simple types, so the const can go
to the left, but you can't unwind them by simple textual substitution. I
believe some (all?) compilers allow some consistency by permitting the
const to come _after_ a simple type (so const is always to the right of
the thing it applies to), and then we get something that can be unwound
through typedefs. For example, const ptr to const int becomes:
int const * const x;
or
typedef int const cint;
typedef cint * const cptrcint;
or
typedef int const cint;
typedef cint * ptrcint;
typedef ptrcint const cptrcint;
const ptr to var ptr to const int, done via typedefs:
typedef int const cint;
typedef cint *ptrcint;
typedef ptrcint *ptrptrcint;
typedef ptrptrcint const cptrptrcint;
cptrptrcint x;
unwinding that gives:
int const ** const x;
and there you are.
> While casts are Bad Things, typedefs are Good Things. They are so good
> that with some lints you can have them treated as completely new types and
> get warnings about assigning a squarepeg to a roundhole even though both
> are typedef'd void* underneath. Betcha if Apache used 'em everywhere the
> warnings list from the nightly builds 'd fill a filesystem :P
:-) Probably not quite _that_ bad, but alarming nonetheless, I'll wager.
I agree that typedefs are a Good Thing (though I'm not hugely in favour
of using them to hide *s).
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: warnings on Solaris
Posted by Gregory A Lundberg <lu...@vr.net>.
On Sat, 17 Jan 1998, Ben Laurie wrote:
> This is the same as const x **. Did you mean something like const x
> const ** (or do I mean const x * const *?)?
I always find parenthesis good at this point. If you mean a pointer,
which I cannot change, to a pointer which I can change, try:
const (x *) * or x * const *
I think the first is more correct, but on some compilers I've had trouble
with it and found they wanted the second form. Since we're worried about
portability, I'd suggest clarifying the issue with some typedefs.
typedef const int cint; /* const int */
typedef cint * cintptr; /* var ptr to const int */
typedef const cintptr cintcptr; /* const ptr to const int */
cintcptr * x ; /* var ptr to const ptr to const int */
const cintcptr * y; /* const ptr to const ptr to const int */
Unrolling this yields
const const int * * x;
const const const int * * y;
which _should_ work but confuses some compilers (and most programmers) so
let's stick with typedefs.
While casts are Bad Things, typedefs are Good Things. They are so good
that with some lints you can have them treated as completely new types and
get warnings about assigning a squarepeg to a roundhole even though both
are typedef'd void* underneath. Betcha if Apache used 'em everywhere the
warnings list from the nightly builds 'd fill a filesystem :P
----
Gregory A Lundberg Senior Partner, VRnet Company
1441 Elmdale Drive email: lundberg@vr.net [205.133.13.8]
Kettering, OH 45409-1615 USA voice: +1 (937) 299-7653
Re: warnings on Solaris
Posted by Ben Laurie <be...@algroup.co.uk>.
Gregory A Lundberg wrote:
>
> On Sat, 17 Jan 1998, Ben Laurie wrote:
>
> > *" to a "const x *" it is not valid to pass an "x **" to a "const x **".
>
> Try this:
>
> const const x * *
>
> if it works, there you go. If it doesn't report the bug to the compiler
> list.
This is the same as const x **. Did you mean something like const x
const ** (or do I mean const x * const *?)?
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: warnings on Solaris
Posted by Gregory A Lundberg <lu...@vr.net>.
On Sat, 17 Jan 1998, Ben Laurie wrote:
> *" to a "const x *" it is not valid to pass an "x **" to a "const x **".
Try this:
const const x * *
if it works, there you go. If it doesn't report the bug to the compiler
list.
----
Gregory A Lundberg Senior Partner, VRnet Company
1441 Elmdale Drive email: lundberg@vr.net [205.133.13.8]
Kettering, OH 45409-1615 USA voice: +1 (937) 299-7653
Re: warnings on Solaris
Posted by Ben Laurie <be...@algroup.co.uk>.
Marc Slemko wrote:
>
> "mod_imap.c", line 768: warning: argument #2 is incompatible with prototype:
> prototype: pointer to array[2] of const double : "mod_imap.c", line 198
> argument : pointer to array[2] of double
>
> same as in pr#<mumble>.
>
> SC4.2.
>
> This is valid code, no? You can always pass a non-const to a const,
> can't you? Why does gcc 2.8 and IRIX's cc complain about the same
> thing?
>
> Guess would should just end up removing const... changing it to
> be pointers in the function definition doesn't help.
Sigh. I'm sure I've said this several times, but I'll say it again. The
problem is with double indirection; although it is valid to pass an "x
*" to a "const x *" it is not valid to pass an "x **" to a "const x **".
This is why I had to add the _nc variants for a pile of stuff in
utils.c. I haven't quite decided whether I believe this restriction is
justified, but it certainly exists in many compilers. I suspect it is
actually a compiler bug, but would welcome informed opinion.
BTW, the xlc compiler on AIX also complains about this, I'm told.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache