[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

Roundup Robot added the comment: 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 h

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

Larry Hastings added the comment: 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). -- ___ Python tracker <

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

Jeffrey Armstrong added the comment: 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 (t

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

STINNER Victor added the comment: > 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 th

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

STINNER Victor added the comment: > 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 year

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

Georg Brandl added the comment: 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 combinati

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

Larry Hastings added the comment: 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. -- ___ Python tracker __

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

Jeffrey Armstrong added the comment: Georg: Sorry, that wasn't directed at you. Your comment snuck in before mine. It was more general frustration. -- ___ Python tracker ___ _

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

Georg Brandl added the comment: Jeffrey: I did not mean to devalue your patch, I just wanted to bring even more issues to Victor's attention. -- ___ Python tracker ___ _

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

Jeffrey Armstrong added the comment: 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 h

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

Georg Brandl added the comment: 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 thi

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

STINNER Victor added the comment: > 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. -- _

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

Roundup Robot added the comment: 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

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

Georg Brandl added the comment: Patch LGTM. -- nosy: +georg.brandl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

Jeffrey Armstrong added the comment: 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.

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

Jeffrey Armstrong added the comment: 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

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

Arfrever Frehtes Taifersar Arahesis added the comment: Maybe it is unnecessary strictness in Open Watcom compiler. If renaming was necessary, then I suggest utime_obj instead of ut. -- nosy: +Arfrever ___ Python tracker

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

Larry Hastings added the comment: 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? -- ___ Python tracker

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

Changes by Antoine Pitrou : -- nosy: +larry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors

New submission from Jeffrey Armstrong: 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 followin