RE: API : constness ?

Discussion in 'Python' started by Tim Peters, May 30, 2004.

  1. Tim Peters

    Tim Peters Guest

    [Benoît Dejean]
    > i don't understand why the ANSI const keyword is never used in the API.


    It is used in the API, and more than once, but it isn't used as often as it
    could be used. It's more likely to appear in newer API functions. When
    Python was first written, most compilers were K&R, and Python avoided ANSI
    features until about a decade later (a C89 compiler is required now). A lot
    of the C API survived unchaged across all that time. There's no objection
    to slamming in consts now, but nobody has cared enough to bother doing so.
     
    Tim Peters, May 30, 2004
    #1
    1. Advertising

  2. Le Sun, 30 May 2004 08:31:36 -0400, Tim Peters a écrit :

    > [Benoît Dejean]
    >> i don't understand why the ANSI const keyword is never used in the API.

    >
    > It is used in the API, and more than once, but it isn't used as often as it
    > could be used. It's more likely to appear in newer API functions. When
    > Python was first written, most compilers were K&R, and Python avoided ANSI
    > features until about a decade later (a C89 compiler is required now). A lot
    > of the C API survived unchaged across all that time. There's no objection
    > to slamming in consts now, but nobody has cared enough to bother doing so.


    it's also for a simple reason, eg using PyArg_ParseTupleAndKeywords

    using const helps gcc to move these data to the text segment

    static const char * const kwlist[] = { "uri", "open_mode", "exclusive",
    "perm", NULL };

    or a better (but tricky) storage could be used to avoid relocation

    bust casting again again like this

    PyArg_ParseTupleAndKeywords(args, kwargs, "should be const char *",
    (char**)kwlist, ...

    is quite ugly ...
     
    =?iso-8859-1?q?Beno=EEt_Dejean?=, May 31, 2004
    #2
    1. Advertising

  3. Am Mo, den 31.05.2004 schrieb Benoît Dejean um 03:26:
    > it's also for a simple reason, eg using PyArg_ParseTupleAndKeywords
    >
    > using const helps gcc to move these data to the text segment

    Don't think so. At least not if you are compiling without
    -traditional or -fwritable-strings:
    andreas@andi-lap:~> cat t.c
    main() {
    char *x = "ABC";
    x[0] = 'D';
    }
    andreas@andi-lap:~> gcc -fwritable-strings -o t t.c
    andreas@andi-lap:~> ./t
    andreas@andi-lap:~> gcc -o t t.c
    andreas@andi-lap:~> ./t
    Speicherzugriffsfehler
    andreas@andi-lap:~>

    Andreas
     
    Andreas Kostyrka, May 31, 2004
    #3
  4. Le Mon, 31 May 2004 14:13:19 +0200, Andreas Kostyrka a écrit :

    > Don't think so. At least not if you are compiling without
    > -traditional or -fwritable-strings:

    of course, but these are basically deprecated and unsafe.
     
    =?iso-8859-1?q?Beno=EEt_Dejean?=, May 31, 2004
    #4
  5. On Mon, 31 May 2004 03:26:53 +0200, Benoît Dejean <>
    wrote:

    >using const helps gcc to move these data to the text segment


    This may sound terrible, but indeed the data that a
    "pointer to constant" is pointing to is not (in general)
    constant. Being a "pointer to constant" is a property of
    the *pointer*, not of the *pointed data*.

    Const pointers in interfaces are designed to be an help
    for the (distracted) programmers, they can't be an help
    for the compiler.

    That const-ness really helps or not is another issue...

    Andrea
     
    Andrea Griffini, Jun 1, 2004
    #5
  6. Andrea Griffini wrote:

    > This may sound terrible, but indeed the data that a
    > "pointer to constant" is pointing to is not (in general)
    > constant. Being a "pointer to constant" is a property of
    > the *pointer*, not of the *pointed data*.
    >
    > Const pointers in interfaces are designed to be an help
    > for the (distracted) programmers, they can't be an help
    > for the compiler.


    To his credit, he was talking about declaring an array of strings as
    const char *const. That is, he was indeed making the data he was
    passing in truly const. As others have pointed out, though, that
    doesn't guarantee that that data will be put in read-only memory, only
    that it makes it possible.

    --
    __ Erik Max Francis && && http://www.alcyone.com/max/
    / \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
    \__/ When you talk to her / Talk to her
    -- India Arie
     
    Erik Max Francis, Jun 1, 2004
    #6
  7. Tim Peters

    Isaac To Guest

    >>>>> "Erik" == Erik Max Francis <> writes:

    Erik> To his credit, he was talking about declaring an array of strings
    Erik> as const char *const. That is, he was indeed making the data he
    Erik> was passing in truly const. As others have pointed out, though,
    Erik> that doesn't guarantee that that data will be put in read-only
    Erik> memory, only that it makes it possible.

    This is not quite right. A string literal is always put into read-only
    memory, no matter whether you specify const or not. So:

    int main() {
    char *str = "abc";
    str[0] = '\b'; // segmentation fault
    }

    On the other hand, as I've stated in another thread, an array of initialized
    pointers can never be put into read-only memory in a module, due to other
    restrictions.

    Regards,
    Isaac.
     
    Isaac To, Jun 1, 2004
    #7
  8. Isaac To wrote:

    > This is not quite right. A string literal is always put into
    > read-only
    > memory, no matter whether you specify const or not.


    That's not true. It _can_ be put in read-only memory. It is not
    mandated to.

    > So:
    >
    > int main() {
    > char *str = "abc";
    > str[0] = '\b'; // segmentation fault
    > }


    No, this is undefined behavior. It's undefined behavior so that the
    implementation _can_ put the string literal in read-only memory, but the
    implementation is under no obligation to.

    --
    __ Erik Max Francis && && http://www.alcyone.com/max/
    / \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
    \__/ Chastity the most unnatural of the sexual perversions.
    -- Aldous Huxley
     
    Erik Max Francis, Jun 1, 2004
    #8
  9. On Mon, 31 May 2004 23:36:38 -0700, Erik Max Francis <>
    wrote:

    >To his credit, he was talking about declaring an array of strings as
    >const char *const. That is, he was indeed making the data he was
    >passing in truly const. As others have pointed out, though, that
    >doesn't guarantee that that data will be put in read-only memory, only
    >that it makes it possible.


    You can declare a constant pointer (you can't change
    the pointer) to constant data (you can't change the
    data). But still those properties are properties of
    the pointer, not of the data. I know it may be
    surprising at a first sight, but the code generated
    by the compiler is not allowed to assume that the
    "pointed to" data will not change; the reason is
    that the limit of "you can't change the data" is
    indeed just related to the pointer... in other words
    the limit is only that you can't change the data

    ==> USING THAT POINTER <==

    By no means you're stating the data is really constant.

    Note also that casting away const-ness from a pointer
    and changing the data is something that must be
    supported if the data is not really constant.
    In other words:

    void foo(const int *x)
    {
    int *y = (int *)x;
    ++(*y);
    }

    int main()
    {
    static int a = 3;
    foo(&a);
    // Here a will be 4
    ...
    }

    The above code is perfectly legal; looking at main()
    and at the declaration of foo the compiler cannot
    decide to put "a" in read-only memory.

    Declaring a parameter "const char *" is ONLY an help
    for the programmer; it adds NO useful information for
    an optimizer or code generator.
    This at least was the original idea of constness...
    I found myself in the quite blaspheme position of
    even questioning if the const specification is an
    help for the programmer or not; but this is a quite
    unrelated topic.

    Declaring a parameter "const char * const" is also
    IMO nonsense; the passed (pointer) value is local
    of the callee, changing it or not is not something
    the caller should be interested about. It adds just
    noise to the interface.

    To recap in C and C++ a "const int *" is not a pointer
    to a const int; an english description could probably
    be "a pointer to an int that can't be used for writing"
    (note that it says nothing about if what is pointed
    to can be changed or not).

    This looks quite OT for a python group, I'd suggest
    the interested ones to ask for better explanations
    in a C or C++ group about this topic.

    HTH
    Andrea
     
    Andrea Griffini, Jun 1, 2004
    #9
  10. Andrea Griffini wrote:

    > You can declare a constant pointer (you can't change
    > the pointer) to constant data (you can't change the
    > data). But still those properties are properties of
    > the pointer, not of the data. I know it may be
    > surprising at a first sight, but the code generated
    > by the compiler is not allowed to assume that the
    > "pointed to" data will not change; the reason is
    > that the limit of "you can't change the data" is
    > indeed just related to the pointer... in other words
    > the limit is only that you can't change the data
    >
    > ==> USING THAT POINTER <==
    >
    > By no means you're stating the data is really constant.


    You're eliminating an important distinction here, which is the
    difference between a pointer-to-const parameter, and data that is
    actually const. You're talking about a pointer-to-const parameter, I'm
    talking about data that's actually const. The original poster wrote
    code that created data that was actually const, and then passed it to a
    function that he wanted to take a pointer-to-const parameter.

    > Note also that casting away const-ness from a pointer
    > and changing the data is something that must be
    > supported if the data is not really constant.


    Yes, that is correct.

    > In other words:
    >
    > void foo(const int *x)
    > {
    > int *y = (int *)x;
    > ++(*y);
    > }
    >
    > int main()
    > {
    > static int a = 3;
    > foo(&a);
    > // Here a will be 4
    > ...
    > }
    >
    > The above code is perfectly legal; looking at main()
    > and at the declaration of foo the compiler cannot
    > decide to put "a" in read-only memory.


    Yes. And if a were declared

    static const int a = 3;

    it would be illegal. That is the case that I was discussing.

    --
    __ Erik Max Francis && && http://www.alcyone.com/max/
    / \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
    \__/ But who shall dwell in these worlds if they be inhabited?
    -- Johannes Kepler
     
    Erik Max Francis, Jun 1, 2004
    #10
  11. Le Tue, 01 Jun 2004 09:29:11 -0700, Erik Max Francis a écrit :

    > Isaac To wrote:
    >
    >> This is not quite right. A string literal is always put into
    >> read-only
    >> memory, no matter whether you specify const or not.


    true. but the pointer to it isn't

    and i was talking of a const char * kwlist[] { }
    obvious optimization is to declare kwlist as static. but when the module
    is loade, kwlist gets initialize. adding another const tags the whole
    kwlist as const and then totally readonly. therefor, your compiler is
    able to store kwlist (the array) in a RO segment.
     
    =?iso-8859-1?q?Beno=EEt_Dejean?=, Jun 1, 2004
    #11
  12. On Tue, 01 Jun 2004 11:42:03 -0700, Erik Max Francis <>
    wrote:

    >Yes. And if a were declared
    >
    > static const int a = 3;
    >
    >it would be illegal. That is the case that I was discussing.


    I completely missed the original poster point. Re-reading
    it indeed the literals could be in read-only memory, and
    the pointers to those literals could be too (if declared const).

    Sorry for all the nonsense babbling I posted...

    Andrea
     
    Andrea Griffini, Jun 1, 2004
    #12
  13. Tim Peters

    Isaac To Guest

    >>>>> "Benoît" == Benoît Dejean <> writes:

    Benoît> and i was talking of a const char * kwlist[] { } obvious
    Benoît> optimization is to declare kwlist as static. but when the module
    Benoît> is loade, kwlist gets initialize. adding another const tags the
    Benoît> whole kwlist as const and then totally readonly. therefor, your
    Benoît> compiler is able to store kwlist (the array) in a RO segment.

    The compiler is never capable to store kwlist in a RO segment if it is
    compiling to a module. See my 2 previous posts.

    Regards,
    Isaac.
     
    Isaac To, Jun 2, 2004
    #13
    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. Martin Magnusson

    Casting away constness

    Martin Magnusson, Nov 17, 2003, in forum: C++
    Replies:
    1
    Views:
    401
    tom_usenet
    Nov 17, 2003
  2. Richard Hayden
    Replies:
    1
    Views:
    755
    Rob Williscroft
    Nov 23, 2003
  3. =?iso-8859-1?q?Beno=EEt_Dejean?=

    API : constness ?

    =?iso-8859-1?q?Beno=EEt_Dejean?=, May 30, 2004, in forum: Python
    Replies:
    0
    Views:
    331
    =?iso-8859-1?q?Beno=EEt_Dejean?=
    May 30, 2004
  4. Delaney, Timothy C (Timothy)

    RE: API : constness ?

    Delaney, Timothy C (Timothy), May 31, 2004, in forum: Python
    Replies:
    5
    Views:
    293
    Andrea Griffini
    Jun 12, 2004
  5. Replies:
    14
    Views:
    843
    Ian Collins
    Apr 4, 2006
Loading...

Share This Page