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

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

Issue on assigning address to pointers

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

Contents

  Issue on assigning address to pointers Alla _ <modelling.data@gmail.com> - 2015-11-17 08:49 -0800
    Re: Issue on assigning address to pointers James Kuyper <jameskuyper@verizon.net> - 2015-11-17 12:36 -0500
      Re: Issue on assigning address to pointers Richard Heathfield <rjh@cpax.org.uk> - 2015-11-17 17:47 +0000
        Re: Issue on assigning address to pointers Alla _ <modelling.data@gmail.com> - 2015-11-17 10:34 -0800
          Re: Issue on assigning address to pointers Keith Thompson <kst-u@mib.org> - 2015-11-17 12:16 -0800
          Re: Issue on assigning address to pointers James Kuyper <jameskuyper@verizon.net> - 2015-11-17 15:23 -0500
      Re: Issue on assigning address to pointers Alla _ <modelling.data@gmail.com> - 2015-11-17 10:33 -0800
    Re: Issue on assigning address to pointers Keith Thompson <kst-u@mib.org> - 2015-11-17 09:41 -0800
      Re: Issue on assigning address to pointers Geoff <geoff@invalid.invalid> - 2015-11-17 10:03 -0800
        Re: Issue on assigning address to pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-17 20:31 +0000
          Re: Issue on assigning address to pointers Geoff <geoff@invalid.invalid> - 2015-11-17 12:53 -0800
      Re: Issue on assigning address to pointers Alla _ <modelling.data@gmail.com> - 2015-11-17 10:32 -0800
        Re: Issue on assigning address to pointers Richard Heathfield <rjh@cpax.org.uk> - 2015-11-17 18:45 +0000
          Re: Issue on assigning address to pointers Alla _ <modelling.data@gmail.com> - 2015-11-17 10:53 -0800
          Re: Issue on assigning address to pointers Keith Thompson <kst-u@mib.org> - 2015-11-17 15:05 -0800
            Re: Issue on assigning address to pointers Philip Lantz <prl@canterey.us> - 2015-11-19 21:16 -0800
          Re: Issue on assigning address to pointers Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2015-11-17 15:47 -0800
          Re: Issue on assigning address to pointers Barry Schwarz <schwarzb@dqel.com> - 2015-11-17 15:53 -0800
            Re: Issue on assigning address to pointers Richard Heathfield <rjh@cpax.org.uk> - 2015-11-18 04:05 +0000
        Re: Issue on assigning address to pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-17 19:41 +0000
    Re: Issue on assigning address to pointers Stephen Sprunk <stephen@sprunk.org> - 2015-11-17 12:17 -0600
      Re: Issue on assigning address to pointers Richard Heathfield <rjh@cpax.org.uk> - 2015-11-17 18:21 +0000
        Re: Issue on assigning address to pointers Geoff <geoff@invalid.invalid> - 2015-11-17 10:36 -0800
          Re: Issue on assigning address to pointers Richard Heathfield <rjh@cpax.org.uk> - 2015-11-17 18:46 +0000
            Re: Issue on assigning address to pointers Alla _ <modelling.data@gmail.com> - 2015-11-17 10:49 -0800
          Re: Issue on assigning address to pointers Alla _ <modelling.data@gmail.com> - 2015-11-17 10:47 -0800
            Re: Issue on assigning address to pointers Richard Heathfield <rjh@cpax.org.uk> - 2015-11-17 18:51 +0000
              Re: Issue on assigning address to pointers Alla _ <modelling.data@gmail.com> - 2015-11-17 10:55 -0800
            Re: Issue on assigning address to pointers Geoff <geoff@invalid.invalid> - 2015-11-17 11:59 -0800
        Re: Issue on assigning address to pointers Stephen Sprunk <stephen@sprunk.org> - 2015-11-17 12:58 -0600
          Re: Issue on assigning address to pointers Richard Heathfield <rjh@cpax.org.uk> - 2015-11-17 19:12 +0000
        Re: Issue on assigning address to pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-17 19:33 +0000
      Re: Issue on assigning address to pointers Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-17 13:25 -0500
    Re: Issue on assigning address to pointers Richard Heathfield <rjh@cpax.org.uk> - 2015-11-17 18:31 +0000
      Re: Issue on assigning address to pointers Alla _ <modelling.data@gmail.com> - 2015-11-17 10:39 -0800
      Re: Issue on assigning address to pointers Alla _ <modelling.data@gmail.com> - 2015-11-17 10:40 -0800
        Re: Issue on assigning address to pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-17 19:40 +0000
    Re: Issue on assigning address to pointers Geoff <geoff@invalid.invalid> - 2015-11-17 11:15 -0800
      Re: Issue on assigning address to pointers James Kuyper <jameskuyper@verizon.net> - 2015-11-17 15:32 -0500
      Re: Issue on assigning address to pointers Keith Thompson <kst-u@mib.org> - 2015-11-17 15:09 -0800
        Re: Issue on assigning address to pointers supercat@casperkitty.com - 2015-11-17 15:41 -0800
          Re: Issue on assigning address to pointers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-17 21:28 -0800
            Re: Issue on assigning address to pointers supercat@casperkitty.com - 2015-11-17 23:18 -0800
        Re: Issue on assigning address to pointers Geoff <geoff@invalid.invalid> - 2015-11-17 17:18 -0800
          Re: Issue on assigning address to pointers James Kuyper <jameskuyper@verizon.net> - 2015-11-17 22:37 -0500
    Re: Issue on assigning address to pointers Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-11-18 11:27 +0100
      Re: Issue on assigning address to pointers Keith Thompson <kst-u@mib.org> - 2015-11-18 06:13 -0800
    Re: Issue on assigning address to pointers guinness.tony@gmail.com - 2015-11-24 02:46 -0800
      Re: Issue on assigning address to pointers Keith Thompson <kst-u@mib.org> - 2015-11-24 09:21 -0800
    Re: Issue on assigning address to pointers John Bode <jfbode1029@gmail.com> - 2015-11-24 05:01 -0800
      Re: Issue on assigning address to pointers Keith Thompson <kst-u@mib.org> - 2015-11-24 09:22 -0800
    Re: Issue on assigning address to pointers John Bode <jfbode1029@gmail.com> - 2015-11-24 06:47 -0800
      Re: Issue on assigning address to pointers Alla _ <modelling.data@gmail.com> - 2015-11-25 06:44 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#76257

On 17-Nov-15 10:49, Alla _ wrote:
> I have seen many times the following declaration of pointers to
> arrays, advised without any caveats:
> 
> int numbers[8];
> int *ptr;
> 
> ptr = numbers + 8; // to point at a value stored at numbers[8]
> 
> Please, take a look at a paragraph from K&R, stating that this method
> doesn't work on "multi-tasking machines". Given K&R was published in
> 1999, I wonder if that statement still holds.

It might have been in K&R1, published in 1978, but that has been
obsolete since ANSI C in 1989; it's not in K&R2, published in 1999.

> The code above sets the array arrayname to zero. This method of
> getting at array data is not recommended by this author except in
> very simple computer environments. If a program is running on a
> normal microcomputer, then there should be few problems with this
> alternative method of handling arrays. On the hand, if the
> microcomputer is multi-tasking, or the program is running on a larger
> system which has a limited manager, then memory ceases to be
> something which can be thought of as a sequence of boxes standing
> next to one another.

Standard C _guarantees_ that, as far as the program can tell, elements
of an array _are_ contiguous in (virtual) memory.

It's entirely possible that, under the hood, the array spans a page
boundary and those pages are not contiguous in (physical) memory, but it
must _appear to the program_ as if they were contiguous, using whatever
mechanisms are necessary for that to occur.

> So ptr = arrayname + 5; might not be a pointer to the fifth character
> in a character array. This could be found instead using the '&'
> operator. A pointer to the fifth element can be reliably found with:
> ptr = &(arrayname[5]);
> Be warned!
> END OF QUOTE

Standard C _defines_ arrayname+5 to be identical to &arrayname[5]; use
whichever more clearly expresses your intent to human readers.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#76258

On 17/11/15 18:17, Stephen Sprunk wrote:
> On 17-Nov-15 10:49, Alla _ wrote:
>> I have seen many times the following declaration of pointers to
>> arrays, advised without any caveats:
>>
>> int numbers[8];
>> int *ptr;
>>
>> ptr = numbers + 8; // to point at a value stored at numbers[8]
>>
>> Please, take a look at a paragraph from K&R, stating that this method
>> doesn't work on "multi-tasking machines". Given K&R was published in
>> 1999, I wonder if that statement still holds.
>
> It might have been in K&R1, published in 1978,

Unlikely.

> but that has been
> obsolete since ANSI C in 1989; it's not in K&R2, published in 1999.

Published *when*? Citation most definitely required!

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

#76266

On Tue, 17 Nov 2015 18:21:48 +0000, Richard Heathfield
<rjh@cpax.org.uk> wrote:

>On 17/11/15 18:17, Stephen Sprunk wrote:
>> On 17-Nov-15 10:49, Alla _ wrote:
>>> I have seen many times the following declaration of pointers to
>>> arrays, advised without any caveats:
>>>
>>> int numbers[8];
>>> int *ptr;
>>>
>>> ptr = numbers + 8; // to point at a value stored at numbers[8]
>>>
>>> Please, take a look at a paragraph from K&R, stating that this method
>>> doesn't work on "multi-tasking machines". Given K&R was published in
>>> 1999, I wonder if that statement still holds.
>>
>> It might have been in K&R1, published in 1978,
>
>Unlikely.
>
>> but that has been
>> obsolete since ANSI C in 1989; it's not in K&R2, published in 1999.
>
>Published *when*? Citation most definitely required!

"The C Programming Language" Second Edition ISBN 0-13-110362-8,
Prentice Hall Software Series bears Copyright 1988.

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

#76270

On 17/11/15 18:36, Geoff wrote:
> On Tue, 17 Nov 2015 18:21:48 +0000, Richard Heathfield
> <rjh@cpax.org.uk> wrote:
>
>> On 17/11/15 18:17, Stephen Sprunk wrote:
>>> On 17-Nov-15 10:49, Alla _ wrote:
>>>> I have seen many times the following declaration of pointers to
>>>> arrays, advised without any caveats:
>>>>
>>>> int numbers[8];
>>>> int *ptr;
>>>>
>>>> ptr = numbers + 8; // to point at a value stored at numbers[8]
>>>>
>>>> Please, take a look at a paragraph from K&R, stating that this method
>>>> doesn't work on "multi-tasking machines". Given K&R was published in
>>>> 1999, I wonder if that statement still holds.
>>>
>>> It might have been in K&R1, published in 1978,
>>
>> Unlikely.
>>
>>> but that has been
>>> obsolete since ANSI C in 1989; it's not in K&R2, published in 1999.
>>
>> Published *when*? Citation most definitely required!
>
> "The C Programming Language" Second Edition ISBN 0-13-110362-8,
> Prentice Hall Software Series bears Copyright 1988.

if(1999 == 1988)
{
   puts("Okay, fair enough.");
}
else
{
   puts("I rest my case.");
}

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

#76272

On Tuesday, November 17, 2015 at 10:46:57 PM UTC+4, Richard Heathfield wrote:
> On 17/11/15 18:36, Geoff wrote:
> > On Tue, 17 Nov 2015 18:21:48 +0000, Richard Heathfield
> > <rjh@cpax.org.uk> wrote:
> >
> >> On 17/11/15 18:17, Stephen Sprunk wrote:
> >>> On 17-Nov-15 10:49, Alla _ wrote:
> >>>> I have seen many times the following declaration of pointers to
> >>>> arrays, advised without any caveats:
> >>>>
> >>>> int numbers[8];
> >>>> int *ptr;
> >>>>
> >>>> ptr = numbers + 8; // to point at a value stored at numbers[8]
> >>>>
> >>>> Please, take a look at a paragraph from K&R, stating that this method
> >>>> doesn't work on "multi-tasking machines". Given K&R was published in
> >>>> 1999, I wonder if that statement still holds.
> >>>
> >>> It might have been in K&R1, published in 1978,
> >>
> >> Unlikely.
> >>
> >>> but that has been
> >>> obsolete since ANSI C in 1989; it's not in K&R2, published in 1999.
> >>
> >> Published *when*? Citation most definitely required!
> >
> > "The C Programming Language" Second Edition ISBN 0-13-110362-8,
> > Prentice Hall Software Series bears Copyright 1988.
> 
> if(1999 == 1988)
> {
>    puts("Okay, fair enough.");
> }
> else
> {
>    puts("I rest my case.");
> }
> 
:)

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

#76271

> 
> "The C Programming Language" Second Edition ISBN 0-13-110362-8,
> Prentice Hall Software Series bears Copyright 1988.

Is it the one by Kernighan and Ritchie? Thank you!

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

#76274

On 17/11/15 18:47, Alla _ wrote:
>
>>
>> "The C Programming Language" Second Edition ISBN 0-13-110362-8,
>> Prentice Hall Software Series bears Copyright 1988.
>
> Is it the one by Kernighan and Ritchie? Thank you!

Yes.

Here's a link to the cover art:

http://s3-us-west-2.amazonaws.com/belllabs-microsite-dritchie/cbook/index.html

I got the URL directly from Dennis Ritchie's home page, which seems to 
have been restored by Bell Labs. It is here:

https://www.bell-labs.com/usr/dmr/www/

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

#76276

On Tuesday, November 17, 2015 at 10:51:49 PM UTC+4, Richard Heathfield wrote:
> On 17/11/15 18:47, Alla _ wrote:
> >
> >>
> >> "The C Programming Language" Second Edition ISBN 0-13-110362-8,
> >> Prentice Hall Software Series bears Copyright 1988.
> >
> > Is it the one by Kernighan and Ritchie? Thank you!
> 
> Yes.
> 
> Here's a link to the cover art:
> 
> http://s3-us-west-2.amazonaws.com/belllabs-microsite-dritchie/cbook/index.html
> 
> I got the URL directly from Dennis Ritchie's home page, which seems to 
> have been restored by Bell Labs. It is here:
> 
> https://www.bell-labs.com/usr/dmr/www/
> 
Thank you very much. Yes, I've already found the book. Well, 
next round begins ) 

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

#76284

On Tue, 17 Nov 2015 10:47:30 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:

>
>> 
>> "The C Programming Language" Second Edition ISBN 0-13-110362-8,
>> Prentice Hall Software Series bears Copyright 1988.
>
>Is it the one by Kernighan and Ritchie? Thank you!

Yes. The ISBN lookup will confirm this.

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

#76277

On 17-Nov-15 12:21, Richard Heathfield wrote:
> On 17/11/15 18:17, Stephen Sprunk wrote:
>> it's not in K&R2, published in 1999.
> 
> Published *when*? Citation most definitely required!

Typo.  I told my fingers 1988, they typed 1999.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#76278

On 17/11/15 18:58, Stephen Sprunk wrote:
> On 17-Nov-15 12:21, Richard Heathfield wrote:
>> On 17/11/15 18:17, Stephen Sprunk wrote:
>>> it's not in K&R2, published in 1999.
>>
>> Published *when*? Citation most definitely required!
>
> Typo.  I told my fingers 1988, they typed 1999.


That's the trouble with the old-fashioned sort. Trade them in. Nowadays 
you can get digital fingers. :-)


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

#76280

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 17/11/15 18:17, Stephen Sprunk wrote:
>> On 17-Nov-15 10:49, Alla _ wrote:
>>> I have seen many times the following declaration of pointers to
>>> arrays, advised without any caveats:
>>>
>>> int numbers[8];
>>> int *ptr;
>>>
>>> ptr = numbers + 8; // to point at a value stored at numbers[8]
>>>
>>> Please, take a look at a paragraph from K&R, stating that this method
>>> doesn't work on "multi-tasking machines". Given K&R was published in
>>> 1999, I wonder if that statement still holds.
>>
>> It might have been in K&R1, published in 1978,
>
> Unlikely.

Certain.  I've gone over it to be sure.  Anyway, the writing style is
all wrong and the content is nonsense!

<snip>
-- 
Ben.

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

#76260

On Tuesday November 17 2015 13:17, in comp.lang.c, "Stephen Sprunk"
<stephen@sprunk.org> wrote:

> On 17-Nov-15 10:49, Alla _ wrote:
>> I have seen many times the following declaration of pointers to
>> arrays, advised without any caveats:
>> 
>> int numbers[8];
>> int *ptr;
>> 
>> ptr = numbers + 8; // to point at a value stored at numbers[8]
>> 
>> Please, take a look at a paragraph from K&R, stating that this method
>> doesn't work on "multi-tasking machines". Given K&R was published in
>> 1999, I wonder if that statement still holds.
> 
> It might have been in K&R1, published in 1978,

Nope. I just checked. Chapter 5 ("Pointers and Arrays") doesn't include such a
comment, and I cannot find it anywhere else in the book.

FWIW, Chapter 5 includes example code (specifically, several implementations
of strcpy() ) that explicitly violate the quoted admonition

> but that has been 
> obsolete since ANSI C in 1989; it's not in K&R2, published in 1999.

A google search on the admonition's text comes up with
  http://www.iu.hio.no/~mark/CTutorial/CTutorial.html
as a source. The web page begins:
  C Programming Tutorial (K&R version 4)

  This is a C Programming Tutorial for people who have a little experience
  with an interpreted programming language, such as Emacs Lisp or a GNU shell.

  Edition 4.02

  Copyright © 1987,1999 Mark Burgess 

Apparently, the OP mistook Mr. Burgess's tutorial for something it is not.

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

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

#76262

On 17/11/15 16:49, Alla _ wrote:
> Hello!
>
> I have seen many times the following declaration of pointers to arrays,
> advised without any caveats:
>
> int numbers[8];
> int *ptr;
>
> ptr = numbers + 8; // to point at a value stored at numbers[8]

No, it points at the location just past the array. (There isn't a 
numbers[8] - the eight-element array's eight indices are 0, 1, 2, 3, 4, 
5, 6, 7 - count them!)

Forming such a pointer is legal (which makes constructs such as:

for(ptrb = numbers; ptrb < ptr; ptr++)
{
   dosomethingwith(*ptrb);
}

legal), but dereferencing ptr is not.

> Please, take a look at a paragraph from K&R, stating that this method
> doesn't work on "multi-tasking machines". Given K&R was published in
> 1999, I wonder if that statement still holds.

It isn't K&R. K&R wasn't published in 1999, but in 1978 (1st edition) 
and 1988 (2nd edition). And it doesn't contain broken advice such as 
that which you quote.

> QUOTE:
> char arrayname[5];
> char *ptr;
> for (ptr = arrayname; ptr <= arrayname+4; ptr++)
> {
> *ptr = 0;
> }
> The code above sets the array arrayname to zero.

No, it sets all elements of that array to 0, as does the far superior:

char arrayname[5] = {0};

> This method of getting
> at array data is not recommended by this author except in very simple
> computer environments. If a program is running on a normal microcomputer,
> then there should be few problems with this alternative method of handling
> arrays. On the hand, if the microcomputer is multi-tasking, or the program
> is running on a larger system which has a limited manager, then memory
> ceases to be something which can be thought of as a sequence of boxes
> standing next to one another. A multi-tasking system shares memory with
> Questions 175
> other programs and it takes what it can find, where it can find it. The upshot
> of this is that it is not possible to guarantee that arrays will be stored in one
> simple string of memory locations: it might be scattered around in different
> places.

At this point, you can safely discard the book. I suggest investing in 
K&R instead. The 2nd edition is the one you want. I don't know what 
you're smoking, but it isn't K&R.

> So
> ptr = arrayname + 5;
> might not be a pointer to the fifth character in a character array.

Indeed. It will be the sixth. Count them:

arrayname + 0 = pointer to the first element (element 0)
arrayname + 1 = pointer to the second element (element 1)
arrayname + 2 = pointer to the third element (element 2)
arrayname + 3 = pointer to the fourth element (element 3)
arrayname + 4 = pointer to the fifth element (element 4)
arrayname + 5 = pointer to the sixth element (element 5)

> This could
> be found instead using the '&' operator. A pointer to the fifth element can
> be reliably found with:
> ptr = &(arrayname[5]);
> Be warned!

Be warned that the book is teaching you nonsense.

arrayname[5] is exactly equivalent to *(arrayname + 5).

& and * cancel. So

ptr = &(arrayname[5]);

is exactly equivalent to:

ptr = arrayname + 5;

which is the very construct that the author (wrongly) warned you about. 
He clearly doesn't know what he's doing, and needs to be ignored very 
very loudly.

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

#76267

> At this point, you can safely discard the book. I suggest investing in 
> K&R instead. The 2nd edition is the one you want. I don't know what 
> you're smoking, but it isn't K&R.
>
Oh. Sad that I've spent precious time (few days) on reading it.
What's K&R then? That's what Google "helped" me to find )

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

#76268

On Tuesday, November 17, 2015 at 10:31:41 PM UTC+4, Richard Heathfield wrote:
> On 17/11/15 16:49, Alla _ wrote:
> > Hello!
> >
> > I have seen many times the following declaration of pointers to arrays,
> > advised without any caveats:
> >
> > int numbers[8];
> > int *ptr;
> >
> > ptr = numbers + 8; // to point at a value stored at numbers[8]
> 
> No, it points at the location just past the array. (There isn't a 
> numbers[8] - the eight-element array's eight indices are 0, 1, 2, 3, 4, 
> 5, 6, 7 - count them!)
> 
> Forming such a pointer is legal (which makes constructs such as:
> 
> for(ptrb = numbers; ptrb < ptr; ptr++)
> {
>    dosomethingwith(*ptrb);
> }
> 
> legal), but dereferencing ptr is not.
> 
> > Please, take a look at a paragraph from K&R, stating that this method
> > doesn't work on "multi-tasking machines". Given K&R was published in
> > 1999, I wonder if that statement still holds.
> 
> It isn't K&R. K&R wasn't published in 1999, but in 1978 (1st edition) 
> and 1988 (2nd edition). And it doesn't contain broken advice such as 
> that which you quote.
> 
> > QUOTE:
> > char arrayname[5];
> > char *ptr;
> > for (ptr = arrayname; ptr <= arrayname+4; ptr++)
> > {
> > *ptr = 0;
> > }
> > The code above sets the array arrayname to zero.
> 
> No, it sets all elements of that array to 0, as does the far superior:
> 
> char arrayname[5] = {0};
> 
> > This method of getting
> > at array data is not recommended by this author except in very simple
> > computer environments. If a program is running on a normal microcomputer,
> > then there should be few problems with this alternative method of handling
> > arrays. On the hand, if the microcomputer is multi-tasking, or the program
> > is running on a larger system which has a limited manager, then memory
> > ceases to be something which can be thought of as a sequence of boxes
> > standing next to one another. A multi-tasking system shares memory with
> > Questions 175
> > other programs and it takes what it can find, where it can find it. The upshot
> > of this is that it is not possible to guarantee that arrays will be stored in one
> > simple string of memory locations: it might be scattered around in different
> > places.
> 
> At this point, you can safely discard the book. I suggest investing in 
> K&R instead. The 2nd edition is the one you want. I don't know what 
> you're smoking, but it isn't K&R.
> 
> > So
> > ptr = arrayname + 5;
> > might not be a pointer to the fifth character in a character array.
> 
> Indeed. It will be the sixth. Count them:
> 
> arrayname + 0 = pointer to the first element (element 0)
> arrayname + 1 = pointer to the second element (element 1)
> arrayname + 2 = pointer to the third element (element 2)
> arrayname + 3 = pointer to the fourth element (element 3)
> arrayname + 4 = pointer to the fifth element (element 4)
> arrayname + 5 = pointer to the sixth element (element 5)
> 
> > This could
> > be found instead using the '&' operator. A pointer to the fifth element can
> > be reliably found with:
> > ptr = &(arrayname[5]);
> > Be warned!
> 
> Be warned that the book is teaching you nonsense.
That's what has caused troubles to me. I also thought so. 
And actually reading it made me extremely thankful to Kochan version,
highly chastised here too ))) 

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

#76281

Alla _ <modelling.data@gmail.com> writes:

> On Tuesday, November 17, 2015 at 10:31:41 PM UTC+4, Richard Heathfield wrote:
>> On 17/11/15 16:49, Alla _ wrote:
<snip>
>> > QUOTE:
>> > char arrayname[5];
>> > char *ptr;
>> > for (ptr = arrayname; ptr <= arrayname+4; ptr++)
>> > {
>> > *ptr = 0;
>> > }
<snip>
>> > This method of getting at array data is not recommended by this
>> > author except in very simple computer environments. If a program is
>> > running on a normal microcomputer, then there should be few
>> > problems with this alternative method of handling arrays. On the
>> > hand, if the microcomputer is multi-tasking, or the program is
>> > running on a larger system which has a limited manager, then memory
>> > ceases to be something which can be thought of as a sequence of
>> > boxes standing next to one another. A multi-tasking system shares
>> > memory with other programs and it takes what it can find, where it
>> > can find it. The upshot of this is that it is not possible to
>> > guarantee that arrays will be stored in one simple string of memory
>> > locations: it might be scattered around in different places.
<snip>
>> Be warned that the book is teaching you nonsense.
> That's what has caused troubles to me. I also thought so.

But what book is it?  The quote is so wrong that I'd like to know, just
in case anyone else needs to warned off using it.

> And actually reading it made me extremely thankful to Kochan version,
> highly chastised here too )))

Yes, but the latest book seems to be very much worse.

-- 
Ben.

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

#76279

On Tue, 17 Nov 2015 08:49:29 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:

>int numbers[8];
>int *ptr;
>
>ptr = numbers + 8; // to point at a value stored at numbers[8]
>

If you are seeing code that looks like this without an caveats then
you should discard it immediately. The author is either being tricky
or he doesn't know what he is doing.

There are 8 elements in the numbers array, 0 through 7. Pointing to a
ninth element is an error.

>Please, take a look at a paragraph from K&R, stating that this method
>doesn't work on "multi-tasking machines". Given K&R was published in
>1999, I wonder if that statement still holds.

K&R, the first edition of "The C Programming Language" ISBN
0-13-110163-3, was published in 1978. K&R2, the second edition of "The
C Programming Language", ISBN 0-13-110362-8, was published in 1988.
There were no new revised editions published since then.

If you are using
http://www.iu.hio.no/~mark/CTutorial/CTutorial.html#Arrays
as a reference it is good you are questioning it.

It is NOT K&R or K&R2 and it should not claim to be K&R version
ANYTHING!

This document uses examples that are not modern C and uses a rather
poor style and represent "old" C as it was written in K&R and K&R2 but
isn't used , example:

main ()

 { int a;
   float x,y,z;

 /* statements */

 }


Modern C:

int main (void) { 
    int a;
    float x,y,z;

 /* statements */

}


OR

int main (void) 
{
    int a;
    float x,y,z;

    /* statements */

}

Mr. Burgess should have stated:
C Programming Tutorial (Using K&R C or ANSI C 1988)
in his title.

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

#76292

On 11/17/2015 02:15 PM, Geoff wrote:
> On Tue, 17 Nov 2015 08:49:29 -0800 (PST), Alla _
> <modelling.data@gmail.com> wrote:
> 
>> int numbers[8];
>> int *ptr;
>>
>> ptr = numbers + 8; // to point at a value stored at numbers[8]
>>
> 
> If you are seeing code that looks like this without an caveats then
> you should discard it immediately. The author is either being tricky
> or he doesn't know what he is doing.

The comment is wrong and misleading, but the code is fine.

> There are 8 elements in the numbers array, 0 through 7. Pointing to a
> ninth element is an error.

No, it is not. Pointing one past the end of an array is explicitly
permitted by the standard (though a strict reading of 6.5.6p8 justifies
the unintended conclusion that it can only be accessed by writing
(numbers+7)+1).
-- 
James Kuyper

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

#76323

Geoff <geoff@invalid.invalid> writes:
[...]
> There are 8 elements in the numbers array, 0 through 7. Pointing to a
> ninth element is an error.

As discussed previously, constructing the pointer is not an error, but
dereferencing it is.

[...]
> Mr. Burgess should have stated:
> C Programming Tutorial (Using K&R C or ANSI C 1988)
> in his title.

The phrase "K&R C" usually refers to pre-ANSI C as described in K&R1;
the most prominent difference from ANSI C is the lack of prototypes.
I haven't looked at the tuturial yet, but something written in 1999
doesn't use prototypes, that's one more strike against 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]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web