rand_s () is a function available starting from Windows XP, which provides "secure" random number generation, without the need of a seed :
http://msdn.microsoft.com/en-us/library/sxtz2fa8%28VS.80%29.aspx
errno_t is the return type, and a simple typedef to int :
http://msdn.microsoft.com/en-us/library/ms235429%28v=vs.90%29.aspx
For the record, it's now required to compile libraries such as GLib (see https://bugzilla.gnome.org/show_bug.cgi?id=711043).
Please consider attached patch, which adds their definitions to the headers and exports the function symbol.
I don't see any major obstacle to supporting this, but I do have some issues with your patch, and with your assertion that this API is supported from WinXP onwards:
I don't see a ChangeLog entry, to support your patch.
If I run
~~~~
$ pexports msvcrt.dll | grep rand
~~~~
(in the appropriate system directory), on my WinXP VMs, (both day 0, and with SP2 applied), I see
randandsrand, but norand_s; aGetProcAddress()probe on MSVCRT.DLL confirms its absence, so I must conclude that it is not reliably supported by the standard system DLL, on WinXP. (I do see it on Win7).ISO C11 Annex K suggests that
errno_tshould be defined inerrno.h; MSDN gives us no clue where Microsoft might have defined it, prior to C11 adoption, butwinnt.hjust seems wrong, as does guarding it with_ERRCODE_DEFINED.MinGW currently complies with the POSIX requirement that
errnois defined as anint. ISO C11 specifieserrno_tto be a more descriptive typedef forerrnoitself, but that recommendation has yet to be adopted by MinGW; until it is, it seems more reasonable to me that we should consistently define the return type ofrand_s, (if we are to implement it), asint, matching the type oferrno.That said, the above is my opinion only, and I will not progress this without Earnie's agreement.