Antoine Pitrou added the comment:
I don't understand the point of your patch. Can you explain?
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15530
___
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? And
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.
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:
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 silence
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 very
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 seem very
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15530
___
___
Python-bugs-list
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
Changes by Martin v. Löwis mar...@v.loewis.de:
--
resolution: - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15530
___
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 rep...@bugs.python.org
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
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.)
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
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
15 matches
Mail list logo
