Thread: rand and srand

Wow...now that I test that, I guess I really don't understand memory allocation as much as I thought I did.

edit: TactX, your suggestion didn't work either. I get two completely identical outputs on two seperate runs of the same program, both runs occuring in the same second.

>Holy !@#$. Fine.
Okay then, be an ............... I'll remember how grateful you are to volunteers helping you in their spare time and refrain from ever helping you in the future.

*plonk!*

Originally Posted by pianorain

edit: TactX, your suggestion didn't work either. I get two completely identical outputs on two seperate runs of the same program, both runs occuring in the same second.

Yeah, I've tested it too and got the same results (testet on Linux/gcc and Windows/VS6).

But I can't really explain why the allocated memory is identical in two subsequent calls of the programm even if it is modified by the programm. What am i missing? Can anyone explain that, please?

Edit: typo

>Can anyone explain that, please?
Each process uses "fake" addresses, rather than the real addresses that the fake addresses are mapped to in physical (or virtual) memory. That's why the malloc solution wouldn't work well in practice. Can you be more specific about your second solution (code if possible)? Because it reeks of undefined behavior.

Originally Posted by Prelude

Because it reeks of undefined behavior.

Reeks? No, I'm fairly certain that it is. Here's what I tried:

Code:

#include <iostream>
#include <ctime>
#include <windows.h>

using std::endl;
using std::cout;

int main()
{
	unsigned int *p = new unsigned int;

/*
used just so that I have time to start the 
program twice in a second
*/
	Sleep(1000); 

/*
between incrementing an uninitialized value
and the actual pointer address,
surely something here is unique
*/
	cout << ++(*p) << " " << (int)p << " " << time(NULL) << endl;
	delete p;
	return 0;
}

I'd show you a sample output, except it's pretty meaningless. I think it's enough to say that in the few times I ran the program, it always showed the same values except for the time. When ran in the same second, everything was the same.

edit:
And yes, I'm sorry...that's C++.

Code:

#include <stdio.h>
#include <time.h>
#include <windows.h>

int main(void)
{
	unsigned int *p = malloc(sizeof(unsigned int));
	Sleep(1000);
	printf("%d %d %d\n",++(*p),(int)p,(unsigned long)time(NULL));
	fflush(stdin);
	free(p);
	return 0;
}

>Reeks? No, I'm fairly certain that it is.
Well, there's reasonable doubt, so I didn't want to jump to any conclusions.

Bottom line: The C standard does not guarantee a way to always get a unique value every time an instance of the same program is run, so it's impossible to create a 100% portable way to do it.

Why don't you start saying what you mean and limit your criteria a bit? Most operating systems have a way to get the process ID, even if it's not always through getpid(). Most operating systems also allow you to retrieve the time in ways more granular than seconds. Some operating systems (not many today though) don't use virtual memory so malloc() calls all return a unique address. Come up with a realistic scenario and you're likely to get more definitive responses.

Originally Posted by Prelude

>Can anyone explain that, please?
Each process uses "fake" addresses, rather than the real addresses that the fake addresses are mapped to in physical (or virtual) memory. That's why the malloc solution wouldn't work well in practice. Can you be more specific about your second solution (code if possible)? Because it reeks of undefined behavior.

O.K. the point about memory mapping is clear. What I thought of was (basically the same as pianorains):

Code:

int main(void){
	int *foo;
	foo=malloc(sizeof(int));	// we believe that malloc() will never fail
	++(*foo);
	printf("%d\n",*foo);
	free(foo);

	return 0;
}

It's not clear to me why *foo keeps always the same value when the program is called subsequently, even though it is incremented.

And btw. I can't see undefined behaviour here. I'm not accessing bad memory or anything else...

Enlighten me

Edit: typo

The memory that malloc() allocates is not guaranteed to be the same between runs even if malloc() is always returning the same fake address. You can't depend on *foo even pointing to the same real memory location as the previous instance (and if the program is running twice at the same time you're guaranteed that it's not the same physical memory being addressed.)

That's all clear to me. My question is why *foo keeps the same value all the time in subsequent calls. If the physical location of *foo would always be different then *foo should have different values (at least sometime). And if it's always the same physical location, *foo should be +1 for each call.

PS: My english is not the best. I've had almost no practice in the last years

>I can't see undefined behaviour here. I'm not accessing bad memory or anything else...
You're accessing an undeterminate value, which is undefined behavior. As for why it keeps the same value, I would imagine (speculating wildly) that it's due to the system cleaning up the memory for your process rather than just leaving it with old values from whatever ran last.

>And if it's always the same physical location, *foo should be +1 for each call.
The memory location that your pointer really points to is always going to be unique and different, even though each process might see the address as the same. If all foos point to the same real address then that would cause all sorts of trouble.

Originally Posted by Prelude

>I can't see undefined behaviour here. I'm not accessing bad memory or anything else...
You're accessing an undeterminate value, which is undefined behavior.

Uhmm, well. In this case I wanted this behaviour, so I cannot call it "undefined". But that's not the point...

Well for now I'll just accept that it is this way and believe that my OS cleans up my mess

For all intents and purposes, you cannot use malloc() to share memory between processes reliably. And it doesn't really matter what the OS does with free()d memory from your perspective, as long as it meets the requirements of the C standard. As long as you set the allocated memory to something useful before using it then it doesn't matter if the OS zeroes out unused memory or leaves it the same or even fills it in with the fibonacci sequence. You just can't depend on newly malloc()d memory containing anything you expect it to.

>Uhmm, well. In this case I wanted this behaviour, so I cannot call it "undefined".
Sure you can. Just because it happens to do what you want doesn't mean it's not hopelessly broken.