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

Discussion in 'Python' started by Christian Seberino, Feb 10, 2004.

  1. 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
     
    Christian Seberino, Feb 10, 2004
    #1
    1. Advertising

  2. Re: Python.h problem-> /usr/include/python2.2/longobject.h:48:

    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
     
    Skip Montanaro, Feb 10, 2004
    #2
    1. Advertising

  3. Christian Seberino

    Guest

    Re: Python.h problem-> /usr/include/python2.2/longobject.h:48:

    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: (619) 553-9973
    Fax : (619) 553-6521
    Email:
    _______________________________________
     
    , Feb 10, 2004
    #3
  4. Re: Python.h problem-> /usr/include/python2.2/longobject.h:48:

    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
     
    Skip Montanaro, Feb 11, 2004
    #4
  5. Christian Seberino

    Guest

    Re: Python.h problem-> /usr/include/python2.2/longobject.h:48:

    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: (619) 553-9973
    Fax : (619) 553-6521
    Email:
    _______________________________________
     
    , Feb 11, 2004
    #5
  6. Re: Python.h problem-> /usr/include/python2.2/longobject.h:48:

    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
     
    Skip Montanaro, Feb 11, 2004
    #6
  7. Re: Python.h problem-> /usr/include/python2.2/longobject.h:48:

    At some point, 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?


    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
     
    David M. Cooke, Feb 11, 2004
    #7
  8. Re: Python.h problem-> /usr/include/python2.2/longobject.h:48: warning:ISO C89 does not support `long long'

    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
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Feb 11, 2004
    #8
  9. Re: Python.h problem-> /usr/include/python2.2/longobject.h:48: warning:ISO C89 does not support `long long'

    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
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Feb 11, 2004
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    13
    Views:
    6,520
    Dave Thompson
    Dec 20, 2004
  2. ISO C89 and ISO C99

    , Dec 10, 2004, in forum: C Programming
    Replies:
    18
    Views:
    564
    Dave Thompson
    Dec 20, 2004
  3. G Patel
    Replies:
    1
    Views:
    571
  4. shankha
    Replies:
    0
    Views:
    739
    shankha
    May 5, 2009
  5. anne001
    Replies:
    1
    Views:
    592
Loading...

Share This Page