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

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

pass by address

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

Contents

  pass by address "Bill Cunningham" <nosapm@nspam.invalid> - 2014-05-02 16:53 -0400
    Re: pass by address "Bill Cunningham" <nosapm@nspam.invalid> - 2014-05-02 17:03 -0400
      Re: pass by address "Bill Cunningham" <nosapm@nspam.invalid> - 2014-05-02 17:20 -0400
    Re: pass by address Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-05-02 17:58 -0400
      Re: pass by address "Bill Cunningham" <nosapm@nspam.invalid> - 2014-05-02 18:09 -0400
        Re: pass by address Barry Schwarz <schwarzb@dqel.com> - 2014-05-02 16:37 -0700
          Re: pass by address gazelle@shell.xmission.com (Kenny McCormack) - 2014-05-02 23:43 +0000
            Re: pass by address Richard <rgrdev_@gmail.com> - 2014-05-03 15:58 +0200
              Re: pass by address gazelle@shell.xmission.com (Kenny McCormack) - 2014-05-03 14:08 +0000
                Re: pass by address Barry Schwarz <schwarzb@dqel.com> - 2014-05-03 10:38 -0700
                  Re: pass by address Richard <rgrdev_@gmail.com> - 2014-05-03 21:13 +0200
          Re: pass by address "Bill Cunningham" <nosapm@nspam.invalid> - 2014-05-03 01:46 -0400
          Re: pass by address "Bill Cunningaham" <nospam@nspam.invalid> - 2014-05-03 11:22 -0400
            Re: pass by address James Kuyper <jameskuyper@verizon.net> - 2014-05-03 12:13 -0400
            Re: pass by address Keith Thompson <kst-u@mib.org> - 2014-05-03 12:34 -0700
              Re: pass by address Richard <rgrdev_@gmail.com> - 2014-05-03 22:33 +0200
              Re: pass by address glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-05-03 21:21 +0000
                Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-04 00:08 -0400
                  Re: pass by address Barry Schwarz <schwarzb@dqel.com> - 2014-05-03 21:52 -0700
                    Re: pass by address Tonton Th <tth@nowhere.invalid> - 2014-05-04 08:44 +0000
                      Re: pass by address Keith Thompson <kst-u@mib.org> - 2014-05-04 01:51 -0700
                        Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-04 15:06 -0400
                          Re: pass by address Barry Schwarz <schwarzb@dqel.com> - 2014-05-04 15:35 -0700
                            Re: pass by address Richard <rgrdev_@gmail.com> - 2014-05-05 12:01 +0200
                              Re: pass by address Barry Schwarz <schwarzb@dqel.com> - 2014-05-05 11:46 -0700
                            Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-05 14:18 -0400
                              Re: pass by address Barry Schwarz <schwarzb@dqel.com> - 2014-05-05 11:55 -0700
                                Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-05 15:20 -0400
                                  Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-05 15:23 -0400
                                    Re: pass by address Ken Brody <kenbrody@spamcop.net> - 2014-05-06 11:02 -0400
                                      Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-06 14:46 -0400
                          Re: pass by address Richard <rgrdev_@gmail.com> - 2014-05-05 12:00 +0200
                          Re: pass by address Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-05-05 14:50 -0700
                            Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-05 23:13 -0400
                              Re: pass by address "Osmium" <r124c4u102@comcast.net> - 2014-05-05 23:09 -0500
                                Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-06 08:55 -0400
                              Re: pass by address Ken Brody <kenbrody@spamcop.net> - 2014-05-06 11:16 -0400
                                Re: pass by address Richard <rgrdev_@gmail.com> - 2014-05-06 18:13 +0200
                        Re: pass by address Kaz Kylheku <kaz@kylheku.com> - 2014-05-04 21:06 +0000
                          Re: pass by address Kaz Kylheku <kaz@kylheku.com> - 2014-05-04 23:50 +0000
                    Re: pass by address Keith Thompson <kst-u@mib.org> - 2014-05-04 12:36 -0700
                    Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-05 14:21 -0400
                  Re: pass by address Keith Thompson <kst-u@mib.org> - 2014-05-04 01:29 -0700
                    Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-04 15:09 -0400
          Re: pass by address "Bill Cunningaham" <nospam@nspam.invalid> - 2014-05-03 11:32 -0400
    Re: pass by address Barry Schwarz <schwarzb@dqel.com> - 2014-05-02 16:43 -0700
      Re: pass by address "Bill Cunningham" <nosapm@nspam.invalid> - 2014-05-03 01:54 -0400
        Re: pass by address Richard <rgrdev_@gmail.com> - 2014-05-03 15:59 +0200
      Re: pass by address "Bill Cunningham" <nosapm@nspam.invalid> - 2014-05-03 02:08 -0400
        Re: pass by address "Bill Cunningaham" <nospam@nspam.invalid> - 2014-05-03 11:46 -0400
      Re: pass by address Kaz Kylheku <kaz@kylheku.com> - 2014-05-03 21:43 +0000

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

#43936 — pass by address

    Now there is something new I've never heard of til now from reading a C 
book called "pass by address". Now am I understanding it right. I will use 
this example.

I think scanf might be like this. The second parameter by wanting a pointer 
is usually passed the address of the pointee using the ampersand (In know 
there's an elipsis there). But a value is decalred and initialized. Their is 
no pointer addresss involved. Is that "pass by address"?

    int a=15;
    scanf("%d\n",&n);

See no pointer address. But a pointee address is passed. The /value/ is 15.

Hope I'm clear.

[toc] | [next] | [standalone]

#43941

"Bill Cunningham" <nosapm@nspam.invalid> wrote in message 
news:lk10j7$uhr$1@dont-email.me...
>    Now there is something new I've never heard of til now from reading a C 
> book called "pass by address". Now am I understanding it right. I will use 
> this example.
>
> I think scanf might be like this. The second parameter by wanting a 
> pointer is usually passed the address of the pointee using the ampersand 
> (In know there's an elipsis there). But a value is decalred and 
> initialized. Their is no pointer addresss involved. Is that "pass by 
> address"?
>
>    int a=15;
>    scanf("%d\n",&n);
>
> See no pointer address. But a pointee address is passed. The /value/ is 
> 15.
>
> Hope I'm clear.

    Sorry my mistake. That should've been

scanf("%d\n",&a);

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

#43945

"Bill Cunningham" <nosapm@nspam.invalid> wrote in message 
news:lk117o$3k0$1@dont-email.me...
>
> "Bill Cunningham" <nosapm@nspam.invalid> wrote in message 
> news:lk10j7$uhr$1@dont-email.me...
>>    Now there is something new I've never heard of til now from reading a 
>> C book called "pass by address". Now am I understanding it right. I will 
>> use this example.
>>
>> I think scanf might be like this. The second parameter by wanting a 
>> pointer is usually passed the address of the pointee using the ampersand 
>> (In know there's an elipsis there). But a value is decalred and 
>> initialized. Their is no pointer addresss involved. Is that "pass by 
>> address"?
>>
>>    int a=15;
>>    scanf("%d\n",&n);
>>
>> See no pointer address. But a pointee address is passed. The /value/ is 
>> 15.
>>
>> Hope I'm clear.
>
>    Sorry my mistake. That should've been
>
> scanf("%d\n",&a);

    No value passed. No pointer address passed. If a value were passed 
evidently a dereference would be needed. The value is obtained from the 
passed "address" or a pointee that's not done here by the user anyway.

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

#43947

On Friday 02 May 2014 16:53, in comp.lang.c, "Bill Cunningham"
<nosapm@nspam.invalid> wrote:

>     Now there is something new I've never heard of til now from reading a
>     C
> book called "pass by address". Now am I understanding it right. I will use
> this example.
> 
> I think scanf might be like this. The second parameter by wanting a
> pointer is usually passed the address of the pointee using the ampersand
> (In know there's an elipsis there). But a value is decalred and
> initialized. Their is no pointer addresss involved. Is that "pass by
> address"?
> 
>     int a=15;
>     scanf("%d\n",&n);
> 
> See no pointer address. But a pointee address is passed. The /value/ is
> 15.

Bill, think about this one a bit....

  int a = 15;
  int *p;

  p = &a;

  printf("%d\n",*p);
  scanf("%d\n",p);


-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#43948

"Lew Pitcher" <lew.pitcher@digitalfreehold.ca> wrote in message 
news:NxU8v.443052$1p2.55006@fx13.iad...

> Bill, think about this one a bit....
>
>  int a = 15;
>  int *p;
>
>  p = &a;
>
>  printf("%d\n",*p);
>  scanf("%d\n",p);

    That's really simple to interpret. Anyway. You are passing to printf the 
value stored at the pointee's address. With the scanf you are passing the 
pointer's address. Since pointers can only hold addresses. I would say the 
scanf  example is "pass by address" and the printf example is "pass by 
value". Is that right? But with scanf in your example; that's the first time 
I've ever seen the /pointer's/ address passed. Usually it's the /pointee's/ 
address using the &. But then that second parameter is an elipses and I 
haven't considered variable argument lists. Way over my head right now 
anyway.

Bill


Bill


Bill 

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

#43950

On Fri, 2 May 2014 18:09:20 -0400, "Bill Cunningham"
<nosapm@nspam.invalid> wrote:

>
>"Lew Pitcher" <lew.pitcher@digitalfreehold.ca> wrote in message 
>news:NxU8v.443052$1p2.55006@fx13.iad...
>
>> Bill, think about this one a bit....
>>
>>  int a = 15;
>>  int *p;
>>
>>  p = &a;
>>
>>  printf("%d\n",*p);
>>  scanf("%d\n",p);
>
>    That's really simple to interpret. Anyway. You are passing to printf the 
>value stored at the pointee's address. With the scanf you are passing the 

In your terminology, the pointer points to the pointee.  So this is
the same as saying you pass the value of the pointee.

>pointer's address. Since pointers can only hold addresses. I would say the 

No.  With scanf you are passing the value of the pointer, not its
address.  That value is the address of a, not of p.

>scanf  example is "pass by address" and the printf example is "pass by 

You can, and usually do, say whatever you want but the simple fact is
that this is pass by value.  The value happens to be an address.  I
don't think anyone has ever said pass by int or pass by double so I
wonder why you consider this particular type of value worthy of
special terminology.

>value". Is that right? But with scanf in your example; that's the first time 
>I've ever seen the /pointer's/ address passed. Usually it's the /pointee's/ 

Here you don't see the pointer's address passed, you see the pointer's
value passed.  But you have seen a pointer's addressed passed just
within the past week.  Go back and look at your previous messages
regarding strtol.

>address using the &. But then that second parameter is an elipses and I 
>haven't considered variable argument lists. Way over my head right now 
>anyway.

You might have an easier time understanding things if you didn't keep
throwing in unrelated issues at the last minute.  Variable argument
lists have nothing to do with whether you pass an object's value or
its address to a function.  That decision is based entirely on the
requirements of the function.

-- 
Remove del for email

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

#43951

In article <bfa8m9hgf8af40gkotf6mgv3ke08mpep0d@4ax.com>,
Barry Schwarz  <schwarzb@dqel.com> wrote:
...
>>address using the &. But then that second parameter is an elipses and I 
>>haven't considered variable argument lists. Way over my head right now 
>>anyway.
>
>You might have an easier time understanding things if you didn't keep
>throwing in unrelated issues at the last minute.  Variable argument
>lists have nothing to do with whether you pass an object's value or
>its address to a function.  That decision is based entirely on the
>requirements of the function.

YHBT

-- 
Modern Christian: Someone who can take time out from
complaining about "welfare mothers popping out babies we
have to feed" to complain about welfare mothers getting
abortions that PREVENT more babies to be raised at public 
expense.

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

#43962

gazelle@shell.xmission.com (Kenny McCormack) writes:

> In article <bfa8m9hgf8af40gkotf6mgv3ke08mpep0d@4ax.com>,
> Barry Schwarz  <schwarzb@dqel.com> wrote:
> ...
>>>address using the &. But then that second parameter is an elipses and I 
>>>haven't considered variable argument lists. Way over my head right now 
>>>anyway.
>>
>>You might have an easier time understanding things if you didn't keep
>>throwing in unrelated issues at the last minute.  Variable argument
>>lists have nothing to do with whether you pass an object's value or
>>its address to a function.  That decision is based entirely on the
>>requirements of the function.
>
> YHBT

Surely they know?

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

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

#43964

In article <877g63hsky.fsf@gmail.com>, Richard  <rgrdev_@gmail.com> wrote:
>gazelle@shell.xmission.com (Kenny McCormack) writes:
>
>> In article <bfa8m9hgf8af40gkotf6mgv3ke08mpep0d@4ax.com>,
>> Barry Schwarz  <schwarzb@dqel.com> wrote:
>> ...
>>>>address using the &. But then that second parameter is an elipses and I 
>>>>haven't considered variable argument lists. Way over my head right now 
>>>>anyway.
>>>
>>>You might have an easier time understanding things if you didn't keep
>>>throwing in unrelated issues at the last minute.  Variable argument
>>>lists have nothing to do with whether you pass an object's value or
>>>its address to a function.  That decision is based entirely on the
>>>requirements of the function.
>>
>> YHBT
>
>Surely they know?

You have to wonder.  My sense (which seems also to be yours) is that they
know but just don't care.  Which is really sad - sadder than if they didn't
know.

They might as well be pontificating to /dev/null - but this seems to bother
them not.  Kind of like members of Congress spewing nonsense into the
Congressional Record at 3 in the morning - benefiting no one as no one is
listening.

-- 
"The God of the Old Testament is arguably the most unpleasant character
in all fiction: jealous and proud of it; a petty, unjust, unforgiving
control-freak; a vindictive, bloodthirsty ethnic cleanser; a misogynistic,
homophobic, racist, infanticidal, genocidal, filicidal, pestilential,
megalomaniacal, sadomasochistic, capriciously malevolent bully."

 - Richard Dawkins, The God Delusion -

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

#43971

On Sat, 3 May 2014 14:08:32 +0000 (UTC), gazelle@shell.xmission.com
(Kenny McCormack) wrote:

>In article <877g63hsky.fsf@gmail.com>, Richard  <rgrdev_@gmail.com> wrote:
>>gazelle@shell.xmission.com (Kenny McCormack) writes:
>>
>>> In article <bfa8m9hgf8af40gkotf6mgv3ke08mpep0d@4ax.com>,
>>> Barry Schwarz  <schwarzb@dqel.com> wrote:
>>> ...
>>>>>address using the &. But then that second parameter is an elipses and I 
>>>>>haven't considered variable argument lists. Way over my head right now 
>>>>>anyway.
>>>>
>>>>You might have an easier time understanding things if you didn't keep
>>>>throwing in unrelated issues at the last minute.  Variable argument
>>>>lists have nothing to do with whether you pass an object's value or
>>>>its address to a function.  That decision is based entirely on the
>>>>requirements of the function.
>>>
>>> YHBT
>>
>>Surely they know?
>
>You have to wonder.  My sense (which seems also to be yours) is that they
>know but just don't care.  Which is really sad - sadder than if they didn't
>know.
>
>They might as well be pontificating to /dev/null - but this seems to bother
>them not.  Kind of like members of Congress spewing nonsense into the
>Congressional Record at 3 in the morning - benefiting no one as no one is
>listening.

Yes, nothing we say will ever have any impact on Bill.

But if some poor newcomer happens upon this group looking for advice,
I think it would be nice if they could see something that tells them
to ignore Bill's absurdities.

-- 
Remove del for email

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

#43972

Barry Schwarz <schwarzb@dqel.com> writes:

> On Sat, 3 May 2014 14:08:32 +0000 (UTC), gazelle@shell.xmission.com
> (Kenny McCormack) wrote:
>
>>In article <877g63hsky.fsf@gmail.com>, Richard  <rgrdev_@gmail.com> wrote:
>>>gazelle@shell.xmission.com (Kenny McCormack) writes:
>>>
>>>> In article <bfa8m9hgf8af40gkotf6mgv3ke08mpep0d@4ax.com>,
>>>> Barry Schwarz  <schwarzb@dqel.com> wrote:
>>>> ...
>>>>>>address using the &. But then that second parameter is an elipses and I 
>>>>>>haven't considered variable argument lists. Way over my head right now 
>>>>>>anyway.
>>>>>
>>>>>You might have an easier time understanding things if you didn't keep
>>>>>throwing in unrelated issues at the last minute.  Variable argument
>>>>>lists have nothing to do with whether you pass an object's value or
>>>>>its address to a function.  That decision is based entirely on the
>>>>>requirements of the function.
>>>>
>>>> YHBT
>>>
>>>Surely they know?
>>
>>You have to wonder.  My sense (which seems also to be yours) is that they
>>know but just don't care.  Which is really sad - sadder than if they didn't
>>know.
>>
>>They might as well be pontificating to /dev/null - but this seems to bother
>>them not.  Kind of like members of Congress spewing nonsense into the
>>Congressional Record at 3 in the morning - benefiting no one as no one is
>>listening.
>
> Yes, nothing we say will ever have any impact on Bill.
>
> But if some poor newcomer happens upon this group looking for advice,
> I think it would be nice if they could see something that tells them
> to ignore Bill's absurdities.

Err yes. Proclamations that he's an idiot troll. Not reams and reams of
yet more explanations of what a pointer is.


-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

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

#43956

"Barry Schwarz" <schwarzb@dqel.com> wrote in message 
news:bfa8m9hgf8af40gkotf6mgv3ke08mpep0d@4ax.com...
> On Fri, 2 May 2014 18:09:20 -0400, "Bill Cunningham"
> <nosapm@nspam.invalid> wrote:
>
>>
>>"Lew Pitcher" <lew.pitcher@digitalfreehold.ca> wrote in message
>>news:NxU8v.443052$1p2.55006@fx13.iad...
>>
>>> Bill, think about this one a bit....
>>>
>>>  int a = 15;
>>>  int *p;
>>>
>>>  p = &a;
>>>
>>>  printf("%d\n",*p);
>>>  scanf("%d\n",p);
>>
>>    That's really simple to interpret. Anyway. You are passing to printf 
>> the
>>value stored at the pointee's address. With the scanf you are passing the
>
> In your terminology, the pointer points to the pointee.  So this is
> the same as saying you pass the value of the pointee.

    Which happens to be 15.

>>pointer's address. Since pointers can only hold addresses. I would say the
>
> No.  With scanf you are passing the value of the pointer, not its
> address.  That value is the address of a, not of p.

    That's what I said. The value of a pointer variable is an address. Which 
is the address holding the 15.

>>scanf  example is "pass by address" and the printf example is "pass by
>
> You can, and usually do, say whatever you want but the simple fact is
> that this is pass by value.  The value happens to be an address.  I
> don't think anyone has ever said pass by int or pass by double so I
> wonder why you consider this particular type of value worthy of
> special terminology.

    The book said pass by address. It's not my term.

>>value". Is that right? But with scanf in your example; that's the first 
>>time
>>I've ever seen the /pointer's/ address passed. Usually it's the 
>>/pointee's/
>
> Here you don't see the pointer's address passed, you see the pointer's
> value passed.  But you have seen a pointer's addressed passed just
> within the past week.  Go back and look at your previous messages
> regarding strtol.
>
>>address using the &. But then that second parameter is an elipses and I
>>haven't considered variable argument lists. Way over my head right now
>>anyway.
>
> You might have an easier time understanding things if you didn't keep
> throwing in unrelated issues at the last minute.  Variable argument
> lists have nothing to do with whether you pass an object's value or
> its address to a function.  That decision is based entirely on the
> requirements of the function.

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

#43965

"Barry Schwarz" <schwarzb@dqel.com> wrote in message 
news:bfa8m9hgf8af40gkotf6mgv3ke08mpep0d@4ax.com...
> On Fri, 2 May 2014 18:09:20 -0400, "Bill Cunningham"
> <nosapm@nspam.invalid> wrote:
>
>>
>>"Lew Pitcher" <lew.pitcher@digitalfreehold.ca> wrote in message
>>news:NxU8v.443052$1p2.55006@fx13.iad...
>>
>>> Bill, think about this one a bit....
>>>
>>>  int a = 15;
>>>  int *p;
>>>
>>>  p = &a;
>>>
>>>  printf("%d\n",*p);
>>>  scanf("%d\n",p);
>>
>>    That's really simple to interpret. Anyway. You are passing to printf 
>> the
>>value stored at the pointee's address. With the scanf you are passing the
>
> In your terminology, the pointer points to the pointee.  So this is
> the same as saying you pass the value of the pointee.
>
>>pointer's address. Since pointers can only hold addresses. I would say the
>
> No.  With scanf you are passing the value of the pointer, not its
> address.  That value is the address of a, not of p.
>
>>scanf  example is "pass by address" and the printf example is "pass by
>
> You can, and usually do, say whatever you want but the simple fact is
> that this is pass by value.  The value happens to be an address.  I
> don't think anyone has ever said pass by int or pass by double so I
> wonder why you consider this particular type of value worthy of
> special terminology.
>
>>value". Is that right? But with scanf in your example; that's the first 
>>time
>>I've ever seen the /pointer's/ address passed. Usually it's the 
>>/pointee's/
>
> Here you don't see the pointer's address passed, you see the pointer's
> value passed.  But you have seen a pointer's addressed passed just
> within the past week.  Go back and look at your previous messages
> regarding strtol.
>
>>address using the &. But then that second parameter is an elipses and I
>>haven't considered variable argument lists. Way over my head right now
>>anyway.
>
> You might have an easier time understanding things if you didn't keep
> throwing in unrelated issues at the last minute.  Variable argument
> lists have nothing to do with whether you pass an object's value or
> its address to a function.  That decision is based entirely on the
> requirements of the function.

    Barry I'm in no position to argue with you. I am only reading the book. 
It seems to be a little simpler than others I've read. I try. If you say 
there's no "pass by address" then there isn't. That's just what the book's 
calling it. One tells me get a book, another get rid of the book. I 
appreciate the help and that's why I ask but it's hard to connect with 
someone through usenet. I don't expect it to be. Maybe scanf is a bad 
example. I know this is so though...

int a=15;
int *p;
p=&a; // And my compiler complains about that. It calls it old style and 
says = & if I remember right.

I am not giving up but maybe I shoud "regroup" take a break and reconsider 
or something. Try at a different angle. If at first you don't succeed 
well...They say try again.

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

#43970

On 05/03/2014 11:22 AM, Bill Cunningaham wrote:
...

When did you become "Cunning a ham"? I'll have to fix my filters.
-- 
James Kuyper

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

#43974

"Bill Cunningaham" <nospam@nspam.invalid> writes:
[...]
> int a=15;
> int *p;
> p=&a; // And my compiler complains about that. It calls it old style and 
> says = & if I remember right.

Really?

In very early versions of C, the compound assignment operators put
the "=" before the operator rather than after it.  For example,
the old syntax to subtract 2 from i was
    i =- 2;
rather than the modern
    i -= 2;

This caused ambiguities if you didn't use enough whitespace,
resolved as usual via the "maximal munch" rule.  For example:

    i=-2;

would subtract 2 from i rather than assigning the value -2 to i.
Problems could occur for any unary operator that uses the same
symbol as a binary operator that can be part of a compound assignment
operator.

The syntax of compound assignment operators was changed before the
publication of K&R1 in 1978.  Some older compilers would warn about
code that would be parsed differently under the old and new rules.
I've even used a compiler that would warn about it and then use the
old interpretation (it recognized modern operators in unambiguous
cases); fortunately we also had a more modern compiler available.

Bill, the compiler complaint you describe is consistent with
your using an old compiler that warns about code whose meaning
differs between the ancient and modern versions of the language.
As I recall, you use gcc, which certainly doesn't warn about such
things by default, and as far as I know cannot even be made to warn
about them.

And the code that was suggested to you upthread used:
    p = &a;
which you changed for some reason to:
    p=&a;

I'd be interested in knowing exactly what compiler you're using,
what OS you're using it on, and seeing the exact copy-and-pasted
diagnostic message from that 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]

#43978

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

> "Bill Cunningaham" <nospam@nspam.invalid> writes:
> [...]
>> int a=15;
>> int *p;
>> p=&a; // And my compiler complains about that. It calls it old style and 
>> says = & if I remember right.
>
> Really?
>
> In very early versions of C, the compound assignment operators put
> the "=" before the operator rather than after it.  For example,
> the old syntax to subtract 2 from i was
>     i =- 2;
> rather than the modern
>     i -= 2;
>
> This caused ambiguities if you didn't use enough whitespace,
> resolved as usual via the "maximal munch" rule.  For example:
>
>     i=-2;
>
> would subtract 2 from i rather than assigning the value -2 to i.
> Problems could occur for any unary operator that uses the same
> symbol as a binary operator that can be part of a compound assignment
> operator.
>
> The syntax of compound assignment operators was changed before the
> publication of K&R1 in 1978.  Some older compilers would warn about
> code that would be parsed differently under the old and new rules.
> I've even used a compiler that would warn about it and then use the
> old interpretation (it recognized modern operators in unambiguous
> cases); fortunately we also had a more modern compiler available.
>
> Bill, the compiler complaint you describe is consistent with
> your using an old compiler that warns about code whose meaning
> differs between the ancient and modern versions of the language.
> As I recall, you use gcc, which certainly doesn't warn about such
> things by default, and as far as I know cannot even be made to warn
> about them.
>
> And the code that was suggested to you upthread used:
>     p = &a;
> which you changed for some reason to:
>     p=&a;
>
> I'd be interested in knowing exactly what compiler you're using,
> what OS you're using it on, and seeing the exact copy-and-pasted
> diagnostic message from that compiler.

ROTFLM!

http://www.politicsforum.org/images/flame_warriors/flame_61.php


-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

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

#43979

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

(snip)

> In very early versions of C, the compound assignment operators put
> the "=" before the operator rather than after it.  For example,
> the old syntax to subtract 2 from i was
>    i =- 2;
> rather than the modern
>    i -= 2;
 
> This caused ambiguities if you didn't use enough whitespace,
> resolved as usual via the "maximal munch" rule.  For example:
 
>    i=-2;
 
> would subtract 2 from i rather than assigning the value -2 to i.
> Problems could occur for any unary operator that uses the same
> symbol as a binary operator that can be part of a compound assignment
> operator.
 
> The syntax of compound assignment operators was changed before the
> publication of K&R1 in 1978.  Some older compilers would warn about
> code that would be parsed differently under the old and new rules.
> I've even used a compiler that would warn about it and then use the
> old interpretation (it recognized modern operators in unambiguous
> cases); fortunately we also had a more modern compiler available.

I had a compiler that would do that around 1988. (As well as I 
remember, both warn and then do the old way.) For some time, 
I got used to putting in that extra space. 

(My usual convention is not to put space around =, but to put
it around all the compound assignment operators.)

> Bill, the compiler complaint you describe is consistent with
> your using an old compiler that warns about code whose meaning
> differs between the ancient and modern versions of the language.
> As I recall, you use gcc, which certainly doesn't warn about such
> things by default, and as far as I know cannot even be made to warn
> about them.

Along with the X'1A', it is plenty long ago enough now.

-- glen

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

#43989

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:lk3ml7$fb8$1@speranza.aioe.org...
> Keith Thompson <kst-u@mib.org> wrote:
>
> (snip)
>
>> In very early versions of C, the compound assignment operators put
>> the "=" before the operator rather than after it.  For example,
>> the old syntax to subtract 2 from i was
>>    i =- 2;
>> rather than the modern
>>    i -= 2;
>
>> This caused ambiguities if you didn't use enough whitespace,
>> resolved as usual via the "maximal munch" rule.  For example:
>
>>    i=-2;
>
>> would subtract 2 from i rather than assigning the value -2 to i.
>> Problems could occur for any unary operator that uses the same
>> symbol as a binary operator that can be part of a compound assignment
>> operator.
>
>> The syntax of compound assignment operators was changed before the
>> publication of K&R1 in 1978.  Some older compilers would warn about
>> code that would be parsed differently under the old and new rules.
>> I've even used a compiler that would warn about it and then use the
>> old interpretation (it recognized modern operators in unambiguous
>> cases); fortunately we also had a more modern compiler available.
>
> I had a compiler that would do that around 1988. (As well as I
> remember, both warn and then do the old way.) For some time,
> I got used to putting in that extra space.
>
> (My usual convention is not to put space around =, but to put
> it around all the compound assignment operators.)
>
>> Bill, the compiler complaint you describe is consistent with
>> your using an old compiler that warns about code whose meaning
>> differs between the ancient and modern versions of the language.
>> As I recall, you use gcc, which certainly doesn't warn about such
>> things by default, and as far as I know cannot even be made to warn
>> about them.
>
> Along with the X'1A', it is plenty long ago enough now.

    It wasn't the compiler it was the indent program. It mentioned = &. I 
can't seem to remember how to redirect stderr now. And this code works. So I 
don't know why people are telling me it doesn't. I think some people are 
just playing around with me and lying and trying to confuse me. Well here it 
is.

#include <stdio.h>

int main()
{
    int a = 15;
    int *p;
    p = &a;
    printf("%p\n", &p);
    printf("%p\n", p);
    printf("%d\n", *p);
}

The result.

0x7fff8a9bb7b0
0x7fff8a9bb7bc
15

And everytime this is run there is a new addresss used.

Bill

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

#43991

On Sun, 4 May 2014 00:08:07 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>    It wasn't the compiler it was the indent program. It mentioned = &. I 
>can't seem to remember how to redirect stderr now. And this code works. So I 
>don't know why people are telling me it doesn't. I think some people are 
>just playing around with me and lying and trying to confuse me. Well here it 
>is.
>
>#include <stdio.h>
>
>int main()
>{
>    int a = 15;
>    int *p;
>    p = &a;
>    printf("%p\n", &p);

Undefined behavior #1.

>    printf("%p\n", p);

Undefined behavior #2.

>    printf("%d\n", *p);
>}
>
>The result.
>
>0x7fff8a9bb7b0
>0x7fff8a9bb7bc
>15
>
>And everytime this is run there is a new addresss used.

And this surprises you because?

-- 
Remove del for email

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

#43996

On 2014-05-04, Barry Schwarz <schwarzb@dqel.com> wrote:

>>#include <stdio.h>
>>
>>int main()
>>{
>>    int a = 15;
>>    int *p;
>>    p = &a;
>>    printf("%p\n", &p);
>
> Undefined behavior #1.
>
>>    printf("%p\n", p);
>
> Undefined behavior #2.
>
>>    printf("%d\n", *p);
>>}

   I don't understand where in the undefined behaviour. Not so usable
   values printed, yes, but &p and p are pointers, so %p can print their
   values, no ?

   Maybe because p and &p are not 'void *' pointers...


-- 
                         http://weblog.mixart-myrys.org/?post/2014/04/THSF-2014

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

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

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

csiph-web