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 1 of 3  [1] 2 3  Next page →

#76249 — Issue on assigning address to pointers

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]

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.

QUOTE:
char arrayname[5];
char *ptr;
for (ptr = arrayname; ptr <= arrayname+4; ptr++)
{
*ptr = 0;
}
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. 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. 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

[toc] | [next] | [standalone]

#76252

On 11/17/2015 11:49 AM, 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]
> 
> 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.
> 
> QUOTE:
> char arrayname[5];
> char *ptr;
> for (ptr = arrayname; ptr <= arrayname+4; ptr++)
> {
> *ptr = 0;
> }
> 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. 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. 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

Will all due respect to K&R, I cannot agree with the advice given here.
Shared memory is certainly a problem that sometimes needs to be worried
about, and that loop could be dangerous if the array was shared.
However, on a true multi-tasking system, sharing memory with another
process is never something that happens by accident. And it's precisely
the more primitive operating systems where it's relatively easy to share
memory; in more modern systems there's no danger of sharing memory with
another process unless you explicitly call an system function to share
the memory. The dangerous code that more primitive systems allow you to
execute simply causes your program to abort with a segmentation
violation, which is much safer overall.

Equating "modern" with "not primitive" isn't quite right. A lot of
modern C programming is for embedded systems, most of which have
relatively primitive operating systems.
-- 
James Kuyper

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

#76254

On 17/11/15 17:36, James Kuyper wrote:
> On 11/17/2015 11:49 AM, Alla _ wrote:

<snip>

>> 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. 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
>
> Will all due respect to K&R, I cannot agree with the advice given here.

With even more than all due respect to K&R, I cannot recognise either 
the above text or the previous "game of life" example as being from K&R. 
Could Alla provide a page reference for both of these, and explain what 
she meant by her claim that "K&R was published in 1999"? If there was a 
third edition of K&R published in that year, I'd have thought it would 
have attracted sufficient attention from the C community that more of us 
would have heard of it.

<snip>

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

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

#76265

On Tuesday, November 17, 2015 at 9:47:45 PM UTC+4, Richard Heathfield wrote:
> On 17/11/15 17:36, James Kuyper wrote:
> > On 11/17/2015 11:49 AM, Alla _ wrote:
> 
> <snip>
> 
> >> 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. 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
> >
> > Will all due respect to K&R, I cannot agree with the advice given here.
> 
> With even more than all due respect to K&R, I cannot recognise either 
> the above text or the previous "game of life" example as being from K&R. 
> Could Alla provide a page reference for both of these, and explain what 
> she meant by her claim that "K&R was published in 1999"? If there was a 
> third edition of K&R published in that year, I'd have thought it would 
> have attracted sufficient attention from the C community that more of us 
> would have heard of it.
> 
> <snip>
> 
> -- 
> Richard Heathfield
> Email: rjh at cpax dot org dot uk
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line 4 vacant - apply within

Have I deduced correctly that I am reading a wrong K&R version? ))) 
Well.... 
C Programming Tutorial
4th Edition (K&R version)
Mark Burgess
Faculty of Engineering, Oslo College
1999

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

#76287

Alla _ <modelling.data@gmail.com> writes:
[...]
> Have I deduced correctly that I am reading a wrong K&R version? ))) 
> Well.... 
> C Programming Tutorial
> 4th Edition (K&R version)
> Mark Burgess
> Faculty of Engineering, Oslo College
> 1999

You are not reading *any* K&R version.  K&R refers to "The C Programming
Language", by Kernighan & Ritchie.  I don't know what the author of that
tutorial means by "K&R version".  The language described by K&R1,
published in 1978, is often referred to as "K&R C"; I don't know why a
1999 tutorial would cover that obsolete version of the language.

The passage you quoted is wrong.  Based on that, I suggest finding a
better tutorial.  The comp.lang.c FAQ <http://www.c-faq.com/> lists some
decent books; others here can offer more up-to-date advice.

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

#76289

On 11/17/2015 01:34 PM, Alla _ wrote:
> On Tuesday, November 17, 2015 at 9:47:45 PM UTC+4, Richard Heathfield wrote:
...
>> With even more than all due respect to K&R, I cannot recognise either 
>> the above text or the previous "game of life" example as being from K&R. 
>> Could Alla provide a page reference for both of these, and explain what 
>> she meant by her claim that "K&R was published in 1999"? If there was a 
>> third edition of K&R published in that year, I'd have thought it would 
>> have attracted sufficient attention from the C community that more of us 
>> would have heard of it.
>>
>> <snip>
>>
>> -- 
>> Richard Heathfield
>> Email: rjh at cpax dot org dot uk
>> "Usenet is a strange place" - dmr 29 July 1999
>> Sig line 4 vacant - apply within
> 
> Have I deduced correctly that I am reading a wrong K&R version? ))) 
> Well.... 
> C Programming Tutorial
> 4th Edition (K&R version)
> Mark Burgess
> Faculty of Engineering, Oslo College
> 1999
> 

The term "K&R", when used in a C context, is very specifically a
reference to either a particular book titled "The C Programming
Language", or the version of C described by the first edition of that
book. K&R refers to it's authors, Brian W. Kernighan and Dennis M.
Ritchie. That book has only ever had two editions, the first of which
came out in 1978, and the second of which was updated in 1988 to better
match the new C standard that had not yet been completed when it was
published. The second edition has the ISBN 978-0131103627.

The use of "K&R" in the description of the book you're referring to
identifies which version of C it describes. That does not make the book
itself "K&R". It has the wrong title, the wrong author, and the wrong
edition number and the wrong publication date to be "K&R". Amazon.com
doesn't sell any book matching your description. The closest it gets is
"The Gnu C Programming Tutorial".
-- 
James Kuyper

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

#76264

On Tuesday, November 17, 2015 at 9:36:57 PM UTC+4, James Kuyper wrote:
> On 11/17/2015 11:49 AM, 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]
> > 
> > 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.
> > 
> > QUOTE:
> > char arrayname[5];
> > char *ptr;
> > for (ptr = arrayname; ptr <= arrayname+4; ptr++)
> > {
> > *ptr = 0;
> > }
> > 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. 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. 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
> 
> Will all due respect to K&R, I cannot agree with the advice given here.
> Shared memory is certainly a problem that sometimes needs to be worried
> about, and that loop could be dangerous if the array was shared.
> However, on a true multi-tasking system, sharing memory with another
> process is never something that happens by accident. And it's precisely
> the more primitive operating systems where it's relatively easy to share
> memory; in more modern systems there's no danger of sharing memory with
> another process unless you explicitly call an system function to share
> the memory. The dangerous code that more primitive systems allow you to
> execute simply causes your program to abort with a segmentation
> violation, which is much safer overall.
> 
> Equating "modern" with "not primitive" isn't quite right. A lot of
> modern C programming is for embedded systems, most of which have
> relatively primitive operating systems.
> -- 
> James Kuyper

Thank you!

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

#76253

Alla _ <modelling.data@gmail.com> writes:
> 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.
>
> QUOTE:
> char arrayname[5];
> char *ptr;
> for (ptr = arrayname; ptr <= arrayname+4; ptr++)
> {
> *ptr = 0;
> }
> 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. 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. 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

That code is perfectly safe as far as I can tell.

I cannot find that passage in K&R2 (I have the Kindle edition and I
searched for several words in the quoted section), nor do I see anything
relevant in the official errata.  Are you *sure* that's from (a
legitimate copy of) K&R2?  Can you cite the section number?

BTW, in your example, ptr points past the end of the array.  That's
legal, but the pointer may not be dereferenced.

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

#76255

On Tue, 17 Nov 2015 09:41:41 -0800, Keith Thompson <kst-u@mib.org>
wrote:

>I cannot find that passage in K&R2 (I have the Kindle edition and I
>searched for several words in the quoted section), nor do I see anything
>relevant in the official errata.  Are you *sure* that's from (a
>legitimate copy of) K&R2?  Can you cite the section number?

It appears to be some kind of book manuscript by one Mark Burgess that
bears at the top the following text.

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 

Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies. 

Two sites were immediately found:

https://students.cs.byu.edu/~cs224ta/references/Code%20Composer%20Studio/c/CTutorial.php
http://www.iu.hio.no/~mark/CTutorial/CTutorial.html#Arrays%20and%20Pointers

I don't know by what rights he can say "K&R version 4".

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

#76291

Geoff <geoff@invalid.invalid> wrote:
> On Tue, 17 Nov 2015 09:41:41 -0800, Keith Thompson <kst-u@mib.org>
> wrote:
 
>>I cannot find that passage in K&R2 (I have the Kindle edition and I
>>searched for several words in the quoted section), nor do I see anything
>>relevant in the official errata.  Are you *sure* that's from (a
>>legitimate copy of) K&R2?  Can you cite the section number?
 
> It appears to be some kind of book manuscript by one Mark Burgess that
> bears at the top the following text.
 
> 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. 

(snip)
> Two sites were immediately found:
 
> https://students.cs.byu.edu/~cs224ta/references/Code%20Composer%20Studio/c/CTutorial.php
> http://www.iu.hio.no/~mark/CTutorial/CTutorial.html#Arrays%20and%20Pointers
 
> I don't know by what rights he can say "K&R version 4".

At some point, we still talk about ANSI C and K&R C. 

Seems that is his tutorial for K&R C, maybe somewhere else is
his tutorial for ANSI C, which should say ANSI version at the top.

So, version 4 of his K&R C tutorial, not the tutorial for K&R 
version 4.

-- glen

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

#76295

On Tue, 17 Nov 2015 20:31:20 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>Geoff <geoff@invalid.invalid> wrote:
>> On Tue, 17 Nov 2015 09:41:41 -0800, Keith Thompson <kst-u@mib.org>
>> wrote:
> 
>>>I cannot find that passage in K&R2 (I have the Kindle edition and I
>>>searched for several words in the quoted section), nor do I see anything
>>>relevant in the official errata.  Are you *sure* that's from (a
>>>legitimate copy of) K&R2?  Can you cite the section number?
> 
>> It appears to be some kind of book manuscript by one Mark Burgess that
>> bears at the top the following text.
> 
>> 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. 
>
>(snip)
>> Two sites were immediately found:
> 
>> https://students.cs.byu.edu/~cs224ta/references/Code%20Composer%20Studio/c/CTutorial.php
>> http://www.iu.hio.no/~mark/CTutorial/CTutorial.html#Arrays%20and%20Pointers
> 
>> I don't know by what rights he can say "K&R version 4".
>
>At some point, we still talk about ANSI C and K&R C. 
>
>Seems that is his tutorial for K&R C, maybe somewhere else is
>his tutorial for ANSI C, which should say ANSI version at the top.
>
>So, version 4 of his K&R C tutorial, not the tutorial for K&R 
>version 4.
>

I looked up Mark Burgess and it led me to his personal home page.
http://markburgess.org/index.html

Looking at his publications on C, he's written three C tutorials, all
of which are out of print and he's publishing them on web himself. Two
of them are on K&R C and are both labeled "4th Edition", the third is
on GNU C and is version 4.1. This last one "The GNU C Programming
Tutorial" is Copyright 2002 yet it still uses old C in that is defines
main thusly:

main()
{
   /* do nothing */
}

All of his publications are very dated.

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

#76263

On Tuesday, November 17, 2015 at 9:41:50 PM UTC+4, Keith Thompson wrote:
> Alla _ <modelling.data@gmail.com> writes:
> > 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.
> >
> > QUOTE:
> > char arrayname[5];
> > char *ptr;
> > for (ptr = arrayname; ptr <= arrayname+4; ptr++)
> > {
> > *ptr = 0;
> > }
> > 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. 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. 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
> 
> That code is perfectly safe as far as I can tell.
> 
> I cannot find that passage in K&R2 (I have the Kindle edition and I
> searched for several words in the quoted section), nor do I see anything
> relevant in the official errata.  Are you *sure* that's from (a
> legitimate copy of) K&R2?  Can you cite the section number?
> 
> BTW, in your example, ptr points past the end of the array.  That's
> legal, but the pointer may not be dereferenced.
> 
That's what I also thought. 
Here is a more extensive quote from Chapter 18th (it K&R 4th edition by Mark 
Burgess, 1999):

Note that, if there are not enough elements in the curly braces to account
for every single element in an array, the remaining elements will be filled out
with zeros. Static variables are always guaranteed to be initialized to zero
anyway, whereas auto or local variables are guaranteed to be garbage: this is
because static storage is created by the compiler in the body of a program,
whereas auto or local storage is created at run time.
18.10 Arrays and Pointers
The information about how arrays are stored was not included just for in-
terest. There is another way of looking at arrays which follows the BCPL
idea of an array as simply a block of memory. An array can be accessed with
pointers as well as with [] square brackets.
The name of an array variable, standing alone, is actually a pointer to
the first element in the array.
For example: if an array is declared
float numbers[34];
then numbers is a pointer to the first floating point number in the array;
numbers is a pointer in its own right. (In this case it is type 'pointer to
float'.) So the first element of the array could be accessed by writing:
numbers[0] = 22.3;
or by writing
*numbers = 22.3;
For character arrays, which are dealt with in some depth in chapter 20, this
gives an alternative way of getting at the elements in the array.
char arrayname[5];
char *ptr;
for (ptr = arrayname; ptr <= arrayname+4; ptr++)
{
*ptr = 0;
}
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. A multi-tasking system shares memory withother 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. 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.

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

#76269

On 17/11/15 18:32, Alla _ wrote:

<snip>

> Here is a more extensive quote from Chapter 18th (it K&R 4th edition by Mark
> Burgess, 1999):

K = Brian W Kernighan (a world-famous computer scientist).
R = Dennis M Ritchie (a world-famous computer scientist, and the 
designer of the C programming language).

Mark Burgess = Someone who not only doesn't know C as well as he thinks 
he does, but also has adopted a name for his tutorial that he knows 
perfectly well will mislead people into accepting it as authoritative.

>
> Note that, if there are not enough elements in the curly braces to account
> for every single element in an array, the remaining elements will be filled out
> with zeros.

See? He's not always wrong. (For "zeros", read "default static 
initialisers, which are 0 for integers, 0.0 for doubles, a null pointer 
value for pointers, etc".)

> Static variables are always guaranteed to be initialized to zero
> anyway,

Correct again.

> whereas auto or local variables are guaranteed to be garbage:

No such guarantee is provided. Rather, uninitialised objects have an 
indeterminate value (i.e. you can't tell what it is) until such time as 
a value is assigned to them. C does not define what will happen if your 
program reads an indeterminate value.

> this is
> because static storage is created by the compiler in the body of a program,
> whereas auto or local storage is created at run time.

I would prefer to say that it's because the Standard guarantees the 
default static initialisation behaviour, but not that of automatic objects.

> 18.10 Arrays and Pointers
> The information about how arrays are stored was not included just for in-
> terest. There is another way of looking at arrays which follows the BCPL
> idea of an array as simply a block of memory. An array can be accessed with
> pointers as well as with [] square brackets.
> The name of an array variable, standing alone, is actually a pointer to
> the first element in the array.

Not exactly. Rather, *in a value context*, it 'decays' into such a pointer.

Consider this code:

#include <stdio.h>

int main(void)
{
   float *myptr = NULL;
   float myarray[34] = {0};

   printf("Mark Burgess is ");

   if(sizeof myptr == sizeof myarray)
   {
     puts("RIGHT!");
   }
   else
   {
     puts("WRONG!");
   }
   return 0;
}

> For example: if an array is declared
> float numbers[34];
> then numbers is a pointer to the first floating point number in the array;

No, it's an array.

> numbers is a pointer in its own right.

No, it's an array.

> (In this case it is type 'pointer to
> float'.) So the first element of the array could be accessed by writing:
> numbers[0] = 22.3;

True enough. In this situation, numbers is being used in a value 
context, and so for this expression it is treated *as if* it were a 
pointer to the first element in the array. Nevertheless, numbers is 
still an array, as demonstrated by the sizeof example above.

> or by writing
> *numbers = 22.3;

Again, this is because numbers is being used in a value context.

Your extended quote goes on to cite nonsense that I've already commented 
on earlier, so I'll snip it.

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

#76275

On Tuesday, November 17, 2015 at 10:45:31 PM UTC+4, Richard Heathfield wrote:
> On 17/11/15 18:32, Alla _ wrote:
> 
> <snip>
> 
> > Here is a more extensive quote from Chapter 18th (it K&R 4th edition by Mark
> > Burgess, 1999):
> 
> K = Brian W Kernighan (a world-famous computer scientist).
> R = Dennis M Ritchie (a world-famous computer scientist, and the 
> designer of the C programming language).
>
Well, now I have one more intellectual cell filled with knowledge ) 
Thank you. I truly didn't know who these people are )

That guy Mark is rather creative and bold to use K&R abbreviation )

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

#76321

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 17/11/15 18:32, Alla _ wrote:
[...]
>> whereas auto or local variables are guaranteed to be garbage:
>
> No such guarantee is provided. Rather, uninitialised objects have an 
> indeterminate value (i.e. you can't tell what it is) until such time as 
> a value is assigned to them. C does not define what will happen if your 
> program reads an indeterminate value.
[...]

It depends on what you mean by "garbage", I suppose.  One reasonable
interpretation is that "guaranteed to be garbage" means that there's no
guarantee at all.  There's similar wording in K&R2, though not using the
word "guaranteed".  (The phrase "guaranteed to be garbage" sounds
familiar; it might be in K&R1.)

There are also cases where accessing a "garbage" value has undefined
behavior, so it goes beyond just having some arbitrary value.

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

#76600

Keith Thompson wrote:
> Richard Heathfield writes:
> > Alla _ wrote:
> >> whereas auto or local variables are guaranteed to be garbage:
> >
> > No such guarantee is provided. Rather, uninitialised objects have an 
> > indeterminate value (i.e. you can't tell what it is) until such time as 
> > a value is assigned to them. C does not define what will happen if your 
> > program reads an indeterminate value.
> 
> It depends on what you mean by "garbage", I suppose.  One reasonable
> interpretation is that "guaranteed to be garbage" means that there's no
> guarantee at all.  There's similar wording in K&R2, though not using the
> word "guaranteed".  (The phrase "guaranteed to be garbage" sounds
> familiar; it might be in K&R1.)

It is. Appendix A, section 8.6: "... guaranteed to start off as garbage."

I have always thought that to be an unusual statement.

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

#76332

On Tuesday, November 17, 2015 at 12:45:31 PM UTC-6, Richard Heathfield wrote:
> On 17/11/15 18:32, Alla _ wrote:
> 
> <snip>
> 
> > Here is a more extensive quote from Chapter 18th (it K&R 4th edition by Mark
> > Burgess, 1999):
> 
> K = Brian W Kernighan (a world-famous computer scientist).
> R = Dennis M Ritchie (a world-famous computer scientist, and the 
> designer of the C programming language).
> 
> Mark Burgess = Someone who not only doesn't know C as well as he thinks 
> he does, but also has adopted a name for his tutorial that he knows 
> perfectly well will mislead people into accepting it as authoritative.
> 

With regards to "... that he knows perfectly well will mislead people into accepting it as authoritative", see post by 'glen herrmannsfeldt' that has a more lenient take on what the author might have meant.

- Anand

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

#76333

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

>On 17/11/15 18:32, Alla _ wrote:

<snip>

>> Note that, if there are not enough elements in the curly braces to account
>> for every single element in an array, the remaining elements will be filled out
>> with zeros.
>
>See? He's not always wrong. (For "zeros", read "default static 
>initialisers, which are 0 for integers, 0.0 for doubles, a null pointer 
>value for pointers, etc".)
>
>> Static variables are always guaranteed to be initialized to zero
>> anyway,
>
>Correct again.

Static variables without explicit initialization are guaranteed ...

Is there a difference between "guaranteed" and "always guaranteed"?

-- 
Remove del for email

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

#76347

On 17/11/15 23:53, Barry Schwarz wrote:
> On Tue, 17 Nov 2015 18:45:18 +0000, Richard Heathfield
> <rjh@cpax.org.uk> wrote:
>
<snip>
>>
>>> Static variables are always guaranteed to be initialized to zero
>>> anyway,
>>
>> Correct again.
>
> Static variables without explicit initialization are guaranteed ...

...er, quite. So, *nearly* correct, anyway. The brain is remarkably good 
at filling in the missing details of a picture and then not telling 
itself that it has done so.

> Is there a difference between "guaranteed" and "always guaranteed"?

I suppose that such a difference could be constructed if one felt 
strongly enough about it.

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

#76282

Alla _ <modelling.data@gmail.com> writes:
<snip>
> That's what I also thought. 
> Here is a more extensive quote from Chapter 18th (it [...] by Mark 
> Burgess, 1999):

Ah.  I see.  I've just asked for the name in another post, but I should
have finished the thread first.  No need to answer me.

<snip>
-- 
Ben.

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

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

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

csiph-web