4

If I call srand in my main function, would it also affect results in my functions in other translation units?

anastaciu
  • 23,467
  • 7
  • 28
  • 53
Serket
  • 3,785
  • 3
  • 14
  • 45
  • 2
    It will affect the executed program that is built from several translation units.:) – Vlad from Moscow Aug 19 '20 at 12:12
  • 1
    @VladfromMoscow could you post it as an answer? – Serket Aug 19 '20 at 12:21
  • I do not really understand what you are meaning. What do you mean exactly with "affect results in my functions in other translation units"? Do you call functions defined in other TLUs in main? Could you provide an example for your thought model? – RobertS supports Monica Cellio Aug 19 '20 at 12:27
  • 3
    `srand` is provided by a library, and is linked with an executable (more specifically, one instance of the running executable, i.e. a process). An executable does not differentiate between the different source files/translation units. It will affect all future calls to `rand` in the executable, from whatever function calls it (`main` or otherwise). It will, however, not affect different processes. Therefore, calling `srand` in one process will not affect parent or sibling processes. It will affect children spawned subsequently. – TSG Aug 19 '20 at 12:39
  • 2
    Depends on the implementation. The Standard only mandates that the sequence of numbers generated with the same seed will be the same everytime... `return 4;` is a valid (though very low-quality) implementation of `rand()` --- [mandatory xkcd](https://xkcd.com/221/) --- if you add threads to the mix, then all bets are off! – pmg Aug 19 '20 at 12:46
  • 1
    @pmg Also [mandatory Dilbert](https://dilbert.com/strip/2001-10-25). – CiaPan Aug 19 '20 at 13:25

2 Answers2

2

Some small information from the source code of glibc.

srand is a weak alias for __srandom. (Source).

__srandom calls __srandom_r (Source).

__srandom_r is just updating the struct random_data passed to it, based on the seed. (Source)

rand(void) is just calling __random. (Source).

__random calls __random_r, passing the same structure, that was passed to __srandom_r. (Source).

__random_r then generates a random value from the passed struct. (Source).

So, to put it in a nutshell, a call to srand in your main-function will affect the random numbers in every other function, while your program runs, as the state is shared between all functions.

JCWasmx86
  • 3,473
  • 2
  • 11
  • 29
  • 3
    `rand` is generally not considered thread-safe nor reentrant (although it appears to be thread safe in the [glibc/random.c](https://github.com/lattera/glibc/blob/895ef79e04a953cac1493863bcae29ad85657ee1/stdlib/random.c#L293) file that you linked above). – vgru Aug 19 '20 at 12:48
  • 4
    More generally, how glibc does it (anything) is not reliably indicative of how other C libraries do it, except to the extent that glibc conforms to standards. – John Bollinger Aug 19 '20 at 12:52
  • @JohnBollinger You are right, but I assumed, people will know, that it will depend on the library and the standard conformance how `rand`/`srand` is implemented. Furthermore I used glibc, as it is found quite often on linux-systems – JCWasmx86 Aug 19 '20 at 12:54
  • 1
    @JCWasmx86, a lot of people will see this answer who *don't* know or understand that. Moreover, the OP did not specify a particular implementation, much less a glibc-based one in particular. Inasmuch as you *do* know that glibc details are not indicative of other implementations' details, then, it is unclear to me why you think this is responsive to the OP's question at all. – John Bollinger Aug 19 '20 at 13:00
1

C translation units bound the scope for some identifiers that are declared within, but not for any actual functions or objects belonging to a program. Thus, program state cannot be TU-specific, in the sense that it varies for different TUs.

Specifically, then, in any particular thread of a program exercising only defined behaviors, the random number seed set via srand() cannot appear differently to code in one TU than it would do at the same time to code in a different TU.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157