Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: Difference between these pointer syntaxes
Date: Sat, 20 Aug 2016 15:02:19 -0700
Organization: None to speak of
Lines: 73
Message-ID: <lnfupzgkus.fsf@kst-u.example.com>
References: <nodpg5$cr7$1@dont-email.me> <not07u$k7g$1@dont-email.me> <lna8gdomrv.fsf@kst-u.example.com> <not3oh$nk$1@dont-email.me> <ln60r1ojs3.fsf@kst-u.example.com> <not8so$iji$1@dont-email.me> <ln1t1pog5y.fsf@kst-u.example.com> <notcof$voo$1@dont-email.me> <lnwpjhmy7a.fsf@kst-u.example.com> <notjf6$lqo$1@dont-email.me> <lnshu5msy1.fsf@kst-u.example.com> <notmod$u3t$1@dont-email.me> <lnoa4tmpg1.fsf@kst-u.example.com> <nouo9p$f7o$1@dont-email.me> <lnk2fgn2vv.fsf@kst-u.example.com> <novq08$4a1$1@dont-email.me> <ln7fbgmndh.fsf@kst-u.example.com> <kfnvayxdw9q.fsf@x-alumni2.alumni.caltech.edu> <np829e$l73$1@dont-email.me> <lnk2fcgriw.fsf@kst-u.example.com> <np8aia$9h1$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="5060"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX197LPjHtY1vvk+cG+TJVoMz"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:Is1I1R7nC9gIvP4IKcAhFTe5KO8= sha1:jmUhrKNf/GJXkPu/LhEpS+tihBg=
Xref: csiph.com comp.lang.c:92551

Les Cargill <lcargill99@comcast.com> writes:
> Keith Thompson wrote:
[...]
>> If you start with that premise, *maybe* you can be a successful
>> C programmer by memorizing some exceptions and/or avoiding some
>> constructs.
>
>
> I don't really see a problem with that... and yes, that's a lot of
> what I'm saying.
>
> If I may, "avoiding some constructs" is 99% of what I tend to confuse 
> with "being a good 'C' programmer."

Sure -- but you still have to deal with code written by others who don't
avoid the same constructs you do.

[...]

>> I don't recall you stating what those two simple rules are.
>>
>
> Yeah, we have "thread salad" problems. May I?
>
> Two sections: Constraints on declarations:
>
> 1) array declarations allocate memory ( in the linker section sense[0]) 
> in the quantity of (extent*sizeof(element)) bytes, give or take 
> fragmentation and packing issues.
>
> [0] examples include .BSS and .DATA in cases; other mnenomics
> may be used but these are often true for GNU.

Array declarations (more precisely definitions) can allocate memory
either "in the linker section sense" or on the "stack" -- and array
*objects* can be created via malloc() and friends [blah blah strict
aliasing effective type blah blah].

> 2) Treating the array base as an lvalue is verboten.

What do you mean by "base"?  Note that an array name *is* an lvalue when
it's the operand of unary & or sizeof.

> Constraints on operations once declared/initialized:
>
> Either pointer objects or array objects can be deferenced using
> either array (arr[index]) or pointer (*arr+index) notation.
>
> Within this, there is also the "plane" of "pointers must have valid 
> values"[1].
>
> [1] Bounded by valid references to a chunk of memory returned by 
> malloc(),  "allocated" by the toolchain reference binding, allocation
> and location process or in cases, bound to physical hardware structures.
>
> index references to array objects must be valid ( bounded in the 
> inclusive range ( 0..extent-1) ) .

    int arr[10];
    int *ptr = arr;
    printf("%zu vs. %zu\n", sizeof arr, sizeof ptr);

How does your model explain the two different values this will print?
(Assuming of course that a pointer doesn't happen to be the size of 10
ints.)

[...]

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