[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Koji cannot build openldap

On Fri, Aug 03, 2007 at 08:45:53AM +0200, Jan Safranek wrote:
> Maybe POSIX does allow such behavior, but it will break lot of packages 
> - for example all packages who use Berkeley DB (which is my case).  I
> Patching the DB would result in >500 changed lines and I am bit 
> skeptical about upstream accepting such patch - it would break API 
> compatibility.

Excuse me, but how does adding a parenthesis pair affect API compatibility?
If you write (dbm->open) (one, two, three, four); then it is the right
way to avoid open (or replace open with any kind of standard function
defined in the system headers) from being expanded as function-like macro.

> Is here any way how to tell compiler/glibc not to define 
> open() as macro and still have -D_FORTIFY_SOURCE=2?

You can #undef open after including the standard headers, and eventhough
even this is standard conforming way to deal with it, you then lose
all the checking in case you use a real 2 arguments open anywhere.
The new macro will for
  open ("abc", O_CREAT | O_RDWR);
issue a compile error, for
  open ("abc", O_RDWR);
it will just call the normal open with two arguments, for
  open ("abc", flags, 0644)
normal open with 3 arguments, but for
  open ("abc", flags);
where it can't find out at compile time whether flags contains
O_CREAT or not will arrange a special checking open alternate
entry point to be called, which will check that flags doesn't contain
O_CREAT at runtime.
When you use parenthesis, you get both standard conforming code and
the open argument checking for when it is a real call.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]