>Number: 1653 >Category: apache-api >Synopsis: Conflict of routine 'palloc' name/parameters with other >software (PostgreSQL) >Confidential: no >Severity: critical >Priority: medium >Responsible: apache >State: open >Class: change-request >Submitter-Id: apache >Arrival-Date: Sun Jan 11 20:20:00 PST 1998 >Last-Modified: >Originator: [EMAIL PROTECTED] >Organization: apache >Release: 1.3 >Environment: Linux 2.0.33, gcc etc - Not Relevant to problem >Description: I'm writing a user module for apache that is using the PostgreSQL 6.2.1 C client api. This API has a routine called 'palloc'. The Apache server has it's own routine called 'palloc'. The routines have different parameters. The name conflict needs to be removed - I have submitted a Bug report to the postgres team, and will modify the Apache code as a workaround, but the same problem could easily occur with Apache routines which use common names and other ill behaved product API's (Oracle ?).
>How-To-Repeat: Add the Postgres #include 'libpq-fe.h' to the start of 'mod_usertrack'. >Fix: --- partial solution to namespace conflicts (common routines only) --- Change the internal name of Apache's palloc routine to 'ap_palloc' [a very non-standard name] and change 'alloc.h' to #define palloc to refer to the 'ap_palloc' routine if USE_AP_PALLOC is not defined. IE. #ifndef USE_AP_PALLOC #define palloc(a,b) ap_alloc(a,b) #endif (The same is needed for 'pcalloc', 'pstrdup', 'pstrndup' and 'pstrcat') Impact of change is reduced to the 'alloc.c' and 'alloc.h' routines (plus any naughty routines that dont have a #include 'alloc.h' but still use 'palloc') This allows a developer of a user module to utilise other tools which want to supply their own 'palloc' routine and still have access to the core Apache routines via their real internal names. %0 >Audit-Trail: >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include <[EMAIL PROTECTED]> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ]
