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 3 of 3 — ← Prev page 1 2 [3]

#76330

On Tuesday, November 17, 2015 at 5:09:50 PM UTC-6, Keith Thompson wrote:
> As discussed previously, constructing the pointer is not an error, but
> dereferencing it is.

Doing anything with a pointer that is not null, does not identify an object,
and does not immediately follow the end of an object, invokes Undefined
Behavior.  Thus, while the expression (int*)0x23456789 would not invoke
Undefined Behavior in and of itself, the statement "int *p=(int*)0x23456789;
may do so on a platform where integers are required to be word-aligned.  I'm
not really sure what is gained by saying that code can construct a pointer
from an arbitrary "int" without invoking UB, but only if it never tries to
use the pointer for anything, but that seems to be what the Standard says.

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

#76360

On Tuesday, November 17, 2015 at 11:42:06 PM UTC, supe...@casperkitty.com wrote:

> Doing anything with a pointer that is not null, does not identify an object,
> and does not immediately follow the end of an object, invokes Undefined
> Behavior.  Thus, while the expression (int*)0x23456789 would not invoke
> Undefined Behavior in and of itself, the statement "int *p=(int*)0x23456789;
> may do so on a platform where integers are required to be word-aligned.  I'm
> not really sure what is gained by saying that code can construct a pointer
> from an arbitrary "int" without invoking UB, but only if it never tries to
> use the pointer for anything, but that seems to be what the Standard says.
>
I think this is OK.

unsigned char *screenbuffer = onplatform1 ? 0x12345678 : 0x0;

if 0x12345678 traps if we're not on platform1 screenbuffer is
null.

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

#76367

On Tuesday, November 17, 2015 at 11:28:43 PM UTC-6, Malcolm McLean wrote:
> if 0x12345678 traps if we're not on platform1 screenbuffer is
> null.

Loading a trap representation into a non-char pointer won't generally cause
an immediate trap, but may cause unexpected behavior down the line.  For
example, given:

    void copy_ints(int *dest, int *src)
    {
      memcpy(dest, src, sizeof int);
    }
    union {
      int ints[4];
      char chars[sizeof (int)*4];
    } funny;
    void boom(void)
    {
      char *p = funny.chars+1+sizeof (int);
      int *ip = (int*)p;
      funny.ints[0] = 1234;
      copy_ints(ip, funny.ints); 
    }

It would be perfectly legitimate to use memcpy with *p and funny.ints as
arguments even though *p is not aligned as an integer, but because
copy_ints accepts two int* as parameters, the call to memcpy may assume
that it's receiving two int-aligned pointers.  As a consequence, that call
may fail if given a non-aligned pointer even though it normally wouldn't
care.

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

#76343

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

>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.
>
Then let me amend my statement to read:
There are 8 elements in the numbers array, 0 through 7. Pointing to a
ninth element with the intent of doing anything with the contents is
an error. The only thing that pointer is good for is --ptr.


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

Then you'll love the implicit int scattered throughout the tutorial.

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

#76344

On 11/17/2015 08:18 PM, Geoff wrote:
> On Tue, 17 Nov 2015 15:09:41 -0800, Keith Thompson <kst-u@mib.org>
> wrote:
> 
>> 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.
>>
> Then let me amend my statement to read:
> There are 8 elements in the numbers array, 0 through 7. Pointing to a
> ninth element with the intent of doing anything with the contents is
> an error. The only thing that pointer is good for is --ptr.

No, such a pointer can also be compared for relative order with another
pointer into or one past the end of the same array. Testing for relative
order is in fact one of the most common uses of such a pointer:

    for(int *p = array; p < array+num_elements; p++)

It can also be tested for equality with any other valid pointer. Note
the a pointer one past the end of one array is allowed to compare equal
to "a pointer to the start of a different array object that happens to
immediately follow the first array object in the address space." (6.5.9p6).
-- 
James Kuyper

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

#76380

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

If it is original, then it is about some theoretical implementation of C
that never has actually been created...

On another note, you *can* create your own array-types where elements 
aren't continuous:

OwnElem *p1= OwnAccess (OwnArray, 1);
OwnElem *p2= OwnAccess (OwnArray, 2);

p2 might or might not be p1+1

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

#76399

Lőrinczy Zsigmond <zsiga@nospam.for.me> writes:
>> 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!
>
> If it is original, then it is about some theoretical implementation of C
> that never has actually been created...

It's not about any conforming implementation of C.  It's simply about
the author's misunderstanding.

> On another note, you *can* create your own array-types where elements 
> aren't continuous:
>
> OwnElem *p1= OwnAccess (OwnArray, 1);
> OwnElem *p2= OwnAccess (OwnArray, 2);
>
> p2 might or might not be p1+1

That's not an array type, though it might have some array-like properties.

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

#77074

On Tuesday, 17 November 2015 16:49:38 UTC, Alla _  wrote:

<snip>

> 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

Surely that doesn't appear in K&R? (I don't have a copy to hand).

Both Brian and Dennis were good writers - I doubt that they (nor their
publisher's proof-readers) would have allowed the phrase "on the hand"
to have slipped through into the final publication.  Nor would they have
made the glaring error of referring to 'arrayname + 5' and '&(arrayname[5])'
as 'the fifth character' and 'the fifth element'.  And they are plural -
the phrase "this author" would not appear in any joint work of theirs.

That quoted text appears to come from this document:

    http://markburgess.org/CTutorial/C-Tut-4.02.pdf

rather than from K&R.

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

#77114

guinness.tony@gmail.com writes:
> On Tuesday, 17 November 2015 16:49:38 UTC, Alla _  wrote:
>
> <snip>
>
>> 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:
[SNIP]
>> Be warned!
>> END OF QUOTE
>
> Surely that doesn't appear in K&R? (I don't have a copy to hand).
>
> Both Brian and Dennis were good writers - I doubt that they (nor their
> publisher's proof-readers) would have allowed the phrase "on the hand"
> to have slipped through into the final publication.  Nor would they have
> made the glaring error of referring to 'arrayname + 5' and '&(arrayname[5])'
> as 'the fifth character' and 'the fifth element'.  And they are plural -
> the phrase "this author" would not appear in any joint work of theirs.
>
> That quoted text appears to come from this document:
>
>     http://markburgess.org/CTutorial/C-Tut-4.02.pdf
>
> rather than from K&R.

Yes, we established the source a week ago in this thread.

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

#77088

On Tuesday, November 17, 2015 at 10:49:38 AM UTC-6, 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

On any modern OS with virtual memory, this shouldn't be a problem. Yes,
it is possible (AFAIK) that arrays may be split across page boundaries;
from your point of view, though, the array elements will *appear* to be 
contiguous, and I can't think of any circumstance (under a working virtual memory system) where `a + 5` and `&a[5]` would give you different results.  

C's not *that* close to the machine.  

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

#77115

John Bode <jfbode1029@gmail.com> writes:
> On Tuesday, November 17, 2015 at 10:49:38 AM UTC-6, Alla _ wrote:
[...]
>> 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
>
> On any modern OS with virtual memory, this shouldn't be a problem.

On any conforming C implementation, this is absolutely guaranteed
not to be a problem.

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

#77098

On Tuesday, November 17, 2015 at 10:49:38 AM UTC-6, 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

And, as others have been mentioning, this passage does not come from K&R
(that is, "The C Programming Language" by Kernighan and Ritchie), but from
a tutorial written by someone who *thinks* he understands C.  

Honestly, after skimming through this tutorial, I think you should junk
it in favor of something newer.  It uses a very out-of-date version of the
language, and based on the passage quoted and some things I've seen based
on a quick skim of the sample code, I don't trust the author's knowledge
about C.  

My go-to desktop reference for C has been Harbison & Steele's
"C: A Reference Manual" since the late 1980s.  It's currently in its 5th
edition, covering the changes introduced in C99:

http://careferencemanual.com/

I've also heard good things about King's "C Programming: A Modern Approach",
although I don't have any personal experience with it:

http://www.amazon.com/Programming-Modern-Approach-2nd-Edition/dp/0393979504

K&R's "The C Programming Language", 2nd edition (a.k.a The New Testament)
only covers up to the 1989 standard, but it's going to be better than just
about any online tutorial.  

I've yet to see an online C tutorial or website that I thought was any good.

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

#77162

> 
> My go-to desktop reference for C has been Harbison & Steele's
> "C: A Reference Manual" since the late 1980s.  It's currently in its 5th
> edition, covering the changes introduced in C99:
> 
> http://careferencemanual.com/
> 
> I've also heard good things about King's "C Programming: A Modern Approach",
> although I don't have any personal experience with it:
> 
> http://www.amazon.com/Programming-Modern-Approach-2nd-Edition/dp/0393979504
> 
> 
> I've yet to see an online C tutorial or website that I thought was any good.

Thank you very much for these books. If you once see truly good online
tutorial, please, share ) I can't do any judgements myself yet, therefore
I heed to every advice from professionals.

[toc] | [prev] | [standalone]

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

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

csiph-web