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

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

pointers

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

Contents

  pointers asetofsymbols@gmail.com - 2016-10-23 08:11 -0700
    Re: pointers Richard Heathfield <rjh@cpax.org.uk> - 2016-10-23 16:26 +0100
      Re: pointers asetofsymbols@gmail.com - 2016-10-23 10:35 -0700
        Re: pointers Ike Naar <ike@iceland.freeshell.org> - 2016-10-23 17:47 +0000
          Re: pointers asetofsymbols@gmail.com - 2016-10-25 12:55 -0700
        Re: pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-23 13:58 -0400
          Re: pointers BartC <bc@freeuk.com> - 2016-10-24 00:55 +0100
            Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-23 17:27 -0700
              Re: pointers BartC <bc@freeuk.com> - 2016-10-24 11:53 +0100
                Re: pointers supercat@casperkitty.com - 2016-10-24 07:29 -0700
                  Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 08:55 -0700
                  Re: pointers Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-24 14:02 -0700
                    Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 14:42 -0700
                      Re: pointers Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-25 08:56 -0700
                        Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-25 12:17 -0700
                          Re: pointers Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-26 06:37 -0700
                Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 08:49 -0700
                  Re: pointers BartC <bc@freeuk.com> - 2016-10-24 17:25 +0100
                    Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 09:52 -0700
                      Re: pointers BartC <bc@freeuk.com> - 2016-10-24 18:15 +0100
                        Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 12:20 -0700
                          Re: pointers BartC <bc@freeuk.com> - 2016-10-24 20:58 +0100
                            Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 13:16 -0700
                              Re: pointers BartC <bc@freeuk.com> - 2016-10-24 23:53 +0100
                                Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-25 13:38 -0700
                                  Re: pointers BartC <bc@freeuk.com> - 2016-10-25 23:06 +0100
                                    Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-25 15:39 -0700
                                      Re: pointers BartC <bc@freeuk.com> - 2016-10-26 00:26 +0100
                                        Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-25 16:44 -0700
                                          Re: pointers BartC <bc@freeuk.com> - 2016-10-26 01:02 +0100
                                            Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-25 17:35 -0700
                                    Re: pointers Ike Naar <ike@iceland.freeshell.org> - 2016-10-26 06:27 +0000
                                      Re: pointers BartC <bc@freeuk.com> - 2016-10-26 12:47 +0100
                                        Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-26 09:05 -0700
                                          Re: pointers BartC <bc@freeuk.com> - 2016-10-26 18:46 +0100
                                            Re: pointers supercat@casperkitty.com - 2016-10-26 11:44 -0700
                                              Re: pointers BartC <bc@freeuk.com> - 2016-10-26 20:12 +0100
                                                Re: pointers BartC <bc@freeuk.com> - 2016-10-26 20:30 +0100
                                                Re: pointers supercat@casperkitty.com - 2016-10-26 13:02 -0700
                                            Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-26 11:52 -0700
                                        Re: pointers Ike Naar <ike@iceland.freeshell.org> - 2016-10-26 19:11 +0000
                                          Re: pointers BartC <bc@freeuk.com> - 2016-10-26 21:25 +0100
                                Re: pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-25 18:56 -0400
                                  Re: pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-25 19:12 -0400
                                  Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-25 16:31 -0700
                        Re: pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-24 21:36 +0100
                          Re: pointers BartC <bc@freeuk.com> - 2016-10-25 16:54 +0100
                            Re: pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-25 19:09 +0100
                      Re: pointers supercat@casperkitty.com - 2016-10-24 11:33 -0700
                        Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 12:22 -0700
            Re: pointers James Kuyper <jameskuyper@verizon.net> - 2016-10-24 10:23 -0400
    Re: pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-23 12:31 -0400
      Re: pointers Richard Heathfield <rjh@cpax.org.uk> - 2016-10-23 17:38 +0100
    Re: pointers Lorinczy Zsigmond <zsiga@nospam.for.me> - 2016-10-24 14:02 +0200
    Re: pointers John Bode <jfbode1029@gmail.com> - 2016-10-24 13:34 -0700

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

#95168 — pointers

If i have
int buffer[10], *pointer;

Where point to &buffer? Where point &&pointer? Thanks

[toc] | [next] | [standalone]

#95173

On 23/10/16 16:11, asetofsymbols@gmail.com wrote:
> If i have
> int buffer[10], *pointer;
>
> Where point to &buffer? Where point &&pointer? Thanks

&buffer is a pointer to the array named 'buffer'. That is, it has the 
type "pointer to array of 10 int". This is rarely useful.

&&pointer parses as && (logical and) pointer. Since pointer (which is of 
type int *) doesn't point anywhere determinate, the evaluation of 
pointer would be undefined, so we'd better hope that it doesn't take 
place (which it might not, because the left operand of && might be true).

-- 
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]

#95187

I mean int *pointer, ***p;
p=&(&pointer);
What does it point p to?

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

#95189

On 2016-10-23, asetofsymbols@gmail.com <asetofsymbols@gmail.com> wrote:
> I mean int *pointer, ***p;
> p=&(&pointer);
> What does it point p to?

Sorry, it doesn't compile.

$ cat a.c
int main(void)
{
  int *pointer, ***p;
  p=&(&pointer);
  return 0;
}
$ cc a.c
a.c: In function 'main':
a.c:4:5: error: lvalue required as unary '&' operand
   p=&(&pointer);

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

#95309

Ike Naar wrote:
"Sorry, it doesn't compile. 

$ cat a.c 
int main(void) 
{ 
  int *pointer, ***p; 
  p=&(&pointer); 
  return 0; 
} 
$ cc a.c 
a.c: In function 'main': 
a.c:4:5: error: lvalue required as unary '&' operand 
   p=&(&pointer);"
_____~_______________
Ok is not one lvalue is not one place
in memory...

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

#95191

On 10/23/2016 01:35 PM, asetofsymbols@gmail.com wrote:
> I mean int *pointer, ***p;
> p=&(&pointer);
> What does it point p to?

The parentheses are redundant, it's equivalent to & &pointer, which, as 
I've already said, is a constraint violation. Since &pointer is not an 
lvalue, it does not designate an object, violating 6.5.3.2p1.

Let me expand on that explanation. &pointer is a pointer value which 
points at the pointer object named 'pointer'. This value does not have a 
corresponding C object that it need be stored in. That's why it's not an 
lvalue. In practice, it may reside in a register on a machine where 
registers are not addressable (systems where registers ARE addressable 
is something I've heard of, but I know nothing about them).

An implementation might allow & &pointer as an extension - but as a 
constraint violation, it must still issue a diagnostic. Since it would 
be an extension, & &pointer could, in principle, have any behavior at 
all, including doing the equivalent of puts("You don't understand C."). 
However, in practice, an implementation that allows it would probably 
give it a value that points at a piece of memory set aside to store the 
value of &pointer. You'll have to check with that implementation's 
documentation to determine the lifetime of any such object. As far as C 
is concerned, the object doesn't even exist, so the C standard says 
nothing to resolve that issue.

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

#95217

On 23/10/2016 18:58, James R. Kuyper wrote:
> On 10/23/2016 01:35 PM, asetofsymbols@gmail.com wrote:
>> I mean int *pointer, ***p;
>> p=&(&pointer);
>> What does it point p to?
>
> The parentheses are redundant, it's equivalent to & &pointer, which, as
> I've already said, is a constraint violation. Since &pointer is not an
> lvalue, it does not designate an object, violating 6.5.3.2p1.
>
> Let me expand on that explanation. &pointer is a pointer value which
> points at the pointer object named 'pointer'. This value does not have a
> corresponding C object that it need be stored in. That's why it's not an
> lvalue. In practice, it may reside in a register on a machine where
> registers are not addressable (systems where registers ARE addressable
> is something I've heard of, but I know nothing about them).
>
> An implementation might allow & &pointer as an extension - but as a
> constraint violation, it must still issue a diagnostic. Since it would
> be an extension, & &pointer could, in principle, have any behavior at
> all, including doing the equivalent of puts("You don't understand C.").
> However, in practice, an implementation that allows it would probably
> give it a value that points at a piece of memory set aside to store the
> value of &pointer. You'll have to check with that implementation's
> documentation to determine the lifetime of any such object. As far as C
> is concerned, the object doesn't even exist, so the C standard says
> nothing to resolve that issue.

Why not just say that & &pointer is illegal?

It is as meaningful as &25 (and I doubt many implementations will set up 
a storage location containing 25 and return a pointer to that).

& & is sometimes allowed like this:

  int **pointer;

  & & &**pointer;

where the & & and ** cancel out. But gcc doesn't like it so it wouldn't 
be wise to depend on it. For gcc, it needs to be written like this:

  &*&*&pointer;

with the & and * interleaved.


-- 
Bartc

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

#95218

BartC <bc@freeuk.com> writes:
> On 23/10/2016 18:58, James R. Kuyper wrote:
>> On 10/23/2016 01:35 PM, asetofsymbols@gmail.com wrote:
>>> I mean int *pointer, ***p;
>>> p=&(&pointer);
>>> What does it point p to?
>>
>> The parentheses are redundant, it's equivalent to & &pointer, which, as
>> I've already said, is a constraint violation. Since &pointer is not an
>> lvalue, it does not designate an object, violating 6.5.3.2p1.
>>
>> Let me expand on that explanation. &pointer is a pointer value which
>> points at the pointer object named 'pointer'. This value does not have a
>> corresponding C object that it need be stored in. That's why it's not an
>> lvalue.
[snip]
> Why not just say that & &pointer is illegal?

He did say that.  Actually he said something more accurate, that it's a
constraint violation.  He also went on to explain why.  I don't know why
you'd object to that.

> It is as meaningful as &25 (and I doubt many implementations will set up 
> a storage location containing 25 and return a pointer to that).
>
> & & is sometimes allowed like this:
>
>   int **pointer;
>
>   & & &**pointer;
>
> where the & & and ** cancel out. But gcc doesn't like it so it wouldn't 
> be wise to depend on it.

No, that's not allowed (more precisely, it's still a constraint
violation).  N1570 6.5.3.2 says that &*foo is equivalent to foo
"except that the constraints on the operators still apply and the
result is not an lvalue".

>                          For gcc, it needs to be written like this:
>
>   &*&*&pointer;
>
> with the & and * interleaved.

Because that's a different expression, which is not a constraint
violation.  The same applies to any conforming compiler.

-- 
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]

#95221

On 24/10/2016 01:27, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:

>> & & is sometimes allowed like this:
>>
>>   int **pointer;
>>
>>   & & &**pointer;
>>
>> where the & & and ** cancel out. But gcc doesn't like it so it wouldn't
>> be wise to depend on it.
>
> No, that's not allowed (more precisely, it's still a constraint
> violation).  N1570 6.5.3.2 says that &*foo is equivalent to foo
> "except that the constraints on the operators still apply and the
> result is not an lvalue".
>
>>                          For gcc, it needs to be written like this:
>>
>>   &*&*&pointer;
>>
>> with the & and * interleaved.
>
> Because that's a different expression, which is not a constraint
> violation.  The same applies to any conforming compiler.

The behaviour of the non-conforming compilers seems fine to be. Each & 
and * pair cancel each other out, as seems to happen with the conforming 
gcc.

Should it matter then in which order the & and * appear? By the time you 
get to the actual term, you've either got more & than *, or more * than 
&, or they cancel each other out completely.

(Odd that it's the conforming gcc that allows && (without the space) as 
address-of on labels. It seems to pick and choose what it wants to 
conform to! But it does show that && (binary and) and && (unary 
address-of-label) can co-exist.)

-- 
Bartc

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

#95224

On Monday, October 24, 2016 at 5:53:28 AM UTC-5, Bart wrote:
> (Odd that it's the conforming gcc that allows && (without the space) as 
> address-of on labels. It seems to pick and choose what it wants to 
> conform to! But it does show that && (binary and) and && (unary 
> address-of-label) can co-exist.)

The C Standard is unclear whether documented extensions can exempt what
would otherwise be ill-formed programs from the requirement for a
diagnostic.  It doesn't explicitly specify that, but since it doesn't
give any other definition for what would constitute an "extension"
requiring documentation.  If the Standard would allow a particular
source text to treated in arbitrary fashion, the fact that a particular
implementation happens to treat it consistently would not be an "extension"
requiring documentation.  The Standard does that no conforming extension
should alter the effect of a strictly-conforming program, but many of the
"Common Extensions" listed in the annex would do precisely that.  Such
issues could be resolved by having compilers include non-conforming modes,
but it seems elsewhere that the authors of the Standard were trying to
avoid requiring such things.  Otherwise, they could have required that
conforming compilers must be capable of supporting certain commonplace
behaviors which could be emulated on any platform, while allowing such
compilers to offer modes which behave differently (and possibly faster).

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

#95230

supercat@casperkitty.com writes:
> On Monday, October 24, 2016 at 5:53:28 AM UTC-5, Bart wrote:
>> (Odd that it's the conforming gcc that allows && (without the space) as 
>> address-of on labels. It seems to pick and choose what it wants to 
>> conform to! But it does show that && (binary and) and && (unary 
>> address-of-label) can co-exist.)
>
> The C Standard is unclear whether documented extensions can exempt what
> would otherwise be ill-formed programs from the requirement for a
> diagnostic.  It doesn't explicitly specify that, but since it doesn't
> give any other definition for what would constitute an "extension"
> requiring documentation.
[...]

How is it unclear?  The standard requires a diagnostic for any violation
of a syntax rule or constraint.  There's no stated exception to that
requirement for extensions.

gcc's behavior is consistent with this.  For example, gcc has a unary &&
operator that takes a label operand and yields a void* result.  When gcc
is invoked with `-pedantic`, it diagnoses any use of that extension.

-- 
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]

#95247

supercat@casperkitty.com writes:

> The Standard does [say] that no conforming extension should alter
> the effect of a strictly-conforming program, but many of the
> "Common Extensions" listed in the annex would do precisely that.

That depends on how the extension is implemented, doesn't it?  Or
are you saying that some of the listed common extensions would be
impossible to implement without changing some strictly conforming
programs?  If so, which of the listed extensions fall into that
category?

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

#95249

Tim Rentsch <txr@alumni.caltech.edu> writes:
> supercat@casperkitty.com writes:
>> The Standard does [say] that no conforming extension should alter
>> the effect of a strictly-conforming program, but many of the
>> "Common Extensions" listed in the annex would do precisely that.
>
> That depends on how the extension is implemented, doesn't it?  Or
> are you saying that some of the listed common extensions would be
> impossible to implement without changing some strictly conforming
> programs?  If so, which of the listed extensions fall into that
> category?

The "fortran" and "asm" keywords, if they're treated as keywords in
all contexts, would clearly break strictly conforming programs that
use them as identifiers (J.5.9, J.5.10).  Likewise for predefined
macro names using unreserved identifers (J.5.12).

-- 
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]

#95294

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> supercat@casperkitty.com writes:
>>> The Standard does [say] that no conforming extension should alter
>>> the effect of a strictly-conforming program, but many of the
>>> "Common Extensions" listed in the annex would do precisely that.
>>
>> That depends on how the extension is implemented, doesn't it?  Or
>> are you saying that some of the listed common extensions would be
>> impossible to implement without changing some strictly conforming
>> programs?  If so, which of the listed extensions fall into that
>> category?
>
> The "fortran" and "asm" keywords, if they're treated as keywords in
> all contexts, would clearly break strictly conforming programs that
> use them as identifiers (J.5.9, J.5.10).

Sure.  If treated as keywords in the same way that regular C
keywords are treated, then yes.  If instead they were treated as
some form of optional, context-dependent keywords, then they
wouldn't necessarily intrude on the strictly-conformingness
property - right?

> Likewise for predefined
> macro names using unreserved identifers (J.5.12).

In this case too I believe it is possible to implement some form
of "weak" macro definitions that would not intrude on the
strictly-conformingness property.  I admit that it's harder to do
that with macros than the previous case.  But there is another
point worth mentioning here:  the offending macro definitions may
be in force only when the compilation is already in some sort of
non-conforming mode.  In gcc, for example, there are predefined
macros such as 'unix', but these predefined macros go away when
an option like -std=c99 or -ansi is used.  So the objection is
very likely not strictly correct, but even in cases where it
applies it seems to be vastly overblown.

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

#95308

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> supercat@casperkitty.com writes:
>>>> The Standard does [say] that no conforming extension should alter
>>>> the effect of a strictly-conforming program, but many of the
>>>> "Common Extensions" listed in the annex would do precisely that.
>>>
>>> That depends on how the extension is implemented, doesn't it?  Or
>>> are you saying that some of the listed common extensions would be
>>> impossible to implement without changing some strictly conforming
>>> programs?  If so, which of the listed extensions fall into that
>>> category?
>>
>> The "fortran" and "asm" keywords, if they're treated as keywords in
>> all contexts, would clearly break strictly conforming programs that
>> use them as identifiers (J.5.9, J.5.10).
>
> Sure.  If treated as keywords in the same way that regular C
> keywords are treated, then yes.  If instead they were treated as
> some form of optional, context-dependent keywords, then they
> wouldn't necessarily intrude on the strictly-conformingness
> property - right?

Of course, but that's not what I was referring to -- which is why I
wrote "*if* they're treated as keywords in all contexts".

My point is that J.5 lists "common extensions"; it does not limit itself
to *conforming* extensions.  And non-conforming extensions are in fact
common.  For example, gcc with default options (which is known to be
non-conforming) reports a syntax error on `int asm;`.

That's clearly the kind of thing J.5p1 is talking about, extensions that
"render an implementation nonconforming".

>> Likewise for predefined
>> macro names using unreserved identifers (J.5.12).
>
> In this case too I believe it is possible to implement some form
> of "weak" macro definitions that would not intrude on the
> strictly-conformingness property.  I admit that it's harder to do
> that with macros than the previous case.  But there is another
> point worth mentioning here:  the offending macro definitions may
> be in force only when the compilation is already in some sort of
> non-conforming mode.  In gcc, for example, there are predefined
> macros such as 'unix', but these predefined macros go away when
> an option like -std=c99 or -ansi is used.  So the objection is
> very likely not strictly correct, but even in cases where it
> applies it seems to be vastly overblown.

Annex J is not normative anyway, and J.5 in particular veers into
discussing non-conforming implementations (which, to be overly pedantic,
aren't really C implementations at all).  I'm not sure what's being
"vastly oveblown", or who is overblowing it.

-- 
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]

#95326

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> supercat@casperkitty.com writes:
>>>>> The Standard does [say] that no conforming extension should alter
>>>>> the effect of a strictly-conforming program, but many of the
>>>>> "Common Extensions" listed in the annex would do precisely that.
>>>>
>>>> That depends on how the extension is implemented, doesn't it?  Or
>>>> are you saying that some of the listed common extensions would be
>>>> impossible to implement without changing some strictly conforming
>>>> programs?  If so, which of the listed extensions fall into that
>>>> category?
>>>
>>> The "fortran" and "asm" keywords, if they're treated as keywords in
>>> all contexts, would clearly break strictly conforming programs that
>>> use them as identifiers (J.5.9, J.5.10).
>>
>> Sure.  If treated as keywords in the same way that regular C
>> keywords are treated, then yes.  If instead they were treated as
>> some form of optional, context-dependent keywords, then they
>> wouldn't necessarily intrude on the strictly-conformingness
>> property - right?
>
> Of course, but that's not what I was referring to -- which is why I
> wrote "*if* they're treated as keywords in all contexts".
>
> My point is that J.5 lists "common extensions";  it does not limit itself
> to *conforming* extensions.  And non-conforming extensions are in fact
> common.  For example, gcc with default options (which is known to be
> non-conforming) reports a syntax error on `int asm;`.
>
> That's clearly the kind of thing J.5p1 is talking about, extensions that
> "render an implementation nonconforming".
>
>>> Likewise for predefined
>>> macro names using unreserved identifers (J.5.12).
>>
>> In this case too I believe it is possible to implement some form
>> of "weak" macro definitions that would not intrude on the
>> strictly-conformingness property.  I admit that it's harder to do
>> that with macros than the previous case.  But there is another
>> point worth mentioning here:  the offending macro definitions may
>> be in force only when the compilation is already in some sort of
>> non-conforming mode.  In gcc, for example, there are predefined
>> macros such as 'unix', but these predefined macros go away when
>> an option like -std=c99 or -ansi is used.  So the objection is
>> very likely not strictly correct, but even in cases where it
>> applies it seems to be vastly overblown.
>
> Annex J is not normative anyway, and J.5 in particular veers into
> discussing non-conforming implementations (which, to be overly pedantic,
> aren't really C implementations at all).  I'm not sure what's being
> "vastly oveblown", or who is overblowing it.

My point, which seems to have gotten lost in translation, is
that extensions like those described in J.5 may result in
a non-conforming implementation (or variant), but need not
do so necessarily.  Not that they will, but that they might -
or also might not, depending on how they are implemented.

My comment about an objection was not a reaction to anything
you said and I'm sorry if it came across otherwise.

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

#95229

BartC <bc@freeuk.com> writes:
> On 24/10/2016 01:27, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> & & is sometimes allowed like this:
>>>
>>>   int **pointer;
>>>
>>>   & & &**pointer;
>>>
>>> where the & & and ** cancel out. But gcc doesn't like it so it wouldn't
>>> be wise to depend on it.
>>
>> No, that's not allowed (more precisely, it's still a constraint
>> violation).  N1570 6.5.3.2 says that &*foo is equivalent to foo
>> "except that the constraints on the operators still apply and the
>> result is not an lvalue".
>>
>>>                          For gcc, it needs to be written like this:
>>>
>>>   &*&*&pointer;
>>>
>>> with the & and * interleaved.
>>
>> Because that's a different expression, which is not a constraint
>> violation.  The same applies to any conforming compiler.
>
> The behaviour of the non-conforming compilers seems fine to be. Each & 
> and * pair cancel each other out, as seems to happen with the conforming 
> gcc.

What compiler doesn't diagnose `& & &**pointer`?

The standard clearly makes `& &pointer` a constraint violation.
Part of a compiler's job is to diagnose errors.  A compiler that
fails to diagnose this particular error is not doing its job.
One result of this failure would be that a programmer might use
such a construct and not find out that it's invalid until the code
is ported to a conforming compiler.

> Should it matter then in which order the & and * appear? By the time you 
> get to the actual term, you've either got more & than *, or more * than 
> &, or they cancel each other out completely.

The fact is that it *does* matter.  The standard says that & and *
cancel out in certain narrowly defined circumstances.  I see no
advantage in allowing them to cancel out in any cases beyond those
defined by the standard.

Is there some reason you'd want to write `& & &**pointer`, or that you
care how the compiler handles it?

> (Odd that it's the conforming gcc that allows && (without the space) as 
> address-of on labels. It seems to pick and choose what it wants to 
> conform to! But it does show that && (binary and) and && (unary 
> address-of-label) can co-exist.)

I see nothing odd about it.  gcc's unary `&&` operator is an extension.
In standard C, `&&label` is a syntax error, and any conforming compiler
(including `gcc -std=c11 -pedantic`) must diagnose it.  Of course gcc is
not a fully conforming compiler by default.

-- 
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]

#95231

On 24/10/2016 16:49, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:

>> The behaviour of the non-conforming compilers seems fine to be. Each &
>> and * pair cancel each other out, as seems to happen with the conforming
>> gcc.

> What compiler doesn't diagnose `& & &**pointer`?

Pelles C and lccwin.

And MSVC-2008.

>> Should it matter then in which order the & and * appear? By the time you
>> get to the actual term, you've either got more & than *, or more * than
>> &, or they cancel each other out completely.
>
> The fact is that it *does* matter.  The standard says that & and *
> cancel out in certain narrowly defined circumstances.  I see no
> advantage in allowing them to cancel out in any cases beyond those
> defined by the standard.

Think of it the other way around: if one & pairs with one *, and the two 
then cancel out, should it matter if it's &* or *&, or &*&* instead of &&**?

Presumably gcc works from the bottom up: &&**pointer must be processed 
as strictly &(&(*(*pointer))), where each bracketed term starting from 
the innermost must be a legal expression type-wise, before applying the 
next operator.

This means that:

   int a;  &*a;

won't work, as *a is not legal. (But *&a is OK, as &a is valid.) However 
those non-conforming compilers don't like this either, so they are not 
just balancing & and * operators before applying any result (any surplus 
of & or *) to the term.

 > Is there some reason you'd want to write `& & &**pointer`, or that you
 > care how the compiler handles it?

If & and * just mean opposite things (* adds a dereference, & removes 
one), then making them cancel each other makes sense. The net number of 
deferences must still be meaningful (too many * or & is still an error).

And yes I can see this being used, even if it's just to illustrate an 
example like this (you'll need to imagine the spaces between &s):

  int **pointer;

      **pointer;     // 3 net derefs (one is always implicit with
                     // variables in HLLs); result: int
     &**pointer;     // 2 net derefs; int*   ( *pointer)
    &&**pointer;     // 1 net deref;  int**  (  pointer)
   &&&**pointer;     // 0 net derefs; int*** ( &pointer)
  &&&&**pointer;     // -1 net derefs: error (&&pointer)

(You'll notice many of my posts strive to add orthogonality to C, but it 
seems the language just won't have it!)

-- 
Bartc

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

#95234

BartC <bc@freeuk.com> writes:
> On 24/10/2016 16:49, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> The behaviour of the non-conforming compilers seems fine to be. Each &
>>> and * pair cancel each other out, as seems to happen with the conforming
>>> gcc.
>
>> What compiler doesn't diagnose `& & &**pointer`?
>
> Pelles C and lccwin.
>
> And MSVC-2008.

So those compilers have a bug.  It happens.

[...]

> And yes I can see this being used, even if it's just to illustrate an 
> example like this (you'll need to imagine the spaces between &s):
>
>   int **pointer;
>
>       **pointer;     // 3 net derefs (one is always implicit with
>                      // variables in HLLs); result: int
>      &**pointer;     // 2 net derefs; int*   ( *pointer)
>     &&**pointer;     // 1 net deref;  int**  (  pointer)
>    &&&**pointer;     // 0 net derefs; int*** ( &pointer)
>   &&&&**pointer;     // -1 net derefs: error (&&pointer)

So the only reason you can think of to use those constructs is to
illustrate them?  That's hardly a good reason to add them to the
language.

The unary & operator yields the address of its operand.  The resulting
expression is not an lvalue, so another unary & cannot be applied to it.
The special case rule in 6.5.3.2p3 doesn't change that (nor, IMHO,
should it).

Incidentally, that rule was added in C99.  It's not mentioned in the C99
Rationale, and I'm not sure why it was added.

> (You'll notice many of my posts strive to add orthogonality to C, but it 
> seems the language just won't have it!)

Orthogonality is nice, but I see no point in adding *gratuitious*
orthogonality that doesn't add any expressive power.

-- 
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]

#95236

On 24/10/2016 17:52, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:

>> And yes I can see this being used, even if it's just to illustrate an
>> example like this (you'll need to imagine the spaces between &s):
>>
>>   int **pointer;
>>
>>       **pointer;     // 3 net derefs (one is always implicit with
>>                      // variables in HLLs); result: int
>>      &**pointer;     // 2 net derefs; int*   ( *pointer)
>>     &&**pointer;     // 1 net deref;  int**  (  pointer)
>>    &&&**pointer;     // 0 net derefs; int*** ( &pointer)
>>   &&&&**pointer;     // -1 net derefs: error (&&pointer)
>
> So the only reason you can think of to use those constructs is to
> illustrate them?  That's hardly a good reason to add them to the
> language.
>
> The unary & operator yields the address of its operand.

What does that mean? And how does it work with &**pointer?

Because **pointer would do a double dereference to get to the operand. 
Are you saying now that the & operator effectively cancels that second 
dereference?

If so, then & is behaving just as I suggested: removing a dereference, 
while * adds one. (Rather than only giving the address of a named 
operand with no intervening * ops.)

Then there is no reason why & & can't remove both dereferences.

   The resulting
> expression is not an lvalue, so another unary & cannot be applied to it.

Why is **pointer an lvalue but not *pointer?

**pointer is an an rvalue that can have & in front to yield the 
equivalent of *pointer.

*pointer is an rvalue that can have & in front to yield the equivalent 
of pointer.

But you can't have **pointer as an rvalue that can have & & in front to 
yield the equivalent of pointer? That is, with the first & yielding 
*pointer, and the second 'pointer'.

-- 
Bartc

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

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

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

csiph-web