[Bug c/57853] pointer arithmetic on arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853
--- Comment #18 from this is me ---
This is why C arrays are not pointers. It was possible to easily misconstrue
datatypes like especially with imported variables. Defined as a short integer
in one file but, is being used as a character in another file. Here, the 1
datatype width (in "++") here can be narrower with a short integer so when the
cpu tries access a wider character's datatype width then, thats where
segmentation faults or bus errors come from!
Seg faults can still happen even now with the extreme datatype checking
between calling arguments and received parameters! How? Like when defining a
structure then using it! Before allocating any memory for it, still! Some
things never change.
So, a pointer can point to anything but, they're not all of the same datatype
width nature! This is what C arrays are not pointers! C arrays can hold any
type of data too! Where the indexing uses different number values as to which
datatype it is. See "Expert C Programming" by Peter Van Der Linden. Where he
says that it is shocking! C arrays are not pointers!
He also says that the C array indexing is based on a commutative math formula
where a + b = c and b + a = c! Or, here absolute address + datatypewidth offset
= relative address or datatypewidth offset + absolute address = relative
address! As in:
#include
void main(){
char cat[4] = {'C', 'A', 'T' };
int i = 0;
printf("the char is %c\n", cat[0]);
printf("the char is %c\n", cat[1]);
printf("the char is %c\n", 2[cat]); // what does this print?
}
/Programming/C$ gcc Mario.c -o mari
/Programming/C$ ./mari
the char is C
the char is A
the char is T
Theres no array named '2'! Theres no index variable called "cat"! So! Whats
going on? a + b = c and b + a = c! Or, here absolute address + datatypewidth
offset = relative address or datatypewidth offset + absolute address = relative
address!
Its still true today! Even with today's C compilers! 2[cat] still prints 'T'!
[Bug c/57853] pointer arithmetic on arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 --- Comment #17 from this is me --- Its simpler than what Andrew was describing! It is simply incrementing by 1 character datatype width to the next character with "++".
[Bug c/57853] pointer arithmetic on arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 --- Comment #16 from this is me --- Andrew Pinski: Will you delete this Bug 57853 web page for me? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 I can't hired! Howard > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 > > Andrew Pinski changed: > > What|Removed |Added > > Status|UNCONFIRMED |RESOLVED > Resolution|--- |INVALID > > --- Comment #8 from Andrew Pinski --- >> "*++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 > ++. >
[Bug c/57853] pointer arithmetic on arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 --- Comment #15 from Howard Brodale --- The arr pointer is being set to the incremented value which is the 2nd element in the array to start from as the arr[0] value, then.
[Bug c/57853] pointer arithmetic on arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 --- Comment #14 from Howard Brodale --- My email address now is brod...@sbcglobal.net
[Bug c/57853] pointer arithmetic on arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Howard Brodale changed: What|Removed |Added CC||brodhow at sbcglobal dot net --- Comment #13 from Howard Brodale --- I want to delete this bug now but, I don't have the same email address now that I used to create my first account here with.
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Jonathan Wakely changed: What|Removed |Added Severity|critical|normal
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Andreas Schwab changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853
Howard Brodale changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #12 from Howard Brodale ---
"store the incremented v back into v" is not quite right either. The pointer
arithmetic "*++arr[0][0]" is incrementing the head pointer of the string array
element one char past 'a' and not actually storing the shortened string back in
there. If it was storing the shortened string there then the 'a' would be lost
or written over which it is not.
printf("%c\n",*++arr[0][0]);//works fine and prints s
printf("%c\n",*--arr[0][0]);//works fine does print a
as
me
s <- the 1st "++"; incrementing past 'a'
a <- the first "--"; dcrementing back to 'a'
as <- "as" prints now as expected
as df ce me yu we <- and here again, too, "as" is showing as expected. Take out
the "--" operation and these "as"s will be "s"s.
'a' is not lost nor written over by any storing back into v, here or no storing
is going on. Just pointer that array arr gets moved over to point at the next
character.
char *arr2 = "this is a test\n";
int len_arr2 = 0;
len_arr2 = strlen(++arr2);
printf("length of arr2 is %i\n", len_arr2);
printf("%c\n", *arr2--);
len_arr2 = strlen(arr2);
printf("length of arr2 is %i\n", len_arr2);
puts(arr2);
outputs:
length of arr2 is 14 <- "++"; moving past the 't', one character less in string
his is a test <- 't' is missing now
length of arr2 is 15 <- "--"; moving back over the 't', one character more
this is a test <- 't' is back now; if storing in v happened then 't' would've
been lost and would be not recoverable.
Now, I have also recovered more knowledge about pointer arithmentic, with
character strings. 'a' is not being destoyed or lost in the original context.
Its just being ignored.
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #11 from Andrew Pinski --- ++v mean pre-increment v. That means store the incremented v back into v. If you don't understand that, then I cannot help you. Please stop opening an already closed bug. This is not the correct forum to learn C, please take this discussion somewhere else.
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 --- Comment #10 from Howard Brodale --- Should we expect to see "as" in the for loop's printf, for arr[0][0]? YES! And, we do when the pointer arithmetic is NOT being done, above. But, something changed arr[0] to "s" only! What did that? Did I change arr[0] like where I specified arr[0] = "s";? NO! But, something did! Should the C code set arr[0] = "s"? NO! But, it did set a[0] to "s", only! Thats whats happening, erroneously! For when we output array arr again or later or after the pointer arithmetic operation is shown THEN, only "s" appears where "as" used to be! And, also for every where else a[0] is being printed! After the pointer arithmetic operation. This "s" problemm is being shown in the for loop's printf and every where else a[0] is being outputed, AFTER the "++" operation. Where another "++" is not! But, "a" is still not showing up, AFTER the initial "++" operation. Look at all the subsequent printfs, AFTER the "++" operation. Where "as" used to be now only "s" is being outputed. Do you see where the issue is first appearing? Then, by what C code statement the issue is being done by? Though "*++arr[0][0]" does output 's' (correctly); something else is being done that should not be done! Setting *arr[0] EQUAL TO "s"! Which is wrong!
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853
Howard Brodale changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #9 from Howard Brodale ---
(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!
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #8 from Andrew Pinski --- >"*++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 ++.
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 --- Comment #7 from Howard Brodale --- we get only 's' in a subsequent printf that runs after that "++" statements. >From that next printf "as" should aappear but, it has been changed to only 's', by the "++" operation!
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 --- Comment #6 from Howard Brodale --- "*++arr[0][0]" is not supposed to change the array arr! It is supposed to take the source, change it for later use and leave the source unchanged! That the way pointer arithmetic works. It never has changed the source ever, until now. Where "as" is still supposed to output we get only 's' now.
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Howard Brodale changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #5 from Howard Brodale --- "*arr[0][0] += 1" generates a segmentation fault when run. That is not vaild to get 's' to output.
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- (In reply to Howard Brodale from comment #3) > ++arr[0][0] does work for printing out the second character 's'. ++arr[0][0] increments arr[0][0] like you said. It changes the value of what is contained in arr[0][0] .
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853
Howard Brodale changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #3 from Howard Brodale ---
++arr[0][0] does work for printing out the second character 's'. But, then that
pointer arithmetic operation has the side effect of wiping out the 'a' from
"as". Because when
for (i=0; i<2; ++i)
for (j=0; j<3; ++j)
printf("%s ", arr[i][j]);
runs, it just prints 's' for where "as" should be. The 'a' is now gone or
destroyed by the previous ++arr[0][0] operation. Wgen that "++" is removed then
"as" prints from those for loops after where the printf with the "++" was.
So, this bug is not invalid! And, is not resolved!
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- ++arr[0][0] Does: (arr[0][0] += 1) So it increments the char pointer so instead of pointing to &"as"[0], it points to &"as"[1].
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 --- Comment #1 from Howard Brodale --- gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
