3.2 Compile problems with gcc 4.0

[Jim Gallacher <jg...@sympatico.ca>]

I updated dated my workstation today which included pulling in gcc 4.0.1 
and thought I'd give mod_python a whirl and how if they'd play together.

Compilation fails with the following:

requestobject.c: In function 'request_tp_dealloc':
requestobject.c:1482: warning: implicit declaration of function 
'request_tp_clear'
requestobject.c: At top level:
requestobject.c:1514: error: static declaration of 'request_tp_clear' 
follows non-static declaration
requestobject.c:1482: error: previous implicit declaration of 
'request_tp_clear' was here
requestobject.c: In function 'request_tp_clear':
requestobject.c:1528: warning: assignment from incompatible pointer type
apxs:Error: Command failed with rc=65536

Since gcc 3.3 sails right through, I'm going to assume gcc 4 is 
stricter.  It's easy enough to fix (and I will) by adding a function 
prototype for request_tp_clear before it is called in 
request_tp_dealloc(). eg.
  static int request_tp_clear(requestobject *self);

I've noticed that in general functions are implicitly declared in 
mod_python. Is there a technical reason for this, or is it "just one of 
those things"?

Also, since request_tp_clear is only used in requestobject.c, is it 
correct to put the declaration there or should it go in requestobject.h? 
  Ya, I know, my c-skills suck. :)

Regards,
Jim

Re: 3.2 Compile problems with gcc 4.0

["Gregory (Grisha) Trubetskoy" <gr...@apache.org>]

On Thu, 11 Aug 2005, Jim Gallacher wrote:

> OK, chief. :) I don't mind doing an audit for Apache coding style 
> compliance, but in a post 3.2.0 time frame. Let's not start mucking with 
> working code just before the release.

I agree, it's just a note for the future, whatever code we check in should 
always be the best, well spaced, well commented, read like a poem, etc.

:-)

Grisha

Re: 3.2 Compile problems with gcc 4.0

[Jim Gallacher <jg...@sympatico.ca>]

Gregory (Grisha) Trubetskoy wrote:
> 
> 
> On Wed, 10 Aug 2005, Jim Gallacher wrote:
> 
>> Compilation fails with the following:
>>
>> requestobject.c: In function 'request_tp_dealloc':
>> requestobject.c:1482: warning: implicit declaration of function 
>> 'request_tp_clear'
> 
> 
> This looks like a bug - I guess GCC 3 defaulted to static for 
> implicitely declared functions, or perhaps didn't mind a non-static 
> declaration followed by a static declaration.

gcc 3.3 just generates a warning:

requestobject.c: In function `request_tp_dealloc':
requestobject.c:1479: warning: implicit declaration of function 
`request_tp_clear'
requestobject.c: At top level:
requestobject.c:1511: warning: `request_tp_clear' was declared 
implicitly `extern' and later `static'
requestobject.c:1479: warning: previous declaration of `request_tp_clear'

> As a sidenote - (wearing my dictator hat) - we really should be 
> following the Apache coding style - having no spaces after if and 
> several statements per line makes it difficult to read. Also, repetitive 
> code is probably a good case for using an extra function or a macro 
> (macro's should be last resort though because they can be hard to read 
> and debug - but in this particular case a macro may be just fine)

OK, chief. :) I don't mind doing an audit for Apache coding style 
compliance, but in a post 3.2.0 time frame. Let's not start mucking with 
working code just before the release.

>> It's easy enough to fix (and I will) by adding a function prototype 
>> for request_tp_clear before it is called in request_tp_dealloc(). eg.
>> static int request_tp_clear(requestobject *self);
> 
> 
> I think it can be fixed by simply moving tp_dealloc after tp_clear.

This is true, but I wasn't sure if it that was the preferred way.

>> I've noticed that in general functions are implicitly declared in 
>> mod_python. Is there a technical reason for this, or is it "just one 
>> of those things"?
> 
> 
> Not really - implicit declaration is when something is referenced before 
> being declared which in most cases results in compilation errors. What 
> you probably mean to say is that they do not have forward declarations, 
> but you generally don't need them if code is ordered correctly - there 
> is no reason to have a forward declaration for every function.

OK. I'll fix the bug by moving request_tp_clear ahead of request_tp_dealloc.

Jim

Re: 3.2 Compile problems with gcc 4.0

["Gregory (Grisha) Trubetskoy" <gr...@apache.org>]

On Thu, 11 Aug 2005, Gregory (Grisha) Trubetskoy wrote:

> On Wed, 10 Aug 2005, Jim Gallacher wrote:

>> It's easy enough to fix (and I will) by adding a function prototype

> What you probably mean to say is that they do not have forward 
> declarations

Having googled this a bit, "function prototype" actually is the correct 
term, a "forward declaration" seems to a C++ thing pertaining to classes 
:-)

Grisha

Re: 3.2 Compile problems with gcc 4.0

["Gregory (Grisha) Trubetskoy" <gr...@apache.org>]

On Wed, 10 Aug 2005, Jim Gallacher wrote:

> Compilation fails with the following:
>
> requestobject.c: In function 'request_tp_dealloc':
> requestobject.c:1482: warning: implicit declaration of function 
> 'request_tp_clear'

This looks like a bug - I guess GCC 3 defaulted to static for implicitely 
declared functions, or perhaps didn't mind a non-static declaration 
followed by a static declaration.

As a sidenote - (wearing my dictator hat) - we really should be following 
the Apache coding style - having no spaces after if and several statements 
per line makes it difficult to read. Also, repetitive code is probably a 
good case for using an extra function or a macro (macro's should be last 
resort though because they can be hard to read and debug - but in this 
particular case a macro may be just fine)

> It's easy enough to fix (and I will) by adding a function prototype for 
> request_tp_clear before it is called in request_tp_dealloc(). eg.
> static int request_tp_clear(requestobject *self);

I think it can be fixed by simply moving tp_dealloc after tp_clear.

> I've noticed that in general functions are implicitly declared in 
> mod_python. Is there a technical reason for this, or is it "just one of 
> those things"?

Not really - implicit declaration is when something is referenced before 
being declared which in most cases results in compilation errors. What you 
probably mean to say is that they do not have forward declarations, but 
you generally don't need them if code is ordered correctly - there is no 
reason to have a forward declaration for every function.

> Also, since request_tp_clear is only used in requestobject.c, is it correct 
> to put the declaration there or should it go in requestobject.h?

see above

> Ya, I know, my c-skills suck. :)

That's OK, I don't profess to be a C expert either :-)

Grisha