<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/74724>74724</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            About llvm::sys::Process::GetRandomNumber Setting a Random Seed
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          yype
      </td>
    </tr>
</table>

<pre>
    `llvm::sys::Process::GetRandomNumber` sets a random seed upon first use:

https://github.com/llvm/llvm-project/blob/2a951d78df633f2100a91b556f675efb4fec568b/llvm/lib/Support/Unix/Process.inc#L454

clang uses `GetRandomNumber` to generate unique path names for temporary files. This makes the return values of [rand()](https://man7.org/linux/man-pages/man3/rand_r.3.html) and [random()](https://man7.org/linux/man-pages/man3/random.3.html) without manually `srand` first non-deterministic later down the pipeline, e.g., in LLVM passes.

I came across an issue when I was expecting deterministic behaviors in calling `rand()` without calling `srand()` when developing LLVM passes since the `rand()` function is expected to be automatically seeded with 1 in this case. As analyzed before, calls to `rand()` are instead affected by a pre-seeded value set by `GetRandomNumber`, called by clang. Note that using opt to load the LLVM pass yields an expected and deterministic behavior since opt does not call `GetRandomNumber()`.

I can imagine the rationale behind setting a random seed, e.g., avoiding too many collisions when multiple instances of clang work together. However, I wonder if we should clarify somewhere in the documentation that developers (e.g., of LLVM passes) should always call `srand` first if they expect `rand` to work deterministically. Or should we do something like calling `srand(1)` to reset the seed before invoking the LLVM passes? This non-deterministic behavior could be surprising and confusing to some.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJykVcFy4zYM_Rr6golGlizJPviQ3YzbnUm3nabttUORkMWGIlWCsqN-fQeU4zqbXHZ6iSWFBN57eAAkkTk6xL2oPonqYSWn2Puwn-cRV63X817UubWnQZT3orynmZaHX4JXSJeXHzD-Kp32w9dpaDGIOgfCSCAhpM9AiBqm0TvoTKAIEyHfzB9EfvnbxzimaMVBFIejif3UZsoPojik7MvP3Rj8X6iiKA6t9a0oDoXcVWvdbHVXl2VXrPNc7tZtVdVd3VTYtZsOVVVv25s4hl-epnH0gQP97syLKA4XQplxShTl46ba3MJTVrojwyYQdf4B3-jhiA6DjAiTM39PCKOMPTg5IEHnA0QcRh9kmKEzFimD33pDMMhnJIg9QsA4BQcnaSck8B2I6hPLJ4qtKHaiehDF9q1Kg3RN5sMxkXLTy_LpbpRHpOW5FMWBY_wZsjLr42BFsQPp9Gts1vf_R_fDTfSzib2fIgzSTdLamfWixKPOL9V33t1pjBgG4wxFo8DKiAG0P7skxWhGtMahKD4DZseMf42Dx8c_foJREiFlt8X5AkoOCFIFTwTSgSGaEM49OvgCZ0mALyOqaNwR3uZtsZcn4wNxeCWt5SOizm90r_MrpZsD9M0JTqXxhNaPfOIGKZBxChOtd4G7yaloPAO-QETNTmoR5BT9IKNRSUPuH9QJCKwZa2TvKEmYwT1Tlnb-BzW02PmQZON7xLHeJZUBwTiKKDXIrluStjNIGAPeXTIlF3IT838-dPxrkuVy6o8MvvrIVCV3OOvgx8gYrJc6KXDVBWaDVqdiXYmzLz8uz0VDjqY9Eji_FOMjZK883znEgRnk0bilFkGy8NIiJzFOM9dkkDcz69aA8uSN5hPRe3b3DMpba8h4R4sBhslGM9pFXunU0sbL6Dj78AzRHzH2GDL40Z_xxGg_s0O90xjAdHBGoN5PVvOtYLoZyA947jHVLAHXXk0DupjwL1pfjIeBQBTbV7y-u7Uht-YltLRnOdNVwG-a03ScZr6U5WqfZcQlFm9qxPbM4OfwGvzMCBPq2LNY1jzjR42zvrgxegjIPmNuaU0sHgbjTv45yX3rGyRRHpbJ-X6KXO2iEpQWgaYwBpOsyO5S3nWLMeOCMVvpfal35U6ucL9u8vWuzndVuer3225bqm7TVHXdtNtNrXalRl2pelt2umnUyuyLvCjXRd6sN1VVldlGrWtstrhTTV625VZschyksRnvHR6kqzSW9s2mKTYrK1u0lJZuUTg8LzNLFAXv4LBPy66djiQ2uTUU6b8o0USL-_uWJ9J3LmZ4upp8-QxPiHo1Bbv_7v2b8PIiSHz-DQAA__-sNMWW">