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.
Jakub
--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
