Under certain circumstances, Modules/posixmodule.c will fail to compile due to a number of utime-related functions using a variable named "utime" when a function named "utime" already exists in the compiler's C header files.  Specifically, if the following are undefined:

HAVE_UTIMENSAT
HAVE_UTIMES

and the following are defined:

HAVE_UTIMENSAT
HAVE_LUTIMES
HAVE_UTIME_H

the compiler will fail because the UTIME_TO_UTIMBUF module attempts to access utime->now when utime is acutually a function included from utime.h.

I've attached a patch that renames the uname functions' parameter "utime" to "ut" to avoid the conflict.

This bug was encountered using Open Watcom 2.0 (owcc) under GNU/Linux 32-bit.

I don't understand.  If utime is a *function*, then the local variable should simply take precedence.  Do you possibly mean that utime is a *macro*?

What compilation error do you get?

Maybe it is unnecessary strictness in Open Watcom compiler.

If renaming was necessary, then I suggest utime_obj instead of ut.

Under the conditions I described in Modules/posixmodules.c on line 4815, the utime() function is called.  With the current code, the following correct compiler error is emitted:

./Modules/posixmodule.c(4815): Error! E1012: Expression is not a function

The above occurs because utime is treated as a local variable and an attempt is made at calling it as a function.

The use of a possible (and fairly standard) function name as a local variable is unfortunate, and I'm guessing these conditions haven't been tested in a while.

So in my original report, I actually got things backwards.  The failure is because utime is a local variable, but a call to utime() is then attempted.

Regardless, the code is still completely broken in Modules/posixmodule.c under the conditions I described.

Patch LGTM.

New changeset 58601c36a357 by Victor Stinner in branch '3.4':
Issue #22568: Fix compilation of posixmodule.c with Open Watcom: rename "utime"
https://hg.python.org/cpython/rev/58601c36a357

New changeset 588657f910ac by Victor Stinner in branch 'default':
(Merge 3.4) Issue #22568: Fix compilation of posixmodule.c with Open Watcom:
https://hg.python.org/cpython/rev/588657f910ac

> Patch LGTM.

The patch is safe. Even if I don't care of the Open Watcom compiler, the patch is simple enough to be accepted. (It doesn't add crazy #ifdef WATCOM).

I commited your change, thanks Jeffrey for your contribution.

UTIME_TO_UTIMBUF actually still looks dodgy and UTIME_TO_TIME_T is completely broken.

* There should be only one "utimbuf" structure, because it already contains both times (see man 2 utime).

* UTIME_TO_TIME_T uses a type called "struct timet" which I don't think exists, it should be "time_t *".  The "&" operator is wrong.

My patch merely fixes broken code that wasn't being used by Python's "supported" compilers under most common configurations.  It's really independent of compiler.  I realize nobody here cares about Open Watcom as a supported compiler; the Python community has made that *abundantly* clear.

Jeffrey: I did not mean to devalue your patch, I just wanted to bring even more issues to Victor's attention.

Georg: Sorry, that wasn't directed at you.  Your comment snuck in before mine.  It was more general frustration.

Georg, you want to take a swing at it, be my guest.  The current mess is my doing, and I claim this is an *improvement* over what came before.

I'm sure you've improved the code. Without looking at the hg history, you've likely just inherited the broken C code from the previous version and made it prettier :)

Since this breakage has not been reported so far, the last two #elses appear to be a combination of #defines that is very rare.

> I realize nobody here cares about Open Watcom as a supported compiler; the Python community has made that *abundantly* clear.

I only heard once about Open Watcom, maybe 1 or 2 years ago. I see on http://www.openwatcom.org/ that the latest release is 4 years old.

Open Watcom is not packaged in my Linux Fedora 20. I downloaded the source code of the release 1.9 and I tried to compile it with build.sh. I had to modify build.sh to use bash instead of sh. Than the compilation of c/mglob.c failed with "Unknown CPU architecture", it looks like x86_64 CPU is not supported :-(

On which platform are you working? Dummy question, why not using a different compiler like GCC or Clang?

It was discussed recently to define rules to support a platform (ex: OpenBSD). For example, a requirement to have a buildbot and someone able to fix issues. I'm trying to help to support AIX even if I don't consider the platform important enough and I don't like proprietary software :) There is a buildbot and a developer proposing regulary patches.

If you want an official and full support of OpenWatcom, it's better to discuss it on the python-dev mailing list.

> UTIME_TO_UTIMBUF actually still looks dodgy and UTIME_TO_TIME_T is completely broken.

Agreed. It looks like dead code which was never used nor tested.

@Jeffrey: Is your patch enough to compile posixmodule.c with OpenWatcom?

If it's enough, I will close the issue.

The last "official" Open Watcom release (1.9) is indeed quite dated.  The codebase was forked for a variety of reasons where development continues: 

https://github.com/open-watcom/open-watcom-v2

The current development release does indeed build on x86_64 (the build system is quite complicated).  I'm running Open Watcom nightly builds on Debian Wheezy x86 myself.  I've mentioned supporting OW in Python, most notably in a PyCon lightning talk last year, but there really seems to be no interest even if there are some benefits.  OW allows building the full interpreter and standard library on Windows, for example, without any MS tooling.

I was using it in this particular case as a benchmark for compile times for a presentation in a few weeks.  OW is able to build the interpreter in ~25sec whereas GCC is taking 1min 10sec on my desktop.  I don't have any plans to pursue Python support for OW any further, although I'm open to the idea.

This patch is enough to compile *this portion* of Modules/posixmodule.c with OW, but, no, it is not sufficient to compile the whole file.  There are two more places where some preprocessor definitions cause issues.  One is OW-specific, and I don't plan on filing a bug against it.  The other is #22579.  I only filed this bug because the code was broken.

I remember manually setting/unsetting #defines to force alternate compilation paths.  But I think there were one or two that I didn't have library support for (testing on Linux and Windows).

New changeset 922526816b25 by Georg Brandl in branch '3.4':
Closes #22568: fix UTIME_TO_* macros in posixmodule for rare cases.
https://hg.python.org/cpython/rev/922526816b25

New changeset 0b2c7ea86d96 by Georg Brandl in branch 'default':
#22568: merge with 3.4
https://hg.python.org/cpython/rev/0b2c7ea86d96