public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "brodhow at all2easy dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/57853] pointer arithmetic on arrays
Date: Tue, 09 Jul 2013 03:08:00 -0000	[thread overview]
Message-ID: <bug-57853-4-360mcCv9zD@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-57853-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853

Howard Brodale <brodhow at all2easy dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #9 from Howard Brodale <brodhow at all2easy dot net> ---
(In reply to Andrew Pinski from comment #8)
> >"*++arr[0][0]" is not supposed to change the array arr! 
> 
> At this point I am going to say you don't know C and should ask on a C
> mailing list learning C.
> 
> *++arr[0][0] does the following:
> ++arr[0][0]
> And then deferences that value (which turns into 's').
> 
> 
> If you only want (arr[0][0])[1] then use that or *(arr[0][0]+1) rather than
> ++.

That is not the issue. With "*++arr[0][0]" we want to see 's'. The problem is
after that "++" operation when we want to output the array arr's values again
that the arr[0][0] is no longer "as" but, only "s" now. That is seen in the
nested for loops, after the "++" operation, above. When the "++" operation is
removed then in the for loops, a[0][0] is "as"; in the for loop's printf.  You
are not looking at the for loops printf()!  With the "++" operstion then, the
printf() in the for loops outputs "s" for where "as" was.

 This means that a[0][0] is being treated as a Left Hand value of an equal sign
where a[0][0]++ value is now the right hand side of that equal sign.  Where
a[0][0] is being set equal to "s" now.  This process has never existed before
in C when doing pointer arithmetic (++) on array elements and such.  Where
performing ++ptr would not just result in the next datatype's value normally.
But, here a --ptr would then render the initial value, again. Or, where *ptr
remained unchanged, itself.  

  Millions of lines of legacy C code has this same pointer arithmetic in the
expectation that it does not change the value that the pointer points to, for
later reference.  Or, ++prt does not change the value that a[0][0] is but, here
"++" is changing what a[0] is, later.  Before, a[0] is set to "as" in the for
loop's printf after where "++" was, above. After the "++" operation is added,
a[0] is now being set to just "s" or the 'a' has been wiped out, lost or
destroyed. As seen in the later printf, in the for loops.

 So, see what the for loop's printf outputs for a[0][0] ("as") without the "++"
operation above. Then, add "++" and see what the same for loop's printf outputs
("s").  That value in the array was changed by the pointer arithmetic! Or,
++ptr is not equivalent to ptr = ++pter! But, that is whats happening here! As
seen in the for loop's printf for array arr!

 Do you agree that ++ptr is not equivalent to ptr = ++pter? If not then you
don't see that that this is whats very wrong here!  Pointer arithmetic does not
make the value a pointer points to a Left Hand side value, in this equality
expression!  No such equality expression should exist here!


  parent reply	other threads:[~2013-07-09  3:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-08 20:03 [Bug c/57853] New: " brodhow at all2easy dot net
2013-07-08 20:10 ` [Bug c/57853] " brodhow at all2easy dot net
2013-07-08 20:17 ` pinskia at gcc dot gnu.org
2013-07-08 22:06 ` brodhow at all2easy dot net
2013-07-08 22:08 ` pinskia at gcc dot gnu.org
2013-07-08 22:10 ` brodhow at all2easy dot net
2013-07-08 22:13 ` brodhow at all2easy dot net
2013-07-08 22:15 ` brodhow at all2easy dot net
2013-07-08 22:18 ` pinskia at gcc dot gnu.org
2013-07-09  3:08 ` brodhow at all2easy dot net [this message]
2013-07-09  4:15 ` brodhow at all2easy dot net
2013-07-09  4:24 ` pinskia at gcc dot gnu.org
2013-07-09  6:52 ` brodhow at all2easy dot net
2013-07-09  7:15 ` schwab@linux-m68k.org
2013-07-09 10:28 ` redi at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-57853-4-360mcCv9zD@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).