Re: cvs: php4 /ext/sablot sablot.c

At 16:01 10-08-01, Rasmus Lerdorf wrote:

php_sablot.h has: typedef struct _php_sablot_globals {

    zval *errorHandler;
    php_sablot_error *errors;
    php_sablot_error errors_start;
    char *output_transform_file; /* For output transformations */
    int last_errno;              /* Global last_errno, if no handle is

found */

    SablotHandle processor;

} php_sablot_globals And now it won't build.

It's a module interfacing with the engine. If it used the BEGIN_MODULE_GLOBALS etc. macros, it'd build fine - I'll fix it. This stuff is more the interface with the thread-safe resource manager. These are not zend globals. They are extension globals. Making a bad situation worse is simply not a good idea, that's why. PHP extensions are really zend_module_entry's - the PHP macros are replicas of

the engine macros, which is a bad situation.    Removing them was on my

TODO list on low prio, but I took the few minutes to do that now. I don't think this is a good trend. More and more stuff is being pulled into the engine. We are losing the clean distinction here.

Hmm? You might have lost track of it - but the clear distinction is there. The fact you copied&pasted macros from the engine into php.h should have given you the indication that you're doing something wrong... Nothing was 'pulled' (well, except for some macro someone added to the wrong place, php.h) - the replicas in php.h were simply removed. Function modules are data structures that the engine defines, manipulates and activates. Their definition are direct derivatives of the engine's data structures. The macros that help build them are engine macros. The fact we had a 2nd set in php.h was bogus. Zeev