Re: Question About const Keyword

Discussion in 'C Programming' started by Lanarcam, Apr 17, 2012.

  1. Lanarcam

    Lanarcam Guest

    Le 17/04/2012 21:58, David T. Ashley a écrit :
    > Consider the following function.
    >
    > void or_me_please_thank_you(unsigned *target, const unsigned *source)
    > {
    > *target |= *source;
    > }
    >
    > I was reluctant to declare the second parameter "const" because
    > someone might call the function with the same pointer for both
    > parameters.
    >
    > But then I thought, if someone does this, the array will be unchanged,
    > because a | a == a, so it would be const then too.
    >
    > Does "const" mean that the memory location won't be changed, or that
    > it won't be written? (These are two different conditions.)
    >
    > Is the second parameter above const if someone is allowed to pass the
    > same pointer for both parameters?
    >

    The compiler can't check whether the pointers values are identical
    since this a run time condition not a compile time one.

    The compiler only ensures that *source is not a l-value in
    any expression.
    Lanarcam, Apr 17, 2012
    #1
    1. Advertising

  2. Lanarcam

    Lanarcam Guest

    Le 17/04/2012 22:17, David T. Ashley a écrit :
    > On Tue, 17 Apr 2012 22:06:42 +0200, Lanarcam<>
    > wrote:
    >
    >> Le 17/04/2012 21:58, David T. Ashley a écrit :
    >>> Consider the following function.
    >>>
    >>> void or_me_please_thank_you(unsigned *target, const unsigned *source)
    >>> {
    >>> *target |= *source;
    >>> }
    >>>
    >>> I was reluctant to declare the second parameter "const" because
    >>> someone might call the function with the same pointer for both
    >>> parameters.
    >>>
    >>> But then I thought, if someone does this, the array will be unchanged,
    >>> because a | a == a, so it would be const then too.
    >>>
    >>> Does "const" mean that the memory location won't be changed, or that
    >>> it won't be written? (These are two different conditions.)
    >>>
    >>> Is the second parameter above const if someone is allowed to pass the
    >>> same pointer for both parameters?
    >>>

    >> The compiler can't check whether the pointers values are identical
    >> since this a run time condition not a compile time one.
    >>
    >> The compiler only ensures that *source is not a l-value in
    >> any expression.

    >
    > That isn't my question.
    >
    > It goes without saying that you can always find a way to assign
    > pointers so that target==source and the compiler won't be able to
    > detect this.
    >
    > My question is about the true meaning of const.
    >
    > Is an object that is written with the same value it had previously
    > truly "const", or not?
    >

    "const" is a compile time instruction, it doesn't mean that the
    object won't be modified.

    You can even declare:

    const volatile int i;

    I don't have a better explanation, sorry.
    Lanarcam, Apr 17, 2012
    #2
    1. Advertising

  3. Lanarcam

    Ben Pfaff Guest

    David T. Ashley <> writes:

    > My question is about the true meaning of const.
    >
    > Is an object that is written with the same value it had previously
    > truly "const", or not?


    An object that is declared as const is not modifiable.
    Attempting to modify it is a constraint violation or yields
    undefined behavior, depending on how you do it.

    For example, the following is a constraint violation and hence
    requires a diagnostic:

    const int x;
    x = 0;

    Modifying an object that is not declared const (or otherwise
    read-only, e.g. a string literal), but was pointed to through a
    "const <type> *" pointer, does not violate anything except good
    taste.

    For example, the following is a valid (though silly) way to
    modify x:

    int x;
    const int *ip = &x;

    *(int *) ip = 0;
    Ben Pfaff, Apr 17, 2012
    #3
  4. Lanarcam

    James Kuyper Guest

    On 04/17/2012 05:12 PM, Ben Pfaff wrote:
    ....
    > An object that is declared as const is not modifiable.
    > Attempting to modify it is a constraint violation or yields
    > undefined behavior, depending on how you do it.


    That's only true if it's defined as const (6.7.3p6). A declaration that
    is not a definition does not have that effect.
    James Kuyper, Apr 17, 2012
    #4
  5. Lanarcam

    Ben Pfaff Guest

    James Kuyper <> writes:

    > On 04/17/2012 05:12 PM, Ben Pfaff wrote:
    > ...
    >> An object that is declared as const is not modifiable.
    >> Attempting to modify it is a constraint violation or yields
    >> undefined behavior, depending on how you do it.

    >
    > That's only true if it's defined as const (6.7.3p6). A declaration that
    > is not a definition does not have that effect.


    I agree, but I'm not sure whether the distinction matters.
    "const int x; int x;" is a constraint violation, I believe.
    Perhaps function parameters are one context where it matters?
    Ben Pfaff, Apr 17, 2012
    #5
  6. Lanarcam

    Stefan Ram Guest

    David T. Ashley <> writes:
    >>The compiler only ensures that *source is not a l-value in
    >>any expression.

    >That isn't my question.


    Possibly, it was supposed to be an /answer/ to your
    question, not to be your question.

    >My question is about the true meaning of const.


    True meaning. In the strict sense, only assertions can be
    true or false, and »meaning« is not an assertion. In the
    strict sense, only entity identifiers have a meaning
    (which is the entity identified, of course), but »const«
    does not name an entity. »const« appears as a /part/ of
    type specifiers, who do have a meaning, which is a type.

    »*source« (in the scope of »const unsigned *source«) has a
    const-qualified type and thus it is not a modifiable lvalue
    by N1570 6.3.2.1p1.
    Stefan Ram, Apr 17, 2012
    #6
  7. Lanarcam

    James Kuyper Guest

    On 04/17/2012 05:44 PM, Ben Pfaff wrote:
    > James Kuyper <> writes:
    >
    >> On 04/17/2012 05:12 PM, Ben Pfaff wrote:
    >> ...
    >>> An object that is declared as const is not modifiable.
    >>> Attempting to modify it is a constraint violation or yields
    >>> undefined behavior, depending on how you do it.

    >>
    >> That's only true if it's defined as const (6.7.3p6). A declaration that
    >> is not a definition does not have that effect.

    >
    > I agree, but I'm not sure whether the distinction matters.
    > "const int x; int x;" is a constraint violation, I believe.
    > Perhaps function parameters are one context where it matters?


    That's my understanding:

    const int x;
    int func(const int *p)
    {
    return *p;
    }

    Both x and *p have been declared const. x has been defined as const,
    while *p is not defined at all, at least not in this part of the program.
    James Kuyper, Apr 17, 2012
    #7
  8. Lanarcam

    Ben Pfaff Guest

    James Kuyper <> writes:

    > On 04/17/2012 05:44 PM, Ben Pfaff wrote:
    >> James Kuyper <> writes:
    >>
    >>> On 04/17/2012 05:12 PM, Ben Pfaff wrote:
    >>> ...
    >>>> An object that is declared as const is not modifiable.
    >>>> Attempting to modify it is a constraint violation or yields
    >>>> undefined behavior, depending on how you do it.
    >>>
    >>> That's only true if it's defined as const (6.7.3p6). A declaration that
    >>> is not a definition does not have that effect.

    >>
    >> I agree, but I'm not sure whether the distinction matters.
    >> "const int x; int x;" is a constraint violation, I believe.
    >> Perhaps function parameters are one context where it matters?

    >
    > That's my understanding:
    >
    > const int x;
    > int func(const int *p)
    > {
    > return *p;
    > }
    >
    > Both x and *p have been declared const. x has been defined as const,
    > while *p is not defined at all, at least not in this part of the program.


    I don't think that there is a declaration or a definition for
    '*p' here. I've never heard of anyone talk about a declaration
    of an expression like that.

    This is what I meant by "function parameters". Below, 'x' is
    declared, but not defined, as "const":

    void func(const int x);
    void func(int x)
    {
    x = 0;
    }
    Ben Pfaff, Apr 17, 2012
    #8
  9. Lanarcam

    Tim Rentsch Guest

    Ben Pfaff <> writes:

    > James Kuyper <> writes:
    >
    >> On 04/17/2012 05:44 PM, Ben Pfaff wrote:
    >>> James Kuyper <> writes:
    >>>
    >>>> On 04/17/2012 05:12 PM, Ben Pfaff wrote:
    >>>> ...
    >>>>> An object that is declared as const is not modifiable.
    >>>>> Attempting to modify it is a constraint violation or yields
    >>>>> undefined behavior, depending on how you do it.
    >>>>
    >>>> That's only true if it's defined as const (6.7.3p6). A declaration that
    >>>> is not a definition does not have that effect.
    >>>
    >>> I agree, but I'm not sure whether the distinction matters.
    >>> "const int x; int x;" is a constraint violation, I believe.
    >>> Perhaps function parameters are one context where it matters?

    >>
    >> That's my understanding:
    >>
    >> const int x;
    >> int func(const int *p)
    >> {
    >> return *p;
    >> }
    >>
    >> Both x and *p have been declared const. x has been defined as const,
    >> while *p is not defined at all, at least not in this part of the program.

    >
    > I don't think that there is a declaration or a definition for
    > '*p' here. I've never heard of anyone talk about a declaration
    > of an expression like that.
    >
    > This is what I meant by "function parameters". Below, 'x' is
    > declared, but not defined, as "const":
    >
    > void func(const int x);
    > void func(int x)
    > {
    > x = 0;
    > }


    There is not one 'x' but two. One of them is declared 'const',
    the other is not. Compare:

    void func( const int aardvark );

    void
    func( int zebra ){
    zebra = 0;
    }

    A particular identifier is either const or it isn't, and all
    declarations (and any definition) for the identifier must agree
    on its const-ness. The function parameter case is confusing
    because the identifiers in a prototype are not the same as those
    in the function definition (or indeed in other prototypes).
    Tim Rentsch, May 8, 2012
    #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. coala
    Replies:
    3
    Views:
    374
    coala
    Sep 6, 2006
  2. coala
    Replies:
    1
    Views:
    590
    Victor Bazarov
    Sep 6, 2006
  3. Replies:
    11
    Views:
    1,102
  4. Javier
    Replies:
    2
    Views:
    561
    James Kanze
    Sep 4, 2007
  5. 0m
    Replies:
    26
    Views:
    1,116
    Tim Rentsch
    Nov 10, 2008
Loading...

Share This Page