[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers

STINNER Victor added the comment: The initial issue is fixed in 3.7 and master branches. If you want to work on related issue like WIN32_LEAN_AND_MEAN, please open a separated issue. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed

[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers

STINNER Victor added the comment: New changeset 791e5fcbab9e444b62d13d08707cbbbeb9406297 by Victor Stinner (Erik Janssens) in branch '3.7': bpo-36965: Fix includes in main.c on Windows with non-MSC compilers (GH-13421) (GH-13471)

[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers

Change by Erik Janssens : -- pull_requests: +13401 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers

Eryk Sun added the comment: > FSCTL_GET_REPARSE_POINT is not exported with WIN32_LEAN_AND_MEAN You can explicitly include "winioctl.h" after "windows.h". Getting it from "windows.h" is indirect via "winscard.h" (smart card services), which will be skipped if either WIN32_LEAN_AND_MEAN or

[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers

STINNER Victor added the comment: > WIN32_LEAN_AND_MEAN is defined by Include/internal/pycore_condvar.h (...) It would be nice to get ride of #include in Python headers. The was introduced by this commit: commit 2ebc5ce42a8a9e047e790aefbf9a94811569b2b6 Author: Eric Snow Date: Thu Sep 7

[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers

STINNER Victor added the comment: eryksun commented there, but I prefer to discuss here: https://github.com/python/cpython/commit/925af1d99b69bf3e229411022ad840c5a0cfdcf8#commitcomment-33617265 ""Windows.h" was already being included, as I mentioned on the issue tracker, because we certainly

[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers

STINNER Victor added the comment: New changeset 925af1d99b69bf3e229411022ad840c5a0cfdcf8 by Victor Stinner (Erik Janssens) in branch 'master': bpo-36965: Fix includes in main.c on Windows with non-MSC compilers (GH-13421)

[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers

Eryk Sun added the comment: "crtdbg.h" doesn't provide STATUS_CONTROL_C_EXIT, but it should be fine to remove it anyway. I think it was left behind by accident in 2007. It was added to support a PYTHONNOERRORWINDOW environment variable, but then this idea was dropped in favor of extending

[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers

Erik Janssens added the comment: PR has been changed to include "windows.h" ... -- ___ Python tracker ___ ___ Python-bugs-list

[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers

Erik Janssens added the comment: ok, thank you for the advice, I'll keep it in mind and adapt the PR ! -- ___ Python tracker ___

[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers

Steve Dower added the comment: Some people say "windows.h" is the only one you're ever supposed to include, so if that works best, let's go with that :) -- ___ Python tracker

[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers

Erik Janssens added the comment: including "winnt.h" gives me compilation problems with other undefined types. however, simply including "windows.h" instead of both includes compiles just fine. so maybe that is sufficient ?? -- ___ Python

[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers

Steve Dower added the comment: Is including just "winnt.h" sufficient? It's very hard to tell which Windows headers are "public" vs "internal", but winternl.h is certainly one of the internal ones (according to the big warning comment at the top of the file) --

[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers

Erik Janssens added the comment: According to the Microsoft documentation at https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/using-ntstatus-values system-supplied status codes are defined in ntstatus.h. and the NTSTATUS type is defined in ntdef.h PR 13421 includes both

[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers

Change by Erik Janssens : -- keywords: +patch pull_requests: +13330 stage: -> patch review ___ Python tracker ___ ___

[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers

Change by SilentGhost : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers

New submission from Erik Janssens : in Modules/main.c STATUS_CONTROL_C_EXIT is included conditionally if compiling when _MSC_VER is defined. Later on STATUS_CONTROL_C_EXIT is used if MS_WINDOWS is defined. This breaks compilation of main.c with any non MSC compiler while compiling for MS