You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by ra...@bellglobal.com on 1998/01/26 18:43:33 UTC

Recent table struct change

Dean recently changed the table struct in alloc.h from

    typedef array_header table;

to

    typedef table table;

In my PHP module I am now getting:

     main.c:992: dereferencing pointer to incomplete type

Line 992 looks like this:

  table_entry *elts = (table_entry *)r->subprocess_env->elts;

This is probably an exceedingly stupid question, but how should I be
casting this assignment?  With the table type being opague, the compiler
doesn't know that 'elts' is an element of r->subprocess_env and thus
correctly complains.

This is another change that I think might have warranted an MMN bump.
As far as I am concerned, I am not using anything that is not part of the
API in my module, and whenever something is changed in Apache that breaks
my module, I consider it an API change.

-Rasmus

Re: Recent table struct change

Posted by Marc Slemko <ma...@worldgate.com>.
On Mon, 26 Jan 1998, Dean Gaudet wrote:

> Can someone suggest a good place to place these instructions? 

In the changes section of the docs for our API.

Too bad there aren't any.


Re: Recent table struct change

Posted by Martin Kraemer <Ma...@mch.sni.de>.
On Mon, Jan 26, 1998 at 12:27:36PM -0800, Dean Gaudet wrote:
> It's actually:
> 
> typedef struct table table; 
> 
> I don't really care if that works in C++.

That _IS_ C++ ;-)   Or at least the spirit oc C++.

Actually, in C++, every struct XXX {}; definition is at the same time
a typedef of its struct name. So, asl long as you use
    typedef struct XXX XXX;
it's file with C++ (i.e., you wrap the typedef in #ifndef __cplusplus).

The pool case is different because it defines
    typedef struct XXX *XXX;
so it's very unlike the above situation.

    Martin
-- 
| S I E M E N S |  <Ma...@mch.sni.de>  |      Siemens Nixdorf
| ------------- |   Voice: +49-89-636-46021     |  Informationssysteme AG
| N I X D O R F |   FAX:   +49-89-636-44994     |   81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request

Re: Recent table struct change

Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
> 
> It's actually:
> 
> typedef struct table table;
> 
> I don't really care if that works in C++.  That is the traditional way of
> declaring an opaque type or forward type reference in C.  Apache is
> written in C, not in C++.  I don't buy the benefit of "improved type
> checking".

There are others. But anyway, it works, or if it doesn't, it can be left
out and the nett effect is the same (that's one of the other benefits -
less lines of code :-)

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: Recent table struct change

Posted by Dean Gaudet <dg...@arctic.org>.
It's actually:

typedef struct table table; 

I don't really care if that works in C++.  That is the traditional way of
declaring an opaque type or forward type reference in C.  Apache is
written in C, not in C++.  I don't buy the benefit of "improved type
checking". 

Dean

On Mon, 26 Jan 1998 rasmus@bellglobal.com wrote:

> 
> > I'd like to see this code cleaned up in all modules, but will back out the
> > "opaqueness" part of the change if pushed hard. 
> 
> I can see how it makes the table mechanism more flexible, so on that account
> it doesn't bug me.  However, haven't we just introduced another one of those
> "typedef pool pool" C++ killers?
> 
> -Rasmus
> 


Re: Recent table struct change

Posted by ra...@bellglobal.com.
> I'd like to see this code cleaned up in all modules, but will back out the
> "opaqueness" part of the change if pushed hard. 

I can see how it makes the table mechanism more flexible, so on that account
it doesn't bug me.  However, haven't we just introduced another one of those
"typedef pool pool" C++ killers?

-Rasmus

Re: Recent table struct change

Posted by Dean Gaudet <dg...@arctic.org>.
This is a change that enforces the API the way it was supposed to be used. 
I'm willing to back it out slightly... but now we've seen not only a few
core modules were broken, but so were mod_perl and php.  The reason for
making the change is that without it it's hard to use more sophisticated
structures for tables (and there's reason to believe this may be a
performance win, but we haven't found the right structure yet).  The API
had this in mind ages ago...  which is why there's the table_elts()
function. 

The fix for your code is straight forward, and works for all versions of
apache: 

Wherever you refer to t->elts, replace it with this:

    array_header *arr = table_elts(t);
    table_entry *elts = (table_entry *)arr->elts;

Wherever you refer to t->nelts, use arr->nelts.

Since this works with all versions of Apache (ok at least 1.2 and 1.3) 
you don't need to conditionalize it, and so I don't think the MMN needs to
be bumped. 

I'd like to see this code cleaned up in all modules, but will back out the
"opaqueness" part of the change if pushed hard. 

Can someone suggest a good place to place these instructions? 

Dean

On Mon, 26 Jan 1998 rasmus@bellglobal.com wrote:

> Dean recently changed the table struct in alloc.h from
> 
>     typedef array_header table;
> 
> to
> 
>     typedef table table;
> 
> In my PHP module I am now getting:
> 
>      main.c:992: dereferencing pointer to incomplete type
> 
> Line 992 looks like this:
> 
>   table_entry *elts = (table_entry *)r->subprocess_env->elts;
> 
> This is probably an exceedingly stupid question, but how should I be
> casting this assignment?  With the table type being opague, the compiler
> doesn't know that 'elts' is an element of r->subprocess_env and thus
> correctly complains.
> 
> This is another change that I think might have warranted an MMN bump.
> As far as I am concerned, I am not using anything that is not part of the
> API in my module, and whenever something is changed in Apache that breaks
> my module, I consider it an API change.
> 
> -Rasmus
>