You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Stein <gs...@lyra.org> on 2001/01/04 21:54:04 UTC
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On Thu, Jan 04, 2001 at 08:45:13PM -0000, trawick@apache.org wrote:
> trawick 01/01/04 12:45:12
>
> Modified: modules/filters mod_include.c
> Log:
> Get rid of some warnings on Tru64 and OS/390. void * isn't compatible
> with function pointers.
You're kidding.
Is there some kind of compiler switch to set to fix that? I'd rather see a
switch than these monkey casts.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Posted by Ben Laurie <be...@algroup.co.uk>.
Jeff Trawick wrote:
>
> Greg Stein <gs...@lyra.org> writes:
>
> > I thought that void* was compatible with all pointers (including func ptrs).
> > Dean posted a reply a bit ago that says otherwise (according to the specs,
> > and a couple demo cases he gave).
> >
> > So ignore me :-)
>
> For better or for worse, I have a hard time ignoring you (which is why
> I looked into it further) :) I wish I had a more thorough
> interpretation (or copy) of the spec. My usually-reliable "Standard
> C" by Plauger & Brodie did not cover the issue.
Hmm. K&R2 explicitly says "Any pointer may be converted to type void *
without loss of information" (A6.8 Pointers to Void, p.199).
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
Greg Stein <gs...@lyra.org> writes:
> I thought that void* was compatible with all pointers (including func ptrs).
> Dean posted a reply a bit ago that says otherwise (according to the specs,
> and a couple demo cases he gave).
>
> So ignore me :-)
For better or for worse, I have a hard time ignoring you (which is why
I looked into it further) :) I wish I had a more thorough
interpretation (or copy) of the spec. My usually-reliable "Standard
C" by Plauger & Brodie did not cover the issue.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Posted by David Reid <dr...@jetnet.co.uk>.
>
> So ignore me :-)
We couldn't do that, you'd just shout louder!
:)
david
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Posted by Sascha Schumann <sa...@schumann.cx>.
> I thought that void* was compatible with all pointers (including func ptrs).
> Dean posted a reply a bit ago that says otherwise (according to the specs,
> and a couple demo cases he gave).
Annex I of C99 specifies a Common Warning in the case that
"An implicit narrowing conversion is encountered, such as the
assignment of [..] a pointer to void to a pointer to any type
other than a character type." As OS/390 and Tru64 yield a
warning only, they seem to follow that recommendation.
Section 6.3.2.3 of C99 basically allows a conversion from a
pointer to void from/to a pointer to any object type.
Note that I'm not sure whether "object type" in this
particular context also refers to types describing a function
(6.2.5 designates "function type" for that purpose).
- Sascha
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> > > If by chance you mean that the sentence beginning with "void" is
> > > factually incorrect according to published standards, I'd like to
> > > know, as I'll contact the OS/390 compiler folks and see what they can
> > > do. (I'll punt on Tru64 as I don't know how issues like this are
> > > handled.)
> >
> > [ actually, it *is* potentially a problem if a func ptr can't fit in a
> > void*; that means the hash table is simply broken on some platforms ]
>
> Yeah, but it is an easy fix. Dean said that (void *)() is always a valid
> func ptr, so we just need to use that instead of void *.
Correct... K&R 2nd Ed (very old historical document :-) states in the last
paragraph of 5.9 that "Draft Proposed ANSI C introduces the type "void *", or
pointer to void, to represent a "universal" data pointer."
>From the first paragraph of 11.4.5, "All other pointer types (except perhaps
function pointers) can be converted to type void * and back without change;"
That says it all. I think we have always had the scenario where code pointers
can be disjunct from function pointers, and this will be especially true in
the newer 64 bit long data pointers on NT Whistler, while appearing to maintain
the 32 bit code pointer [don't quote me, I could be wrong on that.]
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Posted by Ben Laurie <be...@algroup.co.uk>.
dean gaudet wrote:
>
> that's void (*)() ... got to get the bracketing right :)
>
> note that it's even conceivable that void (*)(), void (*)(int) and void
> (*)(int, ...) are different pointer sizes. but i've yet to encounter an
> architecture like that...
It may be conceivable, but it isn't bleedin' C.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Posted by dean gaudet <dg...@arctic.org>.
that's void (*)() ... got to get the bracketing right :)
note that it's even conceivable that void (*)(), void (*)(int) and void
(*)(int, ...) are different pointer sizes. but i've yet to encounter an
architecture like that...
typically those can result in completely different calling conventions.
a fixed argument function can use registers for some arguments, for
example. whereas varargs functions essentially have to pass args on the
stack (weirdo architectures like hobbit notwithstanding :).
for example if you cast a varargs function to void (*)(int) and then
called it that way you would generate bad code on some architectures.
MSVC fastcall conventions for example use registers. (there's also
bizarre push-left-to-right and right-to-left differences under windows,
having to do with the pascal calling convention legacy... which is what
leads to the differences in how you declare varargs versus fixed args
functions for dlls.)
the only time the void (*)() thing is a pain is if you want to do pointer
arithmetic... which isn't really defined for functions at all. if you're
doing arithmetic to generate a hash or something then you may want a
config time test which calculates the smallest integer type which holds a
function pointer, and bail out if one can't be found.
-dean
On Sun, 7 Jan 2001 rbb@covalent.net wrote:
>
> > > If by chance you mean that the sentence beginning with "void" is
> > > factually incorrect according to published standards, I'd like to
> > > know, as I'll contact the OS/390 compiler folks and see what they can
> > > do. (I'll punt on Tru64 as I don't know how issues like this are
> > > handled.)
> >
> > [ actually, it *is* potentially a problem if a func ptr can't fit in a
> > void*; that means the hash table is simply broken on some platforms ]
>
> Yeah, but it is an easy fix. Dean said that (void *)() is always a valid
> func ptr, so we just need to use that instead of void *.
>
> Ryan
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
>
>
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Posted by rb...@covalent.net.
> > If by chance you mean that the sentence beginning with "void" is
> > factually incorrect according to published standards, I'd like to
> > know, as I'll contact the OS/390 compiler folks and see what they can
> > do. (I'll punt on Tru64 as I don't know how issues like this are
> > handled.)
>
> [ actually, it *is* potentially a problem if a func ptr can't fit in a
> void*; that means the hash table is simply broken on some platforms ]
Yeah, but it is an easy fix. Dean said that (void *)() is always a valid
func ptr, so we just need to use that instead of void *.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jan 04, 2001 at 05:42:53PM -0500, Jeff Trawick wrote:
> Greg Stein <gs...@lyra.org> writes:
>
> > On Thu, Jan 04, 2001 at 08:45:13PM -0000, trawick@apache.org wrote:
> > > trawick 01/01/04 12:45:12
> > >
> > > Modified: modules/filters mod_include.c
> > > Log:
> > > Get rid of some warnings on Tru64 and OS/390. void * isn't compatible
> > > with function pointers.
> >
> > You're kidding.
>
> Huh?
>
> If by chance you mean that the sentence beginning with "void" is
> factually incorrect according to published standards, I'd like to
> know, as I'll contact the OS/390 compiler folks and see what they can
> do. (I'll punt on Tru64 as I don't know how issues like this are
> handled.)
I thought that void* was compatible with all pointers (including func ptrs).
Dean posted a reply a bit ago that says otherwise (according to the specs,
and a couple demo cases he gave).
So ignore me :-)
[ actually, it *is* potentially a problem if a func ptr can't fit in a
void*; that means the hash table is simply broken on some platforms ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
Greg Stein <gs...@lyra.org> writes:
> On Thu, Jan 04, 2001 at 08:45:13PM -0000, trawick@apache.org wrote:
> > trawick 01/01/04 12:45:12
> >
> > Modified: modules/filters mod_include.c
> > Log:
> > Get rid of some warnings on Tru64 and OS/390. void * isn't compatible
> > with function pointers.
>
> You're kidding.
Huh?
If by chance you mean that the sentence beginning with "void" is
factually incorrect according to published standards, I'd like to
know, as I'll contact the OS/390 compiler folks and see what they can
do. (I'll punt on Tru64 as I don't know how issues like this are
handled.)
> Is there some kind of compiler switch to set to fix that? I'd rather see a
> switch than these monkey casts.
I tried the accept-line-noise switch on OS/390 but it didn't make it
happier. I dunno about Tru64.
I don't see what the big deal is. This is a C language issue. I'm
tickled pink that gcc doesn't care about that detail, but three of the
four independently-produced compilers I can lay my hands on at the
moment think that void * is not compatible with a function pointer. I
suspect that there are more.
gcc doesn't care (at least with our normal flag)
OS/390 IBM compiler does care (no flag will fix it)
Tru64 Compaq compiler does care (I don't know about available flags)
MS VCC++ 5.0 does care (only if /Za is specified)
Cheers...
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Posted by dean gaudet <dg...@arctic.org>.
On Thu, 4 Jan 2001, Greg Stein wrote:
> On Thu, Jan 04, 2001 at 08:45:13PM -0000, trawick@apache.org wrote:
> > trawick 01/01/04 12:45:12
> >
> > Modified: modules/filters mod_include.c
> > Log:
> > Get rid of some warnings on Tru64 and OS/390. void * isn't compatible
> > with function pointers.
>
> You're kidding.
void * is not a function pointer according to ANSI C. void (*)() on the
other hand, *is* a function pointer. it's totally perfectly legal for a
compiler to bitch whine moan, and just not work at all if a void * is cast
to a function pointer.
there's some boxes where function pointers are massive things 512-bits
long; and the word-size is only 32-bits. obviously casts back and forth
won't work in this case.
for a much less exotic example, 16-bit x86 big code, small data models
have 32-bit function pointers, 16-bit data pointers.
-dean