>>80343943
because in the second case the ptr contains a garbage address, not a valid address to garbage data as in the first case

in the first example you declare an int with local storage. it's allocated to the stack, and has an undefined value until you assign 10 to it.

in the second example, you have declared an int pointer with local storage. it also is allocated on the stack. but since it points to stawell knows where, when you dereference to it, you are trying to write to some rando location that will likely seg fault.

>>80343975
So both A and ptr themselves (4 and 8 bytes respectively, depending on the system) are stored on the stack, but the address ptr contains points to a random location (not the stack)?

>>80343943
because you arent used malloc as you are supposed to do and you will segfault

>>80344013
yup. the computer is cool with you accessing the stack. it's (hopefully) not cool with you dereferencing an uninitialized value you find there

>>80344037
I seem thank you.

>>80343943
Retard, you’re dereferencing an uninitialised pointer
If you don’t understand what’s wrong with this you should take a step back as you don’t know anything about automatic variables or pointers.

>>80343943
You are (almost) correct in that A and ptr both contain garbage values initially. In the first example, you are simply overwriting the value of a variable that you own (on the stack) with 10. However, in the second example, *ptr means “Hey, CPU, go jump to this garbage memory address (ptr) and try to write the value 10 to it”. The chances of ptr actually pointing to a region of memory that your process has mapped writable are pretty slim. So, the CPU will attempt to write to memory it doesn’t own, and will then issue a segmentation fault (SIGSEGV) that will bubble back up to your OS, and the program will exit.

>>80344037
And when I do malloc I get some memory allocated on the heap, where it is then safe to overwrite whatever garbage is present there, correct?

>>80344014
You know what yould be fun? run this program thousands of times and find the propability the garbage pointer to be located in your stack.

>>80344066
with realloc if the new value is bigger than before

>>80344061
ptr itself is on the stack as well though, and is safe to overwrite (ex. I could do ptr = 0x...; or ptr = &A;), but the address it contains probably points to somewhere I don't have access to. Did I get it right?

>>80343943
Use a better language.

>>80344125
Yep, that’s correct!

>>80344160
Great, thank you. Think I get it now

>>80344160
P.S. — just remember that “pointers are addresses”. And *ptr just means “go to the ‘ptr’ address”.

Helped me a lot when I was starting out.

>>80344195
>>80344228
Good luck with your future software endeavors!

>>80344228
>>80344242
Thanks guys, appreciate it

>>80344242
>>80344300
Thanks for the gold!

>>80344317
Is that some shit reddit meme?

>>80343943
Deterministic memory management

>>80343943
FUCKOFF TO /SQT/

File: wallhaven-184914.jpg (642 KB, 2560x1600)

642 KB JPG

>>80343943
The real redpill is that SHOULD be able to do this:

int* wew=&10;

Now, supposing that every instance of the integer literal 10 maps to the same point in memory, you can just change the value of the integer literal at runtime.

>>80343943
You could do that, if the operating system would let you. But it won't, because you'd probably be overwriting some memory somewhere and could crash the whole computer.

>>80344784
What are you even trying to accomplish?

>>80343943
you need to call malloc in order for 'ptr' to receive a valid pointer. dereferencing an unitialized pointer is undefined behavior, what happens depends largely on the implementation and environment.

Lots of bad advice in this thread. This has nothing to do with the value itself and everything with the type. If you want to do this assignment, you need to cast 10 to (int *) type, which can be done, for example, like this: *ptr = (int *)(void *)10;

>>80344784
& in this context is an operation f or taking an address of something and 10 is not something that has an address so it should not be possible to do this.

>>80344811
Wouldn't it be great it you could write

    for (int i=0; i<10; i++) {
        fun(); // change the meaning of "10" :^)
        printf("%i\n",10);
    }

and have it print a different value each time?
>No, that's retarded.
It's a thing that actually happened in other langs, and it's fucking hilarious.

>>80344918
> 10 is not something that has an address
Of course it does (in practice). Even literal expressions are stored SOMEWHERE.

>>80344937
Wat. Most literals are pretty unlikely to make it into the binary in a form that still resembles their type in your code, if at all.

>>80344937
In machine code, in form of CPU instructions, with types that are related to hardware you're compiling for (so in this example int could be 4 bytes and 10 would stored in 1 byte in binary) and not necessarily even stored in a way that normal ints are stored in memory.

>>80344928
It's a misunderstanding of what's happening under the hood. The code for this loop might have been unrolled to the point that "10" doesn't exist anywhere in the compiled code nor does the loop. It doesn't let you take the address of "10" because that makes no sense.

>>80343943
Step away from all keyboards immediately.

>>80344928
You can do that, just use a global pointer variable, you can call it TEN or whatever to satisfy your autism.

>>80344060
This, if you wanna learn C you better start at the basics.

>>80344968
>>80345031
Maybe I should clarify: In old FORTRAN, you could pass a literal constant to a subroutine and manipulate it. It allowed for fuckery exactly like that. Ofc nobody in their right mind did that on purpose.

>>80343943
In Haskell this is just
A = 10

do
  ptr <- calloc :: IO (Ptr CInt)
  poke ptr 10

>>80344784
you're retarded. this makes no sense in C.
however, today may be your lucky day, because back the 90s they invented a language precisely for people with your level of ability:

>>> import ctypes
>>> ctypes.cast(id(10), ctypes.POINTER(ctypes.c_int))[6] = 11
>>> 10
11

>>80345079
>>80344060
WRONG.
There is no dereferencing going on, just assigning a value to a pointer in a way that won't compile. Cast 10 to (int *) and it's perfectly valid code.

>>80345092
I thought you were talking about Java. They had a a thing that integer consts up to 128 had pre-made objects in memory for them so that 10==10 was true but 150==150 was false.

>>80345112
>you're retarded.
or am I?
>your example
see, aint that based.

>>80345046
fuck you

>>80344060
You are the retard here faggot

>>80345079
I know the basics fag

>>80344661
kys

>>80344907
Not true, that would still try to overwrite a potentially dangerous memory location

>>80343943
Why initialize a pointer with anything but nullptr?

>>80345656
Just as a question, I know one should always do int *ptr = NULL; for example

>>80345853
So you're familiar on how null works, why you asked a dumb question to begin with?

>>80345901
I was confused on why the garbage an uninitialized pointer contains would point outside the stack. My question had nothing to do with the NULL pointer retard

>>80343943
*ptr = 10 is not equivalent to A = 10. That's why. The equivalent thing to do would be ptr = 10.

>>80346014
Your computer does not have unlimited memory it has in fact very limited memory, pointers are simple memory address that you ask the OS for. You can't initilize a pointer with a memory address that you either never allocated or pointed to.
What the value of 10 is supposed to point to?
Always initialize your points with nullptr.
There is your answear.

>>80345211
If you did, you wouldn't have asked. No questions are stupid, but your inability to accept your own lack of knowledge makes me believe you are.
>>80345121
You must be baiting

>>80347337
I was confused on why the garbage an uninitialized pointer contains would point outside the stack.

If you say no questions are stupid why do you have to respond like an arrogant retard?

>>80347517
See, again, you don't know what your talking about. A pointer is just a memory-adress. It can point to memory in heap, which is outside the stack.
Also, why would a random permutation of bits be a valid address on the stack? It's like saying "oh I was very surprised not every lottery ticket is a winner". This is literally how you sound like to anybody who knows their shit.
Go and learn the basics of memory-management and -organization. It's legitimate advice. Or just keep pretending and never improve.

>>80348240
>why would a random permutation of bits be a valid address on the stack?
It's not random though, it's garbage from the previous variable that was there.

What other basics can I learn lol? I know what the stack and heap are, so instead of just saying "muh go learn more" actually respond to my question perhaps?

>>80348282
The OP I responded to gave you an answer.
And what was "the previous variable that was there"? First you call people faggots or retarded, then you expect to be spoonfed.

>>80348500
You don't know what garbage values are? I think you need to revisit the basics

>>80348282
>it's not random though
have you turned off ASLR?
no?
then it's random.

>>80349348
The addresses themselves are random, but not the 'reason' they are there (a previous variable used them)

>>80348605
Mhm sure.
>>80349449
>The addresses themselves are random, but not the 'reason' they are there (a previous variable used them)
And what value did that hold, hm? You get where you fucked up yet? God you're so dense there is no substance in the known universe you could possibly float on.

>>80349630
it held no 'value' it held an address.
Sure you can say an address is a value, just as
much as you can say you like sucking my dick.

File: seethe.jpg (31 KB, 601x508)

31 KB JPG

>>80349630
Seethe n00b

>>80345121
>They had a a thing that integer consts up to 128 had pre-made objects in memory for them so that 10==10 was true but 150==150 was false
Python does the same thing
https://docs.python.org/3/c-api/long.html#c.PyLong_FromLong
>The current implementation keeps an array of integer objects for all integers between -5 and 256, when you create an int in that range you actually just get back a reference to the existing object

>>80345121
>no dereferencing going on

*ptr = ...

Literally dereferences ptr for the value assignment.

>>80349827
>it held an address
yes. a random address.
the R in ASLR stands for 'random'.
lol.

>>80345121
You're incorrect because the left hand of the assignment is the dereferenced pointer. You'd be correct if OP's code was:

int *p = 10;

Instead of

 int *p;
*p = 10;

Compiling OP's version with gcc 9.3.0 gives the warning

warning: 'p' is uninitialized in this function

Compiling the version you're thinking of gives the warning

warning: initialization of 'int *' from 'int' makes pointer from integer without a cast

Which would be fixed by casting to (int *) as you suggested.

>>80349449
>The addresses themselves are random
literally
>>80350090
you are retarded

>>80350127
address space layout RANDOMization.
come again?

File: 1613972208914.jpg (512 KB, 1541x1151)

512 KB JPG

>>80350204
Are you talking to yourself? Or...
just normal retardation i guess...

>>80350119
>int *p = 10;
This would make p point to the address 10 (0xA) though, right?

>>80350269
english is not my 1nd language
it looked like you were replying to me here
>>80350127

>>80350322
i was replying to
>>80350090
using as a reference
>>80349449

>>80350274
Correct, but the default cast of 10 in this case is int hence the warning. gcc will interpret the 10 as (int *) for you anyway but complain while doing so.

>>80350366
ah, i misinterpreted.