Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #89092 > unrolled thread

*&aptr , &*aptr question

Back to article view | Back to comp.lang.c

Contents

  *&aptr , &*aptr question G G <gdotone@gmail.com> - 2016-06-14 13:43 -0700
    Re: *&aptr , &*aptr question Richard Heathfield <rjh@cpax.org.uk> - 2016-06-14 22:01 +0100
      Re: *&aptr , &*aptr question Ike Naar <ike@iceland.freeshell.org> - 2016-06-14 21:20 +0000
        Re: *&aptr , &*aptr question G G <gdotone@gmail.com> - 2016-06-14 14:38 -0700
      Re: *&aptr , &*aptr question Richard Heathfield <rjh@cpax.org.uk> - 2016-06-14 22:42 +0100
      Re: *&aptr , &*aptr question Ken Brody <kenbrody@spamcop.net> - 2016-06-15 14:22 -0400
        Re: *&aptr , &*aptr question Richard Heathfield <rjh@cpax.org.uk> - 2016-06-15 19:24 +0100
    Re: *&aptr , &*aptr question "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-14 17:17 -0400
    Re: *&aptr , &*aptr question Keith Thompson <kst-u@mib.org> - 2016-06-14 14:37 -0700
    Re: *&aptr , &*aptr question "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-14 17:40 -0400
      Re: *&aptr , &*aptr question "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-14 17:49 -0400
      Re: *&aptr , &*aptr question BartC <bc@freeuk.com> - 2016-06-14 22:57 +0100
        Re: *&aptr , &*aptr question jameskuyper@verizon.net - 2016-06-14 15:22 -0700
          Re: *&aptr , &*aptr question "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-14 18:40 -0400
          Re: *&aptr , &*aptr question BartC <bc@freeuk.com> - 2016-06-14 23:44 +0100
          Re: *&aptr , &*aptr question BartC <bc@freeuk.com> - 2016-06-14 23:54 +0100
            Re: *&aptr , &*aptr question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-15 00:14 +0100
            Re: *&aptr , &*aptr question Keith Thompson <kst-u@mib.org> - 2016-06-14 16:51 -0700
              Re: *&aptr , &*aptr question BartC <bc@freeuk.com> - 2016-06-15 01:15 +0100
                Re: *&aptr , &*aptr question Keith Thompson <kst-u@mib.org> - 2016-06-14 17:44 -0700
                Re: *&aptr , &*aptr question David Brown <david.brown@hesbynett.no> - 2016-06-15 09:12 +0200
                  Re: *&aptr , &*aptr question Richard Heathfield <rjh@cpax.org.uk> - 2016-06-15 08:28 +0100
                    Re: *&aptr , &*aptr question David Brown <david.brown@hesbynett.no> - 2016-06-15 10:26 +0200
                      Re: *&aptr , &*aptr question Richard Heathfield <rjh@cpax.org.uk> - 2016-06-15 09:48 +0100
                  Re: *&aptr , &*aptr question BartC <bc@freeuk.com> - 2016-06-15 11:05 +0100
                    Re: *&aptr , &*aptr question David Brown <david.brown@hesbynett.no> - 2016-06-15 12:22 +0200
                      Re: *&aptr , &*aptr question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-15 03:55 -0700
                        Re: *&aptr , &*aptr question David Brown <david.brown@hesbynett.no> - 2016-06-15 13:15 +0200
                          Re: *&aptr , &*aptr question BartC <bc@freeuk.com> - 2016-06-15 13:08 +0100
                            Re: *&aptr , &*aptr question David Brown <david.brown@hesbynett.no> - 2016-06-15 14:15 +0200
                              Re: *&aptr , &*aptr question BartC <bc@freeuk.com> - 2016-06-15 14:02 +0100
                              Re: *&aptr , &*aptr question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-15 13:38 -0700
                                Re: *&aptr , &*aptr question David Brown <david.brown@hesbynett.no> - 2016-06-16 00:01 +0200
                                  Re: *&aptr , &*aptr question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 00:58 -0700
                            Re: *&aptr , &*aptr question supercat@casperkitty.com - 2016-06-15 09:06 -0700
                              Re: *&aptr , &*aptr question BartC <bc@freeuk.com> - 2016-06-15 17:54 +0100
                            Re: *&aptr , &*aptr question raltbos@xs4all.nl (Richard Bos) - 2016-06-15 20:10 +0000
      Re: *&aptr , &*aptr question supercat@casperkitty.com - 2016-06-14 16:28 -0700
        Re: *&aptr , &*aptr question Keith Thompson <kst-u@mib.org> - 2016-06-14 16:54 -0700
          Re: *&aptr , &*aptr question supercat@casperkitty.com - 2016-06-14 19:13 -0700
            Re: *&aptr , &*aptr question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-15 13:19 +0100
              Re: *&aptr , &*aptr question Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-16 10:39 -0700
                Re: *&aptr , &*aptr question supercat@casperkitty.com - 2016-06-16 12:06 -0700
                  Re: *&aptr , &*aptr question Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-21 12:21 -0700
                Re: *&aptr , &*aptr question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-16 21:06 +0100
                  Re: *&aptr , &*aptr question supercat@casperkitty.com - 2016-06-16 14:35 -0700
                    Re: *&aptr , &*aptr question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-17 01:22 +0100
                  Re: *&aptr , &*aptr question Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-16 22:21 -0700
                    Re: *&aptr , &*aptr question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-18 00:55 +0100
                      Re: *&aptr , &*aptr question supercat@casperkitty.com - 2016-06-17 17:26 -0700
                      Re: *&aptr , &*aptr question Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-21 12:19 -0700
                        Re: *&aptr , &*aptr question supercat@casperkitty.com - 2016-06-21 13:09 -0700
    Re: *&aptr , &*aptr question Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-14 22:30 -0400
      Re: *&aptr , &*aptr question Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-15 14:20 -0700

Page 1 of 3  [1] 2 3  Next page →

#89092 — *&aptr , &*aptr question

refer to pointer:
   & and * operators are compliments of each other

below is a snip from C How to Program
...

int a;
int *aPtr;

a = 7;
aPtr = &a;

let's say the address is of a 0028FEC0

so the address is of a is 0028FEC0
     the value of aPtr is 0028FEC0

how does &*aPtr resolve?

*aPtr has the value of 7  or points to the a which has a value of 7

so, is & then applied to the 7. &7, and the address where 7 is located
returned. if that's the case, then where ever a pointer points and
then the value at that location is dereference the address is returned?

how does *&aPtr resolve?

&Ptr gives the address of Ptr   which let's say is 0028FFF0
so *0028FFF0 returns the value stored there, which is 0028FECO

am i thinking about this correctly?

thanks everyone,

g.

[toc] | [next] | [standalone]

#89094

On 14/06/16 21:43, G G wrote:

<snip>

> int a;
> int *aPtr;
>
> a = 7;
> aPtr = &a;
>
> let's say the address is of a 0028FEC0
>
> so the address is of a is 0028FEC0
>       the value of aPtr is 0028FEC0
>
> how does &*aPtr resolve?

aPtr is a pointer to a.
*aPtr is the value of the thing pointed to by aPtr, so it's the value of 
a, so it's 7.
&*aPtr is an error. You can't take the address of 7.

> how does *&aPtr resolve?

aPtr is a pointer to int.
&aPtr is a pointer to pointer to int, which points at aPtr.
*&aPtr is the value of the object pointed to by the pointer to pointer 
to int, i.e. the value of aPtr.

(That one's fine - no error.)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#89098

On 2016-06-14, Richard Heathfield <rjh@cpax.org.uk> wrote:
> On 14/06/16 21:43, G G wrote:
>
><snip>
>
>> int a;
>> int *aPtr;
>>
>> a = 7;
>> aPtr = &a;
>>
>> let's say the address is of a 0028FEC0
>>
>> so the address is of a is 0028FEC0
>>       the value of aPtr is 0028FEC0
>>
>> how does &*aPtr resolve?
>
> aPtr is a pointer to a.
> *aPtr is the value of the thing pointed to by aPtr, so it's the value of 
> a, so it's 7.
> &*aPtr is an error. You can't take the address of 7.

There's a special case for '&*':

6.5.3.2 Address and indirection operators

3 The unary & operator yields the address of its operand. If the
operand has type 'type', the result has type 'pointer to type'.
If the operand is the result of a unary * operator, neither that
operator nor the & operator is evaluated and the result is as if
both were omitted, except that the constraints on the operators
still apply and the result is not an lvalue. [...]

So &*aPtr does not take the address of 7, it just yields aPtr.

[toc] | [prev] | [next] | [standalone]

#89101

On Tuesday, June 14, 2016 at 5:20:51 PM UTC-4, Ike Naar wrote:


> 6.5.3.2 Address and indirection operators

> ...

> So &*aPtr does not take the address of 7, it just yields aPtr.

Thanks, ok, I see.

g.

[toc] | [prev] | [next] | [standalone]

#89104

On 14/06/16 22:01, Richard Heathfield wrote:
> On 14/06/16 21:43, G G wrote:

G G, I screwed this one up. Sorry. (I have a great excuse, with which I 
will not trouble you!)

I refer you to Keith's reply.

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#89179

On 6/14/2016 5:01 PM, Richard Heathfield wrote:
> On 14/06/16 21:43, G G wrote:
>
> <snip>
>
>> int a;
>> int *aPtr;
>>
>> a = 7;
>> aPtr = &a;
[...]
>> how does &*aPtr resolve?
>
> aPtr is a pointer to a.
> *aPtr is the value of the thing pointed to by aPtr, so it's the value of a,
> so it's 7.
> &*aPtr is an error. You can't take the address of 7.

It might be an MSVC extension, but "&*aPtr" returns the value of aPtr. 
(Which sort of makes sense, in that it's taking the address of what's 
pointed to -- in other words the original pointer.  It's not just a "7", but 
a specific "7" at a specific address to which "*aPtr" refers.)

Even with "/W4", there's not a peep.

But, as I said, it may be an MSVC extension.

[...]

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#89180

On 15/06/16 19:22, Ken Brody wrote:
> On 6/14/2016 5:01 PM, Richard Heathfield wrote:
>> On 14/06/16 21:43, G G wrote:
>>
>> <snip>
>>
>>> int a;
>>> int *aPtr;
>>>
>>> a = 7;
>>> aPtr = &a;
> [...]
>>> how does &*aPtr resolve?
>>
>> aPtr is a pointer to a.
>> *aPtr is the value of the thing pointed to by aPtr, so it's the value
>> of a,
>> so it's 7.
>> &*aPtr is an error. You can't take the address of 7.
>
> It might be an MSVC extension, but "&*aPtr" returns the value of aPtr.

And so it should. Do you ever think "I wish I hadn't posted that"? I do.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#89097

On 06/14/2016 04:43 PM, G G wrote:
> refer to pointer:
>    & and * operators are compliments of each other
> 
> below is a snip from C How to Program
> ...
> 
> int a;
> int *aPtr;
> 
> a = 7;
> aPtr = &a;
> 
> let's say the address is of a 0028FEC0
> 
> so the address is of a is 0028FEC0
>      the value of aPtr is 0028FEC0
> 
> how does &*aPtr resolve?
> 
> *aPtr has the value of 7  or points to the a which has a value of 7
> so, is & then applied to the 7. &7, and the address where 7 is located
> returned.

No. *aPtr is an lvalue referring to the int object in memory that
contains a representation of the value 7. The value of 7 is retrieved
from that object only if the lvalue is used in a context that requires
reading it. The operand of a unary & operator is NOT such a context.

"The operand of the unary & operator shall be either a function
designator, the result of a [] or unary * operator, or an lvalue that
designates an object that is not a bit-field and is not declared with
the register storage-class specifier." (6.5.3.2p1)

"The unary & operator yields the address of its operand.  If the operand
has type ‘‘type’’, the result has type ‘‘pointer to type’’. ..." (first
part of 6.5.3.2p3)

So &*ptr yields the address of the object that the lvalue *ptr refers to.

> how does *&aPtr resolve?

*& is, as a result of a special rule, a no-op:

"... If the operand is the result of a unary * operator, neither that
operator nor the & operator is evaluated and the result is as if both
were omitted, except that the constraints on the operators still apply
and the result is not an lvalue." (the rest of 6.5.3.2p3)

Therefore, *&Ptr has exactly the same meaning as Ptr itself, except that
it imposes certain constraints (6.5.3.2p1, cited earlier) on Ptr.

This special exception merely allows &* to be applied to expressions
where * itself would have undefined behavior, such as a null pointer or
a pointer one past the end of an array; in all other contexts, this rule
produces the same result that would have applied if it didn't exist:
*Ptr is an lvalue referring to the object at the address specified by
Ptr, and &*Ptr is the address of that that object, and must therefore
compare equal to Ptr itself.

[toc] | [prev] | [next] | [standalone]

#89100

G G <gdotone@gmail.com> writes:
> refer to pointer:
>    & and * operators are compliments of each other
>
> below is a snip from C How to Program
> ...
>
> int a;
> int *aPtr;
>
> a = 7;
> aPtr = &a;
>
> let's say the address is of a 0028FEC0

Ok.  Note that that's probably verbal shorthand for something like:

    The address of a, when converted to an appropriate integer type,
    is 0x0028FEC0.

Or, to put it another way:

    &a == (int*)0x0028FEC0

(I'm still making some assumptions about pointer/integer conversions,
assumptions that are probably only about 99% reliable.)

Addresses (pointer values) are not numbers.

(I'm being pedantic; I do know what you mean.)

> so the address is of a is 0028FEC0
>      the value of aPtr is 0028FEC0

Right.

> how does &*aPtr resolve?

`aPtr` is of type `int*`.  `*aPtr` refers to the object that `aPtr`
points to; that object is of type `int`.  `&*aPtr` yields the address of
that `int` object; that address is of type `int*`.

> *aPtr has the value of 7  or points to the a which has a value of 7

`*aPtr` isn't a pointer, so it doesn't point to anything.

The expression `*aPtr` is an *lvalue*.  The expression `a` is also an
lvalue.  An lvalue is an expression that can designate an object.

If you evaluate an lvalue in a context that doesn't require an lvalue,
the result is the value of the designated object.  If you evaluate an
lvalue in a context that *does* require an lvalue, the value of the
object is not used.  The operand of unary `&` is one such context.

> so, is & then applied to the 7. &7, and the address where 7 is located
> returned. if that's the case, then where ever a pointer points and
> then the value at that location is dereference the address is returned?

No, `&7` is not legal, because `7` is not an lvalue.  What's relevant to
the `&` operator is the *object* that its operand refers to.  The value
of that object (which happens to be 7 in this case) is ignored.

> how does *&aPtr resolve?

`aPtr` is an object of type `int*`.  `&aPtr` yields that object's
address, which is of type `int**`.  Applying `*` to that value gives you
the original object `aPtr`.  `*&aPtr` is an lvalue.

> &Ptr gives the address of Ptr   which let's say is 0028FFF0
> so *0028FFF0 returns the value stored there, which is 0028FECO
>
> am i thinking about this correctly?

Mostly.

There's one more special rule.  If you write `&*foo`, neither the `&`
nor the `*` is evaluated, and the expression is equivalent to just
`foo` (except that it's not an lvalue).  Similarly, `&foo[i]` is
equivalent to `foo + i` (since `arr[i]` in general is by definition
equivalent to `*(arr+i)`).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#89102

You may have seen an earlier version of this message. I got the
explanation messed up, and cancelled the message, but cancellation
requests are often ignored by any news server other than the one used by
the sender. I apologize for the noise and confusion.

On 06/14/2016 04:43 PM, G G wrote:
> refer to pointer:
> & and * operators are compliments of each other
>
> below is a snip from C How to Program
> ...
>
> int a;
> int *aPtr;
>
> a = 7;
> aPtr = &a;
>
> let's say the address is of a 0028FEC0
>
> so the address is of a is 0028FEC0
> the value of aPtr is 0028FEC0
>
> how does &*aPtr resolve?
>
> *aPtr has the value of 7 or points to the a which has a value of 7
> so, is & then applied to the 7. &7, and the address where 7 is located
> returned.

&* is, as a result of a special rule, a no-op:

"The unary & operator yields the address of its operand. ... .If the
operand is the result of a unary * operator, neither that operator nor
the & operator is evaluated and the result is as if both were omitted,
except that the constraints on the operators still apply and the result
is not an lvalue." (the rest of 6.5.3.2p3)

Therefore, *&Ptr has exactly the same meaning as Ptr itself, except that
it imposes certain constraints on Ptr:

"The operand of the unary & operator shall be either a function
designator, the result of a [] or unary * operator, or an lvalue that
designates an object that is not a bit-field and is not declared with
the register storage-class specifier." (6.5.3.2p1)

This special exception merely allows &* to be applied to expressions
where * itself would have undefined behavior, such as a null pointer or
a pointer one past the end of an array; in all other contexts, this rule
produces the same result that would have applied if it didn't exist:
*Ptr is an lvalue referring to the object at the address specified by
Ptr, and &*Ptr is the address of that that object, and must therefore
compare equal to Ptr itself.

> how does *&aPtr resolve?

I presume that's a typo for *&Ptr?
If so, &Ptr has a value that is the address of the Ptr object. Applying
the * operator to that address creates an lvalue referring to that
object. What that means depends upon how that lvalue is used. If used in
a expression that reads the value, such as *&Ptr + 5, then it will read
the value stored in Ptr, which is the address of 'a'. If used in a
expression that writes the value, such as *&Ptr = &b, it will set Ptr to
point at b. If used in the expression &*&Ptr, it will give the address
of Ptr again, so &*&Ptr == &Ptr.

[toc] | [prev] | [next] | [standalone]

#89106

On 06/14/2016 05:40 PM, James R. Kuyper wrote:
...
> On 06/14/2016 04:43 PM, G G wrote:
...
>> int *aPtr;
...

[A whole lot of text where I referred to Ptr when I should have been
referring to aPtr]

...
>> how does *&aPtr resolve?
> 
> I presume that's a typo for *&Ptr?

[More text based upon that same mistaken assumption]

I actually do know how to read - but this message was not good evidence
for that claim. :-{
I believe that everything I said about Ptr would actually be a correct
statement if Ptr is converted to aPtr.

[toc] | [prev] | [next] | [standalone]

#89107

On 14/06/2016 22:40, James R. Kuyper wrote:
> You may have seen an earlier version of this message. I got the
> explanation messed up, and cancelled the message, but cancellation
> requests are often ignored by any news server other than the one used by
> the sender. I apologize for the noise and confusion.
>
> On 06/14/2016 04:43 PM, G G wrote:
>> refer to pointer:
>> & and * operators are compliments of each other
>>
>> below is a snip from C How to Program
>> ...
>>
>> int a;
>> int *aPtr;
>>
>> a = 7;
>> aPtr = &a;
>>
>> let's say the address is of a 0028FEC0
>>
>> so the address is of a is 0028FEC0
>> the value of aPtr is 0028FEC0
>>
>> how does &*aPtr resolve?
>>
>> *aPtr has the value of 7 or points to the a which has a value of 7
>> so, is & then applied to the 7. &7, and the address where 7 is located
>> returned.
>
> &* is, as a result of a special rule, a no-op:
>
> "The unary & operator yields the address of its operand. ... .If the
> operand is the result of a unary * operator, neither that operator nor
> the & operator is evaluated and the result is as if both were omitted,
> except that the constraints on the operators still apply and the result
> is not an lvalue." (the rest of 6.5.3.2p3)
>
> Therefore, *&Ptr has exactly the same meaning as Ptr itself, except that
> it imposes certain constraints on Ptr:

If &Ptr is legal, then & &*Ptr or &*&Ptr give an error in gcc.

And &*7 and *&7 both give problems too.

It's not as simple as *& or &* just cancelling each other out.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#89111

On Tuesday, June 14, 2016 at 5:58:03 PM UTC-4, Bart wrote:
> On 14/06/2016 22:40, James R. Kuyper wrote:
...
> > &* is, as a result of a special rule, a no-op:
> >
> > "The unary & operator yields the address of its operand. ... .If the
> > operand is the result of a unary * operator, neither that operator nor
> > the & operator is evaluated and the result is as if both were omitted,
> > except that the constraints on the operators still apply and the result
> > is not an lvalue." (the rest of 6.5.3.2p3)
> >
> > Therefore, *&Ptr has exactly the same meaning as Ptr itself, except that
> > it imposes certain constraints on Ptr:
> 
> If &Ptr is legal, then & &*Ptr or &*&Ptr give an error in gcc.

I can confirm that gcc gives the message "error: lvalue required as
unary ‘&’ operand" for & &*Ptr. This seems to me to be clearly in conflict with the specification: "the result [of &*] is as if both were omitted". I'd consider this a defect in gcc.

I tried using &*&Ptr with gcc, and it produced no error messages. Could you
show us the code that you tried, and the error messages that it produced?

> And &*7 and *&7 both give problems too.

6.5.3.2p3, which I quoted and you requoted above, says "... except that the constraints on the operators still apply ...". In my message, I cited the wrong constraint - &*expression always inherently satisfies 6.5.3.2p1; the relevant constraint is 6.5.3.2p2:

"The operand of the unary * operator shall have pointer type."

&*7 violates that constraint

Unlike &*, there is no special rule for *&, so 6.5.3.2p1 unambiguously applies:
 
"The operand of the unary & operator shall be either a function designator, the result of a [] or unary * operator, or an lvalue that designates an object that is not a bit-field and is not declared with the register storage-class specifier."

*&7 violates that constraint.

[toc] | [prev] | [next] | [standalone]

#89114

On 06/14/2016 06:28 PM, Stefan Ram wrote:
> jameskuyper@verizon.net writes:
>> I can confirm that gcc gives the message "error: lvalue
>> required as unary & operand" for & &*Ptr. This
>> seems to me to be clearly in conflict with the specification:
>> "the result [of &*] is as if both were omitted". I'd consider
>> this a defect in gcc.
> 
>   »& &*Ptr« is not allowed because »the result is not an
>   lvalue« (6.5.3.1p3). »&*Ptr« is not an lvalue, but the
>   first »&« in »&*Ptr« requires an lvalue.

You're right. I'm really making a lot of reading mistakes today.
However, Bartc seems to be making even more than I am, which makes me
feel a little less foolish.

[toc] | [prev] | [next] | [standalone]

#89115

On 14/06/2016 23:22, jameskuyper@verizon.net wrote:
> On Tuesday, June 14, 2016 at 5:58:03 PM UTC-4, Bart wrote:
>> On 14/06/2016 22:40, James R. Kuyper wrote:
> ...
>>> &* is, as a result of a special rule, a no-op:
>>>
>>> "The unary & operator yields the address of its operand. ... .If the
>>> operand is the result of a unary * operator, neither that operator nor
>>> the & operator is evaluated and the result is as if both were omitted,
>>> except that the constraints on the operators still apply and the result
>>> is not an lvalue." (the rest of 6.5.3.2p3)
>>>
>>> Therefore, *&Ptr has exactly the same meaning as Ptr itself, except that
>>> it imposes certain constraints on Ptr:
>>
>> If &Ptr is legal, then & &*Ptr or &*&Ptr give an error in gcc.
>
> I can confirm that gcc gives the message "error: lvalue required as
> unary ‘&’ operand" for & &*Ptr. This seems to me to be clearly in conflict with the specification: "the result [of &*] is as if both were omitted". I'd consider this a defect in gcc.
>
> I tried using &*&Ptr with gcc, and it produced no error messages. Could you
> show us the code that you tried, and the error messages that it produced?

I can't get that second example to fail now either.

I think it would be simpler overall if & and *, or * and &, just 
cancelled each other no matter what the context. It's also possible to 
argue that & & and ** ought to do the same: the middle & and * cancel, 
leaving &* which cancel in turn.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#89116

On 14/06/2016 23:28, Stefan Ram wrote:
> jameskuyper@verizon.net writes:
>> I can confirm that gcc gives the message "error: lvalue
>> required as unary & operand" for & &*Ptr. This
>> seems to me to be clearly in conflict with the specification:
>> "the result [of &*] is as if both were omitted". I'd consider
>> this a defect in gcc.
>
>   »& &*Ptr« is not allowed because »the result is not an
>   lvalue« (6.5.3.1p3). »&*Ptr« is not an lvalue, but the
>   first »&« in »&*Ptr« requires an lvalue.
>

What's going on here then:

int* Ptr;

Ptr = Ptr;
Ptr = *Ptr;
Ptr = &Ptr;
Ptr = &*Ptr;
Ptr = *&Ptr;

Ptr = &*&Ptr;
Ptr = *&*Ptr;

Ptr = &*&*Ptr;
Ptr = *&*&Ptr;

These are all fine according to gcc (and TCC and clang; other compilers 
aren't quite so happy).

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#89118

BartC <bc@freeuk.com> writes:

> On 14/06/2016 23:28, Stefan Ram wrote:
>> jameskuyper@verizon.net writes:
>>> I can confirm that gcc gives the message "error: lvalue
>>> required as unary & operand" for & &*Ptr. This
>>> seems to me to be clearly in conflict with the specification:
>>> "the result [of &*] is as if both were omitted". I'd consider
>>> this a defect in gcc.
>>
>>   »& &*Ptr« is not allowed because »the result is not an
>>   lvalue« (6.5.3.1p3). »&*Ptr« is not an lvalue, but the
>>   first »&« in »&*Ptr« requires an lvalue.
>>
>
> What's going on here then:
>
> int* Ptr;
>
> Ptr = Ptr;
> Ptr = *Ptr;

That's a constraint violation (assigning an int to a pointer).

> Ptr = &Ptr;

Ditto (assigning a pointer of the wrong type).

> Ptr = &*Ptr;
> Ptr = *&Ptr;
>
> Ptr = &*&Ptr;

Ditto (assigning a pointer of the wrong type).

> Ptr = *&*Ptr;

Ditto (assigning an int to a pointer).

> Ptr = &*&*Ptr;
> Ptr = *&*&Ptr;

The others are OK (though not necessarily reasonable code).

> These are all fine according to gcc (and TCC and clang; other
> compilers aren't quite so happy).

For me, gcc gives a diagnostic (as it should) for all of those that are
constraint violations, even with no options.  But that's quite a modern
gcc.  You might need to ask gcc to compile actual C rather that it's
almost C-like default language.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#89121

BartC <bc@freeuk.com> writes:
[...]
> What's going on here then:
>
> int* Ptr;
>
> Ptr = Ptr;
> Ptr = *Ptr;
> Ptr = &Ptr;
> Ptr = &*Ptr;
> Ptr = *&Ptr;
>
> Ptr = &*&Ptr;
> Ptr = *&*Ptr;
>
> Ptr = &*&*Ptr;
> Ptr = *&*&Ptr;
>
> These are all fine according to gcc (and TCC and clang; other compilers 
> aren't quite so happy).

What do you mean by "fine"?  Did you not get warnings?

gcc is notorious for issuing non-fatal warnings by default for some
constraint violations.  Surely you've seen that mentioned here before.

I get:

c.c: In function ‘main’:
c.c:7:9: warning: assignment makes pointer from integer without a cast
[enabled by default]
     Ptr = *Ptr;
         ^
c.c:8:9: warning: assignment from incompatible pointer type [enabled by
default]
     Ptr = &Ptr;
         ^
c.c:12:9: warning: assignment from incompatible pointer type [enabled by
default]
     Ptr = &*&Ptr;
         ^
c.c:13:9: warning: assignment makes pointer from integer without a cast
[enabled by default]
     Ptr = *&*Ptr;
         ^

If you really didn't get any warnings, what version of gcc are you
using?

If you did, why the &*&* didn't you mention that fact?  (Use the
-pedantic-errors option if you want fatal errors for constraint
violations.)

(Of course the standard only requires a diagnostic message, so this
isn't a conformance violation.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#89124

On 15/06/2016 00:51, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
> [...]
>> What's going on here then:
>>
>> int* Ptr;
>>
>> Ptr = Ptr;
>> Ptr = *Ptr;  //w
>> Ptr = &Ptr;  //w
>> Ptr = &*Ptr;
>> Ptr = *&Ptr;
>>
>> Ptr = &*&Ptr; //w
>> Ptr = *&*Ptr;//w

>>
>> Ptr = &*&*Ptr;
>> Ptr = *&*&Ptr;
>>
>> These are all fine according to gcc (and TCC and clang; other compilers
>> aren't quite so happy).
>
> What do you mean by "fine"?  Did you not get warnings?

Yes, I did! But I keep forgetting that the way I use gcc hides all the 
warnings. So the lines I've marked //w above had warnings (from gcc, 
clang, tcc). Other compilers gave actual errors.

Sorry...

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#89125

BartC <bc@freeuk.com> writes:
> On 15/06/2016 00:51, Keith Thompson wrote:
[...]
>> What do you mean by "fine"?  Did you not get warnings?
>
> Yes, I did! But I keep forgetting that the way I use gcc hides all the 
> warnings.

That's a bad idea.

>           So the lines I've marked //w above had warnings (from gcc, 
> clang, tcc). Other compilers gave actual errors.

Let me suggest that hiding all warnings from gcc is a *really really*
bad idea.

Did I mention that it's a bad idea?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web