0

I am a newbie in C, but I have already watched dozens of videos on YT about how to understand pointers... Unfortunately, it seems my stupid brain is not getting the point about pointers. Could anyone help me to understand why I am getting such values in the output?

The output is: 1-40 256-296 64-104

#include <stdio.h>
int main() {
    int arr1[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
    int arr_size = sizeof(arr1) / sizeof(arr1[0]);
    int arr2[arr_size];
    int arr3[arr_size];
    int *ptr1 = arr1;
    int *ptr2 = arr2;
    int *ptr3 = arr3;
    printf("%u-%u %u-%u %u-%u\n", *ptr1, sizeof(arr1), *ptr2, *ptr2+sizeof(arr2), *ptr3, *ptr3+sizeof(arr3));
    return 0;
}

Thanks for help!

Vlad from Moscow
  • 301,070
  • 26
  • 186
  • 335
Tom
  • 11
  • 4
  • 1
    Read a book — a [good book](https://stackoverflow.com/q/562303/15168) — and practice. Practice will help more than watching videos, IMO. With pointers, drawing pictures often helps too. – Jonathan Leffler Apr 13 '22 at 18:22
  • 1
    Tom, on the plus side, you are coding the _arrays_ as `arr...` and _pointers_ as `ptr...`. It is good to demo that arrays are not pointers and pointers are not arrays. – chux - Reinstate Monica Apr 13 '22 at 18:23

1 Answers1

-1

The arrays arr2 and arr3 are not initialized. So their elements have indeterminate values. Outputting uninitialized elements invokes undefined behavior.

Also to output a value of the type size_t you need to use the conversion specifier zu instead of u in a call of printf.

So the only valid call of printf will look the following way

printf("%d-%zu\n", *ptr1, sizeof(arr1) );

This call outputs the value of the first element of the array arr1 by means of the pointer ptr1 that (value) is equal to 1 and the size of the array itself that can be equal to 40 provided that sizeof( int ) is equal to 4.

Vlad from Moscow
  • 301,070
  • 26
  • 186
  • 335
  • Thanks, I will read it carefully, few times, and will see. – Tom Apr 13 '22 at 18:22
  • 1
    Re “Outputting uninitialized elements invokes undefined behavior”: No, it does not. They will have indeterminate values, so some value will be passed to `printf` for formatting (unless the C implementation has trap representations in that type and the indeterminate value happens to be such a trap representation). Using the value of an uninitialized automatic object that could have been declared `register` has undefined behavior per C 2018 6.3.2.1 2, but arrays and their elements cannot be declared `register`. – Eric Postpischil Apr 13 '22 at 18:27
  • @EricPostpischil And an indeterminate value can be a trap value. Oh, it is a well defined program.:) – Vlad from Moscow Apr 13 '22 at 18:35
  • @EricPostpischil From teh C Standard "5 Certain object representations need not represent a value of the object type. If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undefined. If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined.50) Such a representation is called a trap representation." – Vlad from Moscow Apr 13 '22 at 19:00
  • @VladfromMoscow: I know what a trap representation is. Common modern C implementations do not have trap representations in the `int` type, and therefore it cannot occur that an indeterminate value has a trap representation. Further, in C implementations where it does, the statements “`*ptr2` has undefined behavior” and “`*ptr2` has an indeterminate value which could cause undefined behavior” are different statements. This answer contains the former, essentially, so it is wrong. – Eric Postpischil Apr 13 '22 at 19:09
  • @EricPostpischil It is not important how modern compilers behave. It is important what is written in the C Standard. – Vlad from Moscow Apr 13 '22 at 19:19
  • 1
    @VladfromMoscow: What is written in the C standard is that implementations may or may not have trap representations. If an implementation does not have trap representations, then `int x[10]; printf("%d\n", x[0]);` does not have undefined behavior; it is required by the standard to format **some** `int` value and print it. Stating “Outputting uninitialized elements invokes undefined behavior” without qualification is false; it is not what the C standard says. – Eric Postpischil Apr 13 '22 at 19:26
  • @EricPostpischil [J.2 Undefined behavior (...) The value of an object with automatic storage duration is used while it is indeterminate](https://port70.net/~nsz/c/c11/n1570.html#J.2). – n. m. could be an AI Apr 13 '22 at 19:41
  • 1
    @n.1.8e9-where's-my-sharem.: Annex J is non-normative. It is an informational summary, useful for locating things in the normative part of the standard, and it contains errors, such as that one. I have cited the relevant normative part of the standard, C 2018 6.3.2.1 2. – Eric Postpischil Apr 13 '22 at 19:46
  • @EricPostpischil This is what the standard literally **says**. Whether what it says is true or not, I do not judge. – n. m. could be an AI Apr 13 '22 at 19:48
  • 1
    @n.1.8e9-where's-my-sharem.: It is text in the physical document, but it is not part of “the C standard.” If you want to make the point that the text actually appears in the document, fine, but that is worthless. It is not a normative part of the document and is not relevant in determining the meaning of the standard when we have clear language in the normative text of 2018 6.3.2.1 2. – Eric Postpischil Apr 13 '22 at 20:04
  • @EricPostpischil I provided a quote from the section "6.2.6 Representations of types" of the C Standard. – Vlad from Moscow Apr 13 '22 at 20:33
  • @VladfromMoscow: I addressed that. – Eric Postpischil Apr 13 '22 at 20:46
  • @EricPostpischil See also http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_451.htm – n. m. could be an AI Apr 13 '22 at 20:48
  • @EricPostpischil In the quote you provided there is used an example with unsigned char. And moreover until the Standard is not changed you have to follow the Standard. – Vlad from Moscow Apr 13 '22 at 21:04
  • @n.1.8e9-where's-my-sharem.: Why should I see that? What meaning do you think it has for this discussion? – Eric Postpischil Apr 13 '22 at 21:59
  • @VladfromMoscow: (a) I did not provide any quote with an `unsigned char`, and how would that matter anyway? (b) I am discussing the C standard as it stands. Nor do I or any person have to follow the C standard; it is entirely voluntary. Your answer is wrong; just fix it. – Eric Postpischil Apr 13 '22 at 22:02
  • @EricPostpischil My answer is not wrong. It follows the C Standard. – Vlad from Moscow Apr 13 '22 at 22:03