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

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

Why C has Pointers.

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

Contents

  Why C has Pointers. curixinfotech <curixinfotech.54dl3z@no-mx.forums.yourdomain.com.au> - 2011-12-07 07:22 -0500
    Re: Why C has Pointers. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-12-07 04:35 -0800
    Re: Why C has Pointers. Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-07 07:58 -0500
      Re: Why C has Pointers. Mike Manilone <zhtx10@gmail.com> - 2011-12-07 13:15 +0000
        Re: Why C has Pointers. Bill Reid <hormelfree@gmail.com> - 2011-12-08 06:29 -0800
    Re: Why C has Pointers. Vincenzo Mercuri <vincenzo.mercuri@hotmail.it> - 2011-12-07 14:50 +0100
      Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-07 11:01 -0800
        Re: Why C has Pointers. Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2011-12-07 20:49 +0100
        Re: Why C has Pointers. Brian <nospam@nospam.com> - 2011-12-07 20:00 +0000
          Re: Why C has Pointers. James Kuyper <jameskuyper@verizon.net> - 2011-12-07 15:30 -0500
            Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-07 12:43 -0800
              Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-07 13:09 -0800
            Re: Why C has Pointers. Vincenzo Mercuri <vincenzo.mercuri@hotmail.it> - 2011-12-08 19:39 +0100
              Re: Why C has Pointers. James Kuyper <jameskuyper@verizon.net> - 2011-12-08 14:16 -0500
                Re: Why C has Pointers. Vincenzo Mercuri <vincenzo.mercuri@hotmail.it> - 2011-12-08 20:23 +0100
      Re: Why C has Pointers. Kaz Kylheku <kaz@kylheku.com> - 2011-12-07 20:48 +0000
        Re: Why C has Pointers. Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2011-12-07 22:07 +0100
        Re: Why C has Pointers. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-12-10 07:34 +0000
    Re: Why C has Pointers. August Karlstrom <fusionfile@gmail.com> - 2011-12-07 16:16 +0100
    Re: Why C has Pointers. Borax Man <rotflol2@hotmail.com> - 2011-12-08 18:32 +1100
      Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-08 00:20 -0800
        Re: Why C has Pointers. André Gillibert <MetaEntropy.removeThis@gmail.com> - 2011-12-08 13:44 +0100
          Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-09 05:04 -0800
            Re: Why C has Pointers. gazelle@shell.xmission.com (Kenny McCormack) - 2011-12-09 14:59 +0000
              Re: Why C has Pointers. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-12-09 20:19 -0800
              Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-10 07:36 -0800
    Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-08 00:12 -0800
    Re: Why C has Pointers. Cong Wang <xiyou.wangcong@gmail.com> - 2011-12-15 07:26 +0000
    Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-17 08:51 -0800
      Re: Why C has Pointers. Barry Schwarz <schwarzb@dqel.com> - 2011-12-17 10:10 -0800
        Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-17 14:28 -0600
          Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-17 15:00 -0600
          Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-17 13:55 -0800
            Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-17 18:27 -0600
              Re: Why C has Pointers. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-18 01:26 +0000
                Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-17 22:34 -0600
                  Re: Why C has Pointers. "Philip Lantz" <prl@canterey.us> - 2011-12-17 23:48 -0800
                    Re: Why C has Pointers. superpollo <superpollo@tznvy.pbz> - 2011-12-18 11:06 +0100
                  Re: Why C has Pointers. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-18 13:44 +0000
                  Re: Why C has Pointers. pete <pfiland@mindspring.com> - 2011-12-18 11:05 -0500
                  Re: Why C has Pointers. James Kuyper <jameskuyper@verizon.net> - 2011-12-18 11:50 -0500
                  Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-18 13:10 -0800
                    Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-27 16:03 -0600
                      Re: Why C has Pointers. Barry Schwarz <schwarzb@dqel.com> - 2011-12-27 14:40 -0800
                      Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-27 15:08 -0800
                        Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-27 20:09 -0600
                          Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-27 23:00 -0800
                          Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-28 02:53 -0800
                          Re: Why C has Pointers. James Kuyper <jameskuyper@verizon.net> - 2011-12-28 08:39 -0500
                      Re: Why C has Pointers. James Kuyper <jameskuyper@verizon.net> - 2011-12-27 18:14 -0500
                        Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-27 15:36 -0800
                          Re: Why C has Pointers. James Kuyper <jameskuyper@verizon.net> - 2011-12-27 18:53 -0500
                      Re: Why C has Pointers. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-28 13:20 +0000
                  Re: Why C has Pointers. John Bode <jfbode1029@gmail.com> - 2011-12-28 08:42 -0800
                Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-17 20:36 -0800
                  Re: Why C has Pointers. Seebs <usenet-nospam@seebs.net> - 2011-12-18 04:56 +0000
                    Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-17 21:37 -0800
                      Re: Why C has Pointers. Seebs <usenet-nospam@seebs.net> - 2011-12-18 05:42 +0000
                        Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-18 08:08 -0800
                          Re: Why C has Pointers. Robert Wessel <robertwessel2@yahoo.com> - 2011-12-18 10:36 -0600
                          Re: Why C has Pointers. Seebs <usenet-nospam@seebs.net> - 2011-12-18 18:50 +0000
                          Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-19 02:39 -0800
                          Re: Why C has Pointers. gordonb.1i27q@burditt.org (Gordon Burditt) - 2011-12-21 22:34 -0600
                        Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-19 07:56 -0800
                          Re: Why C has Pointers. John Tsiombikas <nuclear@member.fsf.org> - 2011-12-19 18:38 +0000
                            Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-19 13:47 -0800
                              Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-28 02:58 -0800
                                Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-28 03:21 -0800
              Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-18 13:07 -0800
                Re: Why C has Pointers. "io_x" <a@b.c.invalid> - 2011-12-19 04:02 +0100
          Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-17 15:35 -0800
            Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-17 18:41 -0600
          Re: Why C has Pointers. John Bode <jfbode1029@gmail.com> - 2011-12-19 05:14 -0800
        Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-18 09:50 -0800
        Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-09 15:48 -0800
          Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-10 00:21 -0800
            Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-10 01:03 -0800
      Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-17 11:45 -0800
        Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-17 15:18 -0800
        Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-19 14:10 -0800
          Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-20 10:46 -0800
    Re: Why C has Pointers. "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-12-17 19:15 +0100
      Re: Why C has Pointers. "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-12-17 19:19 +0100
        Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-19 02:48 -0800
    Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-18 11:05 -0800
      Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-19 02:48 -0800

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

#14692

On 12/17/2011 11:34 PM, ralph wrote:
...
> So for int arr[10];
> arr[5] is *(arr + (5 * sizeof(int)))

Other people have told you that this is wrong, and have cited the
relevant parts of the standard to prove it. If your compiler implements
a[i] as meaning anything other than *(a+i), it's not a conforming
implementation of C (or C++, or any of several other C-like languages).

However, a couple of casts would make it correct:

arr[5] == *(int*)((char*)arr + (5 * sizeof(int)));

When you understand precisely why the casts make a difference, you'll
have a much better understanding of C arrays and pointers than you
currently appear to have.

> byte arr[10];
> arr[5] is *(arr + (5 * sizeof(byte)))

You haven't provided a typedef for 'byte', but is seems likely, given
the name, that sizeof(byte) == 1. If that's true, than so is your
statement above. Otherwise, it's false.
-- 
James Kuyper

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

#14706

ralph <nt_consulting64@yahoo.net> writes:
> On Sun, 18 Dec 2011 01:26:59 +0000, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
[...]
>>It's not easy to explain the lower-level arithmetic without reference to
>>some particular machine.  For example, on a machine with, say, byte and
>>word addresses, you can't describe it as you have done.  By all means,
>>take a simple architecture and explain what a[0] means on one particular
>>system using addresses and size calculations, but you will also have to
>>explain, eventually, that arr[i] is, by definition, *(arr + i).
>>
>
> Sure it is because it ain't *(arr + i). It is ...

Yes, it is.  C99 6.5.2.1p2:

    The definition of the subscript operator [] is that E1[E2] is
    identical to (*((E1)+(E2))).

> *(arr + ( i * sizeof(datatype)))
>
> So for int arr[10];
> arr[5] is *(arr + (5 * sizeof(int)))
> byte arr[10];
> arr[5] is *(arr + (5 * sizeof(byte)))

You are using your own invented "+" operator that works in units of
byte, rather than the actual C "+" operator that works in units of the
size of the pointed-to type.  That's fine, but only if you explicitly
state that "+" doesn't mean what it means in C.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#15045

On Sun, 18 Dec 2011 13:10:27 -0800, Keith Thompson <kst-u@mib.org>
wrote:

>ralph <nt_consulting64@yahoo.net> writes:
>> On Sun, 18 Dec 2011 01:26:59 +0000, Ben Bacarisse
>> <ben.usenet@bsb.me.uk> wrote:
>[...]
>>>It's not easy to explain the lower-level arithmetic without reference to
>>>some particular machine.  For example, on a machine with, say, byte and
>>>word addresses, you can't describe it as you have done.  By all means,
>>>take a simple architecture and explain what a[0] means on one particular
>>>system using addresses and size calculations, but you will also have to
>>>explain, eventually, that arr[i] is, by definition, *(arr + i).
>>>
>>
>> Sure it is because it ain't *(arr + i). It is ...
>
>Yes, it is.  C99 6.5.2.1p2:
>
>    The definition of the subscript operator [] is that E1[E2] is
>    identical to (*((E1)+(E2))).
>
>> *(arr + ( i * sizeof(datatype)))
>>
>> So for int arr[10];
>> arr[5] is *(arr + (5 * sizeof(int)))
>> byte arr[10];
>> arr[5] is *(arr + (5 * sizeof(byte)))
>
>You are using your own invented "+" operator that works in units of
>byte, rather than the actual C "+" operator that works in units of the
>size of the pointed-to type.  That's fine, but only if you explicitly
>state that "+" doesn't mean what it means in C.

[So an 'actual' unit of "size of the pointed-to-type" doesn't have the
same meaning as an 'invented' unit of "sizeof(<declared>type))". If
you look closer you will will see there is not a single pointer in my
statement nor in the Standard - there ain't NO "pointed-to-type" and
that is the whole point. <bg>]

Sry delay. The holidays...

This reply will have to serve for all of you. <g>

When I mentioned this phenomena as an aid for new programmers, I used
the term "storage map equation" which I assumed everyone understood as
an implementation context. My post that prompted this response was
made quickly because I seriously thought Ben was teasing me. Bad
assumption. You guys are serious.

Well that is pretty much what you get when you assume. lol

The concepts behind ...

 datatype arr[i]  ~==  *(arr + ( i * sizeof(datatype))) 

... and understanding the difference between addresses and pointer
datatypes has served to untangle a ton of "pointer" questions. But
that's me, and my students, and it doesn't matter. ...

IF one is pitching something, and no one is catching, especially those
one definitely respects and believes to be quite competent (and not
assumed <g>) there is something fishy with the pitch. So I yield.
Consider item #9 deleted from my list.

Happy Holidays and Best Wishes for a Great New Year.

-ralph

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

#15048

On Tue, 27 Dec 2011 16:03:35 -0600, ralph <nt_consulting64@yahoo.net>
wrote:

snip

>[So an 'actual' unit of "size of the pointed-to-type" doesn't have the
>same meaning as an 'invented' unit of "sizeof(<declared>type))". If
>you look closer you will will see there is not a single pointer in my
>statement nor in the Standard - there ain't NO "pointed-to-type" and
>that is the whole point. <bg>]

A wonderfully absurd assertion since there are at least two sections
of the standard devoted to pointers (6.3.2.3 and 6.7.5.1) and the term
appears in more than a dozen other sections.

>
>Sry delay. The holidays...
>
>This reply will have to serve for all of you. <g>
>
>When I mentioned this phenomena as an aid for new programmers, I used
>the term "storage map equation" which I assumed everyone understood as
>an implementation context. My post that prompted this response was
>made quickly because I seriously thought Ben was teasing me. Bad
>assumption. You guys are serious.
>
>Well that is pretty much what you get when you assume. lol
>
>The concepts behind ...
>
> datatype arr[i]  ~==  *(arr + ( i * sizeof(datatype))) 

So your readers need only remember whether you are using or own
meaning for the symbols or the common meaning stated in the standard.
And of course you used a syntax nearly identical to C to help make
this unequivocally clear.

-- 
Remove del for email

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

#15053

ralph <nt_consulting64@yahoo.net> writes:
> On Sun, 18 Dec 2011 13:10:27 -0800, Keith Thompson <kst-u@mib.org>
> wrote:
>>ralph <nt_consulting64@yahoo.net> writes:
>>> On Sun, 18 Dec 2011 01:26:59 +0000, Ben Bacarisse
>>> <ben.usenet@bsb.me.uk> wrote:
>>[...]
>>>>It's not easy to explain the lower-level arithmetic without reference to
>>>>some particular machine.  For example, on a machine with, say, byte and
>>>>word addresses, you can't describe it as you have done.  By all means,
>>>>take a simple architecture and explain what a[0] means on one particular
>>>>system using addresses and size calculations, but you will also have to
>>>>explain, eventually, that arr[i] is, by definition, *(arr + i).
>>>>
>>>
>>> Sure it is because it ain't *(arr + i). It is ...
>>
>>Yes, it is.  C99 6.5.2.1p2:
>>
>>    The definition of the subscript operator [] is that E1[E2] is
>>    identical to (*((E1)+(E2))).
>>
>>> *(arr + ( i * sizeof(datatype)))
>>>
>>> So for int arr[10];
>>> arr[5] is *(arr + (5 * sizeof(int)))
>>> byte arr[10];
>>> arr[5] is *(arr + (5 * sizeof(byte)))
>>
>>You are using your own invented "+" operator that works in units of
>>byte, rather than the actual C "+" operator that works in units of the
>>size of the pointed-to type.  That's fine, but only if you explicitly
>>state that "+" doesn't mean what it means in C.
>
> [So an 'actual' unit of "size of the pointed-to-type" doesn't have the
> same meaning as an 'invented' unit of "sizeof(<declared>type))".

I don't understand what you mean by that statement.  The difference
I was pointing out was between your invented "+" operator, which
apparently operates in units of single bytes (thus the need to
explicitly scale it by sizeof(datatype)), vs. the actual C "+"
operator, which operates in terms of the size of the pointed-to type
(so explicit scaling would yield an incorrect result).

>                                                                  If
> you look closer you will will see there is not a single pointer in my
> statement nor in the Standard - there ain't NO "pointed-to-type" and
> that is the whole point. <bg>]

"arr" is an expression of array type.  In this context, it's implicitly
converted to a pointer to the array's first element.  That's one pointer
right there.

When you add an integer value to a pointer, the result is another
pointer.

The pointed-to type is the element type of "arr", which you refer to as
"datatype".

The expression is a syntactically valid C expression.  It uses
parentheses, names which presumably refer to C objects and type,
the unary and binary "*" operator, the "+" operator, and the
"sizeof" operator.  It would be unreasonable, particularly in the
context of this newsgroup or a C class, to assume that it's *not*
intended to be a C expression with C semantics.

> Sry delay. The holidays...
>
> This reply will have to serve for all of you. <g>
>
> When I mentioned this phenomena as an aid for new programmers, I used
> the term "storage map equation" which I assumed everyone understood as
> an implementation context. My post that prompted this response was
> made quickly because I seriously thought Ben was teasing me. Bad
> assumption. You guys are serious.
>
> Well that is pretty much what you get when you assume. lol
>
> The concepts behind ...
>
>  datatype arr[i]  ~==  *(arr + ( i * sizeof(datatype))) 
>
> ... and understanding the difference between addresses and pointer
> datatypes has served to untangle a ton of "pointer" questions. But
> that's me, and my students, and it doesn't matter. ...

The equation as you wrote it is probably easily understandable
*for someone who doesn't know how C pointer arithmetic works*.
That's what I find dangerous about it.  If you teach this before
you teach C pointer arithmetic, a student who goes back and looks
at this equation is likely to be confused, and/or may misunderstand
the actual rules for C pointer arithmetic when encountering them.

It's possible to express the concept you're presenting (which is
a perfectly valid concept) without violating or ignoring C rules.
You can do in pure C by adding casts to and from char*, but that's
probably too confusing.  Or perhaps you could define and use your
own special-purpose operators that don't look exactly like C's "+",
or you could describe it in English.

I'd actually be interested in seeing a good novice-friendly way of
doing that.

> IF one is pitching something, and no one is catching, especially those
> one definitely respects and believes to be quite competent (and not
> assumed <g>) there is something fishy with the pitch. So I yield.
> Consider item #9 deleted from my list.

I get the impression that you're yielding on this point because of the
number of people who disagree with you.  I'd prefer to think that you
understand the argument we're making.  (If you change your mind, we'll
*all* be right!)

Or maybe I'm just beating a dead horse.

> Happy Holidays and Best Wishes for a Great New Year.

Likewise.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#15069

On Tue, 27 Dec 2011 15:08:05 -0800, Keith Thompson <kst-u@mib.org>
wrote:


>
>I get the impression that you're yielding on this point because of the
>number of people who disagree with you.  I'd prefer to think that you
>understand the argument we're making.  (If you change your mind, we'll
>*all* be right!)
>
>Or maybe I'm just beating a dead horse.
>

For the moment yes, that is exactly what I'm (we're) doing. ha

I think I understand what you are trying to say, at least recognize
the "C-Legalese", but unable to distinguish the subtleties in
difference between what I'm saying and what you guys are saying.

[I mean, (among other things), as long as anyone refers to the "arr"
in an array declaration as a "pointer" when it is obviously a literal
constant - I'm likely to stay confused.]

I've always had trouble understanding code lawyers. C for me has been
mostly pragmatic, visual (yeah, I like to draw little memory boxes,
data sections, registers, and arrows <g>), and intuitive over the last
30 years. I know that we aren't that fundamentally different - since
we both likely write the same code. We just use different words to
describe what we wrote.

Well, I done just about everything else in C , have some time on my
hands, so perhaps it is time to really read the standard. That will
likely take a few days. (ok a few weeks, ... months? <g>) Then maybe
that "arr" will turn into a pointer. 

-ralph

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

#15075

ralph <nt_consulting64@yahoo.net> writes:
> On Tue, 27 Dec 2011 15:08:05 -0800, Keith Thompson <kst-u@mib.org>
> wrote:
>>I get the impression that you're yielding on this point because of the
>>number of people who disagree with you.  I'd prefer to think that you
>>understand the argument we're making.  (If you change your mind, we'll
>>*all* be right!)
>>
>>Or maybe I'm just beating a dead horse.
>
> For the moment yes, that is exactly what I'm (we're) doing. ha
>
> I think I understand what you are trying to say, at least recognize
> the "C-Legalese", but unable to distinguish the subtleties in
> difference between what I'm saying and what you guys are saying.

In the particular case we're talking about, the difference is that
you're using a kind of pointer arithmetic that quite simply is not the
way pointer arithmetic works in C.  Do you not understand that?

> [I mean, (among other things), as long as anyone refers to the "arr"
> in an array declaration as a "pointer" when it is obviously a literal
> constant - I'm likely to stay confused.]

Can you show a concrete example of C code that illustrates what you're
referring to here?  There are a number of things that

    the "arr" in an array declaration

could mean, and I honestly have no idea which one you're talking about.

> I've always had trouble understanding code lawyers. C for me has been
> mostly pragmatic, visual (yeah, I like to draw little memory boxes,
> data sections, registers, and arrows <g>), and intuitive over the last
> 30 years. I know that we aren't that fundamentally different - since
> we both likely write the same code. We just use different words to
> describe what we wrote.
>
> Well, I done just about everything else in C , have some time on my
> hands, so perhaps it is time to really read the standard. That will
> likely take a few days. (ok a few weeks, ... months? <g>) Then maybe
> that "arr" will turn into a pointer. 

I suggest reading section 6 of the comp.lang.c FAQ, <http://c-faq.com>.
It has the best explanation I've seen of the relationship between arrays
and pointers in C.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#15094

On Dec 28, 2:09 am, ralph <nt_consultin...@yahoo.net> wrote:
> On Tue, 27 Dec 2011 15:08:05 -0800, Keith Thompson <ks...@mib.org>

I think in your "equation" you're using '+' in the normal arithmetic
meaning. Which I don't think is a completly bad idea. But you *must*
be clear that normal arithmatic is *not* the same as C pointer
arithmatic.

> >I get the impression that you're yielding on this point because of the
> >number of people who disagree with you.  I'd prefer to think that you
> >understand the argument we're making.  (If you change your mind, we'll
> >*all* be right!)
>
> >Or maybe I'm just beating a dead horse.
>
> For the moment yes, that is exactly what I'm (we're) doing. ha
>
> I think I understand what you are trying to say, at least recognize
> the "C-Legalese", but unable to distinguish the subtleties in
> difference between what I'm saying and what you guys are saying.
>
> [I mean, (among other things), as long as anyone refers to the "arr"
> in an array declaration as a "pointer" when it is obviously a literal
> constant - I'm likely to stay confused.]

it isn't a pointer, constant or otherwise. I personnally find these
sort of "explanations" confusing. I have similar problems when people
tell me C++ references are "constant pointers".

> I've always had trouble understanding code lawyers.

programming languages  (usually) have formal definitions. To an extent
this depends how people think. I tend to prefer more formal
explanations, leavened with some solid concrete examples. I need to
see some sort of implementaion at some point, but once I've seen an
implementaion I don't need to have it there all the time. I have known
people who seemed to mentally translate everything into assembler. (or
worse! "it's all shift registers!"). I think it's better to ride a
little higher in the abstraction layers. But horses for courses.

> C for me has been
> mostly pragmatic, visual (yeah, I like to draw little memory boxes,
> data sections, registers, and arrows <g>),

I'd skip the data sections and registers. Way too chummy with the
implementation! I bet if you did Pascal you'd love those little
railway track diagrams that were fashionable to describe syntax.

> and intuitive over the last
> 30 years. I know that we aren't that fundamentally different - since
> we both likely write the same code. We just use different words to
> describe what we wrote.

I'm not so sure.

> Well, I done just about everything else in C , have some time on my
> hands, so perhaps it is time to really read the standard. That will
> likely take a few days. (ok a few weeks, ... months? <g>) Then maybe
> that "arr" will turn into a pointer.

days to read it. Much longer to understand. It's a formal document and
heavily cross-linked. There is little hand-holding. If the standard
says something it rarely says it twice. If you've read K&R you'll have
a flavour of the formallity. Expect the standard to be a step-up.

On the other hand the C standard is quite reasonable as these things
go. Do read the definitions near the beginning carefully. If you can
lay your hands on the Rationale for the ANSI 89 standard it give some
justifications for the decisions made and again is quite a good read.

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

#15113

On 12/27/2011 09:09 PM, ralph wrote:
> On Tue, 27 Dec 2011 15:08:05 -0800, Keith Thompson <kst-u@mib.org>
> wrote:
> 
> 
>>
>> I get the impression that you're yielding on this point because of the
>> number of people who disagree with you.  I'd prefer to think that you
>> understand the argument we're making.  (If you change your mind, we'll
>> *all* be right!)
>>
>> Or maybe I'm just beating a dead horse.
>>
> 
> For the moment yes, that is exactly what I'm (we're) doing. ha
> 
> I think I understand what you are trying to say, at least recognize
> the "C-Legalese", but unable to distinguish the subtleties in
> difference between what I'm saying and what you guys are saying.

It's not C legalese, and it's not subtle. It's a fundamental point about
how C pointer arithmetic works that must be properly understood by any C
programmer before he's competent to write any serious code.

> [I mean, (among other things), as long as anyone refers to the "arr"
> in an array declaration as a "pointer" when it is obviously a literal
> constant - I'm likely to stay confused.]

It's not a pointer in the declaration that we're talking about. However,
in most expressions involving the name of an array, it's name is
automatically converted to a pointer to the first element of the array.
-- 
James Kuyper

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

#15054

On 12/27/2011 05:03 PM, ralph wrote:
> On Sun, 18 Dec 2011 13:10:27 -0800, Keith Thompson <kst-u@mib.org>
> wrote:
> 
>> ralph <nt_consulting64@yahoo.net> writes:
>>> On Sun, 18 Dec 2011 01:26:59 +0000, Ben Bacarisse
>>> <ben.usenet@bsb.me.uk> wrote:
>> [...]
>>>> It's not easy to explain the lower-level arithmetic without reference to
>>>> some particular machine.  For example, on a machine with, say, byte and
>>>> word addresses, you can't describe it as you have done.  By all means,
>>>> take a simple architecture and explain what a[0] means on one particular
>>>> system using addresses and size calculations, but you will also have to
>>>> explain, eventually, that arr[i] is, by definition, *(arr + i).
>>>>
>>>
>>> Sure it is because it ain't *(arr + i). It is ...
>>
>> Yes, it is.  C99 6.5.2.1p2:
>>
>>    The definition of the subscript operator [] is that E1[E2] is
>>    identical to (*((E1)+(E2))).
>>
>>> *(arr + ( i * sizeof(datatype)))
>>>
>>> So for int arr[10];
>>> arr[5] is *(arr + (5 * sizeof(int)))
>>> byte arr[10];
>>> arr[5] is *(arr + (5 * sizeof(byte)))
>>
>> You are using your own invented "+" operator that works in units of
>> byte, rather than the actual C "+" operator that works in units of the
>> size of the pointed-to type.  That's fine, but only if you explicitly
>> state that "+" doesn't mean what it means in C.
> 
> [So an 'actual' unit of "size of the pointed-to-type" doesn't have the
> same meaning as an 'invented' unit of "sizeof(<declared>type))".

I can't tell whether those things have the same meaning, because I don't
know what you mean by those terms. In C, when adding an integer (like
5*sizeof(int)) to a pointer to some type (like arr), the integer is
interpreted as counting units of the pointed-at type. Therefore on an
implementation where sizeof(int) is 2, then the expression arr+10 will
point at the 11th 'int' in arr, which in this case is one past the end
of the array.

> ... If
> you look closer you will will see there is not a single pointer in my
> statement nor in the Standard - there ain't NO "pointed-to-type" and
> that is the whole point. <bg>]

There's lots of pointers in the Standard - it's just plain nonsense to
claim otherwise. I'm going to assume that you meant something else. My
best guess is that you meant "there is not a single pointer in my
statement as interpreted in accordance with the Standard". Please let me
know if that guess is incorrect.

Item 9 in your response to Barry Schwartz on 2011-12-17 used := as if it
were an operator. Therefore, it was pretty clear that you weren't using
C syntax, even if it wasn't clear what the syntax you were using was
supposed to mean. If you say that your statement doesn't contain any
pointers, I'll have to defer to your superior knowledge of the syntax
you were using.

However, in later messages you used or talked about the expressions
arr[i], and *(arr+i), and *(arr+5*sizeof(int)). These look exactly like
normal C expressions. In a message posted to a newsgroup devoted to C,
we're entitled to assume that they carry their normal C meaning.

According to that standard, "an expression that has type ‘‘array of
type’’ is converted to an expression with type ‘‘pointer to type’’ that
points to the initial element of the array object" (6.3.2.1p3). There
are exceptions to that rule, but none of the exceptions apply in any of
these three expressions. In all three of them, "arr" is an expression
that has the type "array of int", so there most definitely is a pointer
to int in each of those expressions, and also a pointed-to type: "int".

> When I mentioned this phenomena as an aid for new programmers, I used
> the term "storage map equation" which I assumed everyone understood as
> an implementation context.

I've never heard the term "storage map equation" before. My personal
guess was that your statement that

	arr[5] is *(arr + (5 * sizeof(int)))

(which is false according to C syntax and semantics on any
implementation where sizeof(int)>1) corresponds the statement

	arr[5] is *(int*)((char*)arr + 5*sizeof(char))

(which is guaranteed to be true on all implementations according to C
syntax and semantics). In a newsgroup associated with the C programming
language, it would have saved a lot of trouble if you'd actually written
it that way.

> The concepts behind ...
> 
>  datatype arr[i]  ~==  *(arr + ( i * sizeof(datatype))) 

Your use of '~==' as if it were an operator again clarifies that you're
not using C syntax and semantics. If you insist on using your own
made-up syntax, you should provide an explanation of what it means. This
statement looks very similar to an earlier one, except that "~=="
replaces ":=". What is the significance of that change?

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

#15059

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> I've never heard the term "storage map equation" before. My personal
> guess was that your statement that
>
> 	arr[5] is *(arr + (5 * sizeof(int)))
>
> (which is false according to C syntax and semantics on any
> implementation where sizeof(int)>1) corresponds the statement
>
> 	arr[5] is *(int*)((char*)arr + 5*sizeof(char))

I think you mean:

  	arr[5] is *(int*)((char*)arr + 5*sizeof(int))

> (which is guaranteed to be true on all implementations according to C
> syntax and semantics). In a newsgroup associated with the C programming
> language, it would have saved a lot of trouble if you'd actually written
> it that way.
[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#15061

On 12/27/2011 06:36 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> [...]
>> I've never heard the term "storage map equation" before. My personal
>> guess was that your statement that
>>
>> 	arr[5] is *(arr + (5 * sizeof(int)))
>>
>> (which is false according to C syntax and semantics on any
>> implementation where sizeof(int)>1) corresponds the statement
>>
>> 	arr[5] is *(int*)((char*)arr + 5*sizeof(char))
> 
> I think you mean:
> 
>   	arr[5] is *(int*)((char*)arr + 5*sizeof(int))

You're right. My message went through MANY revisions. At one point it
referred to his use of sizeof(byte), which I translated as sizeof(char).
Later I changed it to refer to sizeof(int), but didn't carry through the
conversion completely. Sorry!

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

#15109

ralph <nt_consulting64@yahoo.net> writes:
<snip>
> The concepts behind ...
>
>  datatype arr[i]  ~==  *(arr + ( i * sizeof(datatype))) 
>
> ... and understanding the difference between addresses and pointer
> datatypes has served to untangle a ton of "pointer" questions. But
> that's me, and my students, and it doesn't matter. ...

That suggests you've only had to untangle such questions in relatively
simple situations.  As I pointed out before, i*sizeof(datatype) is
sometimes the wrong thing to add to the address.  But you can explain
all of this without leaving the world of C's pointers:

  arr[i] is *(arr + i)

which means (at a lower level)

  (int *)((char *)arr + i * sizeof *arr)

As soon as you try to move beyond C's abstract pointers you need to
start talking about machine addresses and these can be more subtle than
your equation assumes them to be.

<snip>
-- 
Ben.

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

#15120

On Saturday, December 17, 2011 10:34:20 PM UTC-6, ralph wrote:
> On Sun, 18 Dec 2011 01:26:59 +0000, Ben Bacarisse
> <ben.u...@bsb.me.uk> wrote:
> 
[snip]

> >
> >It's not easy to explain the lower-level arithmetic without reference to
> >some particular machine.  For example, on a machine with, say, byte and
> >word addresses, you can't describe it as you have done.  By all means,
> >take a simple architecture and explain what a[0] means on one particular
> >system using addresses and size calculations, but you will also have to
> >explain, eventually, that arr[i] is, by definition, *(arr + i).
> >
> 
> Sure it is because it ain't *(arr + i). It is ...
> 
> *(arr + ( i * sizeof(datatype)))
> 

I suggest you try that with some real code:

    int a[] = {0,1,2,3,4,5};
    printf("a[1] = %d, *(a + 1) = %d, *(a + 1 * sizeof *a) = %d\n",
      a[1], *(a + 1), *(a + 1 * sizeof *a));

*(a + i * sizeof *a) != a[i] 

Pointer arithmetic is defined in terms of the size of the pointed-to type; For any object of type pointer to T, the expression *(p + i) yields the value of the i'th *element* of type T after p, not the i'th *byte*.  

> So for int arr[10];
> arr[5] is *(arr + (5 * sizeof(int)))
> byte arr[10];
> arr[5] is *(arr + (5 * sizeof(byte)))
> 

Again, I suggest you write some code to test that assertion.

> You don't care what platform you are using because the sizeof takes
> care of it. sizeof and size of datatypes are defined for each compiler
> (which is platform specific by default). That's how pointer arithmetic
> works. That's how the C language achieves platform independence and
> compilers can be implemented for any specific architecture.


*EXACTLY*.  You don't have to worry about the size of the data type, so you don't have to think in terms of *byte offsets*.  You simply think in terms of *elements*.  

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

#14674

On Sunday, December 18, 2011 9:26:59 AM UTC+8, Ben Bacarisse wrote:
> ralph <nt_cons...@yahoo.net> writes:
> 
> > On Sat, 17 Dec 2011 13:55:44 -0800, Keith Thompson <ks...@mib.org>
> > wrote:
> >
> >>ralph <nt_cons...@yahoo.net> writes:
> >>[...]
> >>> I have trouble understanding the constant confusion between arrays and
> >>> pointers. Way back when (and we are talking many moons ago <g>) when I
> >>> started out in C my mentor explained it very simply in these terms in
> >>> the first couple of days.
> >>>
> >>> 1) There is a difference between declarations and definitions.
> >>> Remember which you are dealing with and when.
> >>> 2) A pointer is a "variable", an array is a "constant"
> >>
> >>That doesn't really make sense.  An array variable is not a constant:
> >>
> >>    int arr[10];
> >>    arr[5] = 42;
> >>
> >>I suppose what it means is that an array name, when it appears in an
> >>expression (in most but not all context) decays to a pointer to the
> >>array's first element, and that pointer value cannot be modified.  But I
> >>think that saying an array is a constant just reinforces the confusion
> >>between arrays and pointers.
> >>
> >
> > I disagree. 
> >
> > Once the beginner gets it through his head that you can never do an
> > assignment to 'arr' you resolve a ton of the questions we get around
> > here. That as close to the definition of a "constant" as you can get.
> 
> I'd say that "unchanging" or "immutable" were closer definitions, and
> arrays can be changed.
> 
> What you call a constant, I'd call a value, and I'd explain that
> array-valued expressions are (usually) converted automatically to
> pointer values.
> 
> Most people learning programming quickly get the idea of variables and
> values.  Variables can be assigned to, but values can't.  This avoids
> calling arrays "constant".  It's also a start towards some more
> technical matters such as why
> 
>   int x;
>   x = 0;
> 
> is ok, but
> 
>  (int)x = 0;
> 
> is not.
> 
> >>> 3) The array name evaluates to the address of the first element in the
> >>> array.
> >>
> >>This applies to any expression of array type, not just the name of a
> >>declared array object.  But it doesn't apply in all contexts.
> >>Specifically, an expression of array type is converted to a pointer to
> >>the array object's first element *unless* it's:
> >>
> >>    The operand of a unary "sizeof" operator (sizeof arr gives you the
> >>    same of the array, not of a pointer);
> >>
> >>    The operand of a unary "&" operator (&arr gives you the address of
> >>    the array object; it's the same memory location as the address of
> >>    its first element, but it's of a different type);
> >>
> >>    A string literal in an initializer used to initialize an array
> >>    object.  In
> >>        char arr[6] = "hello";
> >>    the *value* of "hello" is copied into arr.
> >>
> >
> > Yep. But what's the big deal. 
> >
> > And of course I disagree that it actually matters to the beginner that
> > the address is of a "different type". Semantically and syntactically
> > it comes out the same. Plenty of time to get into vague language
> > later.
> 
> I agree about putting this off, but 'arr' and '&arr' are not the same
> semantically.  If they were,
> 
>   arr + 1
> 
> and
> 
>   &arr + 1
> 
> would have the same value but they don't.  (I'm using arr as defined
> above.)
> 
> <snip>
> >>In most contexts; see above.  It would be clearer to say that an array
> >>name *decays to* an address (or pointer value).  And I wouldn't use the
> >>word "initialized".
> >
> > I would. And again what does 'decay' meant to the beginner?
> > In code the name "arr" is changed to, or evaluates to, the address of
> > the first element.
> 
> I'd just say "converted".  C has lots of automatic conversions and,
> sooner or later, these need to be explains.  The array to pointer
> conversion fits into this general pattern.
> 
> <snip>
> >>> 9) The array operator evaluates to a storage map equation, eg.
> >>>     type ar[i] := *(a + (i * sizeof(type))
> >>
> >>I'm not sure what syntax you're using.  What does "type" mean here?  And
> >>C pointer arithmetic is already scaled by the size of the pointed-to
> >>type.
> >>
> >>arr[i] is by definition equivalent to *(arr + i).
> >
> > Think about it. 
> >
> > You say that now, but you come back later in other response to point
> > out "sizes". That "already scaled" is because the compiler knows the
> > type, and he knows the type because you declared it.
> 
> It's not easy to explain the lower-level arithmetic without reference to
> some particular machine.  For example, on a machine with, say, byte and
> word addresses, you can't describe it as you have done.  By all means,
> take a simple architecture and explain what a[0] means on one particular
> system using addresses and size calculations, but you will also have to
> explain, eventually, that arr[i] is, by definition, *(arr + i).
> 
> <snip>
> -- 
> Ben.


In C there is no boundary checking  in the index of an array in a read 
or write operation to the array.






 




   

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

#14675

On 2011-12-18, 88888 Dihedral <dihedral88888@googlemail.com> wrote:
> In C there is no boundary checking  in the index of an array in a read 
> or write operation to the array.

This is a vast oversimplification.  It's undefined behavior to access
outside the object.  Whether or not there is bounds checking is up to the
implementation; some real implementations have done it.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#14676

On Sunday, December 18, 2011 12:56:07 PM UTC+8, Seebs wrote:
> On 2011-12-18, 88888 Dihedral <dihedr...@googlemail.com> wrote:
> > In C there is no boundary checking  in the index of an array in a read 
> > or write operation to the array.
> 
> This is a vast oversimplification.  It's undefined behavior to access
> outside the object.  Whether or not there is bounds checking is up to the
> implementation; some real implementations have done it.
> 
> -s
> -- 
 In the language design C is easy to be mixed with assembly. 

If one needs boundary checking  of an array,  other higher level programming
languages are  better options. 

 


  

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

#14678

On 2011-12-18, 88888 Dihedral <dihedral88888@googlemail.com> wrote:
>  In the language design C is easy to be mixed with assembly. 

That, too, is an oversimplification.

> If one needs boundary checking  of an array,  other higher level programming
> languages are  better options. 

Could be, but the fact is, there are bounds-checking implementations.  The
claim that there's no bounds-checking in C is not really generally true.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#14689

On Sunday, December 18, 2011 1:42:59 PM UTC+8, Seebs wrote:
> On 2011-12-18, 88888 Dihedral <dihedr...@googlemail.com> wrote:
> >  In the language design C is easy to be mixed with assembly. 
> 
> That, too, is an oversimplification.
> 
> > If one needs boundary checking  of an array,  other higher level programming
> > languages are  better options. 
> 
> Could be, but the fact is, there are bounds-checking implementations.  The
> claim that there's no bounds-checking in C is not really generally true.
> 
> -s

If there is any boundary checking on a machine, 
what does that mean in the execution speed?

Happy programming?

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

#14691

On Sun, 18 Dec 2011 08:08:34 -0800 (PST), 88888 Dihedral
<dihedral88888@googlemail.com> wrote:

>On Sunday, December 18, 2011 1:42:59 PM UTC+8, Seebs wrote:
>> On 2011-12-18, 88888 Dihedral <dihedr...@googlemail.com> wrote:
>> >  In the language design C is easy to be mixed with assembly. 
>> 
>> That, too, is an oversimplification.
>> 
>> > If one needs boundary checking  of an array,  other higher level programming
>> > languages are  better options. 
>> 
>> Could be, but the fact is, there are bounds-checking implementations.  The
>> claim that there's no bounds-checking in C is not really generally true.
>> 
>> -s
>
>If there is any boundary checking on a machine, 
>what does that mean in the execution speed?


Nothing or anything...  Totally implementation dependent.

Nor does bounds checking have to be anything like exact.  Consider
segments as used my large data model x86 16 bit protected mode
programs.  Accessing just outside of an object may hit an adjacent
object, with the usual overwrite behavior, but far enough outside may
run off the segment boundary triggering a fault.  As that's checked in
hardware, there's no direct performance penalty.  Where segments have
high overhead in x86 is in changing the currently loaded set.

Alternatively, a limited form of bounds checking is implemented by
many C compilers that adds sentinels to critical items on the stack
(particularly the stack frame chain data and return address), but this
is only checked at selected times (for example at the return from a
function).

In environments where much of the bounds checking is done in software,
there has been a fair bit of work on techniques to minimize the cost,
and at least some of those techniques would be usable by a C compiler.

That being said, C's memory model makes bounds checking fairly simply
(if not necessarily efficient) for entire objects, but generally
checking for overflows between items within an object is much more
difficult.

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

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

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

csiph-web