[issue15530] Enhance Py_MIN and Py_MAX

Martin v. Löwis added the comment: > I am indifferent with respect to the use of the GCC extensions, but > getting rid of the umpteen different implementations of MIN/MAX is a > nice , albeit very minor, cleanup. I think that's a different issue from the one we have here, though (which speci

[issue15530] Enhance Py_MIN and Py_MAX

Meador Inge added the comment: I am indifferent with respect to the use of the GCC extensions, but getting rid of the umpteen different implementations of MIN/MAX is a nice , albeit very minor, cleanup. -- ___ Python tracker

[issue15530] Enhance Py_MIN and Py_MAX

Changes by Martin v. Löwis : -- resolution: -> rejected status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue15530] Enhance Py_MIN and Py_MAX

Martin v. Löwis added the comment: > The former. If C allows it then what's the point of special-casing > Py_MIN and Py_MAX to disallow it? "C allows it" includes cases like "C allows an the result to be implementation-defined, or an implementation-defined signal to be raised", and indeed, some

[issue15530] Enhance Py_MIN and Py_MAX

Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue15530] Enhance Py_MIN and Py_MAX

Antoine Pitrou added the comment: > >> I think the feature is somewhat desirable; I agree code combining > >> different types in MIN or MAX is flawed - if it is intentional, asking > >> for an explicit cast is not asking too much. > > > > I don't agree. Trying to battle with C's semantics doesn't

[issue15530] Enhance Py_MIN and Py_MAX

Martin v. Löwis added the comment: >> I think the feature is somewhat desirable; I agree code combining >> different types in MIN or MAX is flawed - if it is intentional, asking >> for an explicit cast is not asking too much. > > I don't agree. Trying to battle with C's semantics doesn't seem ver

[issue15530] Enhance Py_MIN and Py_MAX

Antoine Pitrou added the comment: Le vendredi 03 août 2012 à 12:15 +, Martin v. Löwis a écrit : > So compared to the traditional type checks: > a) this gives a hard compile error, whereas the existing check would > only produce warnings Warnings are quite visible already, and we try to silen

[issue15530] Enhance Py_MIN and Py_MAX

Martin v. Löwis added the comment: Victor hinted that it would detect errors when combining int and unsigned int. To elaborate, see the attached min.c. It gives [traditional MIN definition] [int, pointer] min.c:18: warning: comparison between pointer and integer min.c:18: warning: pointer/int

[issue15530] Enhance Py_MIN and Py_MAX

STINNER Victor added the comment: > I don't understand the point of your patch. Can you explain? Yes. It's explained in the comment of the two macros: "When compiled with GCC, check also that types of x and y are compatible at compile time." So it adds a cheap santity check at compile time.

[issue15530] Enhance Py_MIN and Py_MAX

Antoine Pitrou added the comment: > Yes. It's explained in the comment of the two macros: > > "When compiled with GCC, check also that types of x and y are > compatible at compile time." I'm sorry, that doesn't explain anything. The C compiler already checks types for you. So what does it bring

[issue15530] Enhance Py_MIN and Py_MAX

Antoine Pitrou added the comment: I don't understand the point of your patch. Can you explain? -- nosy: +pitrou ___ Python tracker ___ ___

[issue15530] Enhance Py_MIN and Py_MAX

STINNER Victor added the comment: > I think that's too late for 3.3. It's not a bug fix. Oops, I chose 3.3 instead of 3.4. Fixed. > If we use this kind of feature, we either need to declare a minimum supported > GCC version typeof() and __builtin_types_compatible_p() were introduced to gcc in

[issue15530] Enhance Py_MIN and Py_MAX

Martin v. Löwis added the comment: I think that's too late for 3.3. It's not a bug fix. If we use this kind of feature, we either need to declare a minimum supported GCC version (any GCC older than 10 years can be dropped IMO), or check for the specific version of GCC in which all the necessar

[issue15530] Enhance Py_MIN and Py_MAX

New submission from STINNER Victor: Attached patch enhances Py_MIN and Py_MAX to check that types of both arguments are compatible at compile time. Checks are only done if the compiler is GCC. The patch uses also Py_MIN and Py_MAX in more places. (The commit may be done in two parts.) ---