The PPC Tiger buildbot build output shows (e.g., for 2.7):

/Users/buildbot/buildarea/2.7.parc-tiger-1/build/Modules/_multiprocessing/semaphore.c:421: warning: initialization makes pointer from integer without a cast
/Users/buildbot/buildarea/2.7.parc-tiger-1/build/Modules/_multiprocessing/semaphore.c:441: warning: comparison between pointer and integer
/Users/buildbot/buildarea/2.7.parc-tiger-1/build/Modules/_multiprocessing/semaphore.c:454: warning: comparison between pointer and integer
/Users/buildbot/buildarea/2.7.parc-tiger-1/build/Modules/_multiprocessing/semaphore.c:476: warning: comparison between pointer and integer

This looks as though it should be investigated;  these comparisons are almost certainly doing the wrong thing.

Including Antoine in the nosy because he was the last person to touch this code (I think).

The same warnings show up on the x86 Tiger buildbot.  Leopard and Snow Leopard seem to be fine, though.

See also:

http://paulbeachsblog.blogspot.com/2007/12/building-firebird-20x-macos-semaphoreh.html

It looks as though SEM_FAILED is defined as -1 on OS X 10.4, and (sem_t *)-1 on OS X 10.5+, so it's really a bug in the OS X header file.  Possible workarounds:

(1) write (sem_t *)SEM_FAILED everywhere in the multiprocessing code
(2) define a PY_SEM_FAILED macro and use that
(3) don't worry, be happy;  i.e., just ignore these warnings on OS X 10.4, content that they're not a real problem (provided we're not trying to compile with a C++ compiler, that is).

BTW, as far as I can tell from the standard (see e.g., section 6.5.9p2 of

www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

), comparison between a pointer and an integer gives undefined behaviour, except in the case where the integer can be interpreted as a null pointer constant (which is not the case here).  I'm assuming that the reason that gcc only gives a warning here rather than an error is that its general machinery can only tell that we're comparing an integer with a pointer, which *could* be valid C if that integer is 0.

So I do think this should be fixed, one way or another.

> (2) define a PY_SEM_FAILED macro and use that

That sounds reasonable.

I agree with Antoine

Actually, since SEM_FAILED isn't public and is only used in one file, it seems simplest just to redefine it on Mac.  Here's a patch.

looks fine mark

New changeset a5b49db3383d by Richard Oudkerk in branch '3.2':
Issue #9586: Redefine SEM_FAILED on MacOSX to keep compiler happy.
http://hg.python.org/cpython/rev/a5b49db3383d

New changeset a70db584e897 by Richard Oudkerk in branch '3.3':
Issue #9586: Merge
http://hg.python.org/cpython/rev/a70db584e897

New changeset 92990dd91b07 by Richard Oudkerk in branch 'default':
Issue #9586: Merge.
http://hg.python.org/cpython/rev/92990dd91b07

New changeset 395976a1f26f by Richard Oudkerk in branch '2.7':
Issue #9586: Redefine SEM_FAILED on MacOSX to keep compiler happy.
http://hg.python.org/cpython/rev/395976a1f26f