Python.h problem-> /usr/include/python2.2/longobject.h:48: warning: ISO C89 does not support `long long'

[Christian Seberino]

c extension compilation gives this gripe about python itself with
-Wall and -pedantic switches -->
/usr/include/python2.2/longobject.h:48: warning: ISO C89 does not
support `long long'

Is there any way to avoid this?

Chris

[Skip Montanaro]

Chris> c extension compilation gives this gripe about python itself with
Chris> -Wall and -pedantic switches -->
Chris> /usr/include/python2.2/longobject.h:48: warning: ISO C89 does not
Chris> support `long long'

Chris> Is there any way to avoid this?

Sure. Get rid of the -pedantic switch...

Skip

[seberino]

Skip

Thanks for the help.
I agree. Perhaps I'm being "pedantic" :) but I was just
curious if Python source is using stuff that is NOT ANSI C.

Is "long long" an extension of ANSI C? That Python uses?

Chris

On Tue, Feb 10, 2004 at 05:02:10PM -0600, Skip Montanaro wrote:

Chris> c extension compilation gives this gripe about python itself with
Chris> -Wall and -pedantic switches -->
Chris> /usr/include/python2.2/longobject.h:48: warning: ISO C89 does not
Chris> support `long long'

Chris> Is there any way to avoid this?

Sure. Get rid of the -pedantic switch...

Skip

--
_______________________________________

Christian Seberino, Ph.D.
SPAWAR Systems Center San Diego
Code 2872
49258 Mills Street, Room 158
San Diego, CA 92152-5385
U.S.A.

Phone: [phone]
Fax : [phone]
Email: se******@spawar.navy.mil
_______________________________________

[Skip Montanaro]

Chris> Is "long long" an extension of ANSI C? That Python uses?

Yup. Python's build process knows the difference between 'long long' (the
way GCC spells it) and _int64 (the way MSVC spells it). No other extensions
are currently supported. Are there other ways to spell "64-bit int" in use
at the moment?

Skip

[David M. Cooke]

At some point, Skip Montanaro <sk**@pobox.com> wrote:

Chris> Is "long long" an extension of ANSI C? That Python uses?

Yup. Python's build process knows the difference between 'long long' (the
way GCC spells it) and _int64 (the way MSVC spells it). No other extensions
are currently supported. Are there other ways to spell "64-bit int" in use
at the moment?

Well, in C99 it's int64_t (which is guaranteed to be a 64-bit signed
integer). Or int_least64_t (at least 64 bits) or int_fast64_t (native
type with at least 64 bits that's the fastest of the alternatives).

Mind you, with GCC they're all typedef'ed to long long int (or long
int for 64-bit platforms).

Hmm, does PY_LONG_LONG have to be (at least) 64-bits? A quick grep
through the source seems to suggest that it's used as a large integer
type -- not as something that holds at least 64 bits.

--
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|cookedm(at)physics(dot)mcmaster(dot)ca

[seberino]

Skip

Thanks, that explains a lot.

Extensions to ANSI C don't cause any problems
per se that I can think of.

However, I know in near future all Python
integers will be of type "Python long" and there
won't be "Python ints" anymore IIRC.

I wonder if Python source will still use 64 bit ints then in
implementation.

chris

On Tue, Feb 10, 2004 at 06:50:26PM -0600, Skip Montanaro wrote:

Chris> Is "long long" an extension of ANSI C? That Python uses?

Yup. Python's build process knows the difference between 'long long' (the
way GCC spells it) and _int64 (the way MSVC spells it). No other extensions
are currently supported. Are there other ways to spell "64-bit int" in use
at the moment?

Skip

--
_______________________________________

Christian Seberino, Ph.D.
SPAWAR Systems Center San Diego
Code 2872
49258 Mills Street, Room 158
San Diego, CA 92152-5385
U.S.A.

Phone: [phone]
Fax : [phone]
Email: se******@spawar.navy.mil
_______________________________________

[Skip Montanaro]

Chris> However, I know in near future all Python integers will be of
Chris> type "Python long" and there won't be "Python ints" anymore IIRC.

Chris> I wonder if Python source will still use 64 bit ints then in
Chris> implementation.

Yes, it still will. If you peek a bit into the source, take a look at
Include/longobject.h. You'll see:

#ifdef HAVE_LONG_LONG
PyAPI_FUNC(PyObject *) PyLong_FromLongLong(PY_LONG_LONG);
PyAPI_FUNC(PyObject *) PyLong_FromUnsignedLongLong(unsigned PY_LONG_LONG);
PyAPI_FUNC(PY_LONG_LONG) PyLong_AsLongLong(PyObject *);
PyAPI_FUNC(unsigned PY_LONG_LONG) PyLong_AsUnsignedLongLong(PyObject *);
PyAPI_FUNC(unsigned PY_LONG_LONG) PyLong_AsUnsignedLongLongMask(PyObject *);
#endif /* HAVE_LONG_LONG */

These declarations allow long long integers to be converted to Python long
integers. (There are other similar uses in the source code.) Those sorts
of conversions will still be desirable even after the int->long merger is
complete. As Tim pointed out 'long long' is in C99, so over time, this sort
of usage will become more mainstream.

Skip

[Martin v. Löwis]

David M. Cooke wrote:

Hmm, does PY_LONG_LONG have to be (at least) 64-bits? A quick grep
through the source seems to suggest that it's used as a large integer
type -- not as something that holds at least 64 bits.

No. Instead, PY_LONG_LONG should be intmax_t. In particular, it should
be large enough to hold a file size, and a time_t.

Regards,
Martin

[Martin v. Löwis]

se******@spawar.navy.mil wrote:

However, I know in near future all Python
integers will be of type "Python long" and there
won't be "Python ints" anymore IIRC.
You might remember incorrectly, atleast with respect
to the time scale in which this is happening.
I wonder if Python source will still use 64 bit ints then in
implementation.

C ints and long longs have nothing to do with Python
ints and longs. A Python int is implemented with a C long,
and a Python long is not implemented with any primitive type
(instead, it is implemented as an array of C shorts).

In any case, Python will continue to use the PY_LONG_LONG
type even if Python ints would go away.

Regards,
Martin