On Mon, Nov 13, 2023 at 10:17 PM Glenn Bogdan via Cygwin
wrote:
> SPAMSPAMSPAMSPAMSPAMSPAM
Completely off topic here, but is there an automated way to have the
mail server report these spams to the US FTC? Or is it simply not
worth the effort?
--
Problem reports: https://cygwin.com/proble
Hi ,
We work with businesses to provide a stable cloud based phone solution with
video conferencing and text messaging at a reduced rate from your
traditional telephone provider.
Its levels beyond what other platforms offer, with features like call
recording, call ID, tracking, linking to a CRM,
On Mon, Nov 13, 2023 at 10:33:48PM +0100, Bruno Haible via Cygwin wrote:
> Corinna Vinschen wrote:
> > I took a look into POSIX and I'm a bit puzzled now. From
> > https://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html
>
> Part of the confusion is that POSIX and ISO C have slightly
Corinna Vinschen wrote:
> I took a look into POSIX and I'm a bit puzzled now. From
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html
Part of the confusion is that POSIX and ISO C have slightly different
wording. This POSIX page says:
"The functionality described on this re
On Nov 13 19:04, Bruno Haible via Cygwin wrote:
> Corinna Vinschen wrote:
> > > And indeed glibc, musl libc, AIX, Android, and even NetBSD implement it
> > > in a
> > > multithread-safe way.
> >
> > Our code is from FreeBSD, originally. I checked the latest code from
> > FreeBSD. It doesn't loc
Corinna Vinschen wrote:
> > And indeed glibc, musl libc, AIX, Android, and even NetBSD implement it in a
> > multithread-safe way.
>
> Our code is from FreeBSD, originally. I checked the latest code from
> FreeBSD. It doesn't lock anything in random() and generates the same
> error when running
On 2023-11-13 09:12, Corinna Vinschen via Cygwin wrote:
On Nov 10 17:19, Bruno Haible via Cygwin wrote:
The function 'random' is, unlike 'rand', not marked as not MT-safe in POSIX
[1][2]. Thus it must be multithread-safe [3]:
"Each function defined in the System Interfaces volume of POSIX.1-2
IMHO:
> 2. A different sequence
The word "different" in this context is ambiguous: is it "unrelated" as a
generator, or is it "not the same" sequence of the actual numbers?
> I read this as the newlib technique being one way of correctly implementing
> rand/srand, no?
If the first, then yes
On Nov 13 15:38, Corinna Vinschen wrote:
> On Nov 13 15:25, Bruno Haible wrote:
> > Corinna Vinschen wrote:
> > > The rand() function would still not use locking but AFAICS that's
> > > not actually required by POSIX or ISO C.
> >
> > Correct. Those who want an MT-safe rand-like function need to u
Hi Bruno,
On Nov 10 17:19, Bruno Haible via Cygwin wrote:
> The function 'random' is, unlike 'rand', not marked as not MT-safe in POSIX
> [1][2]. Thus it must be multithread-safe [3]:
> "Each function defined in the System Interfaces volume of POSIX.1-2017
>is thread-safe unless explicitly s
On Nov 13 15:25, Bruno Haible wrote:
> Corinna Vinschen wrote:
> > The rand() function would still not use locking but AFAICS that's
> > not actually required by POSIX or ISO C.
>
> Correct. Those who want an MT-safe rand-like function need to use random(),
> not rand().
FTR, we have to differ he
Corinna Vinschen wrote:
> The rand() function would still not use locking but AFAICS that's
> not actually required by POSIX or ISO C.
Correct. Those who want an MT-safe rand-like function need to use random(),
not rand().
Bruno
--
Problem reports: https://cygwin.com/problems.html
FAQ:
[redirecting to the newlib mailing list]
This is long-standing code in newlib, not actually inside Cygwin.
On Nov 10 21:19, Bruno Haible via Cygwin wrote:
> ISO C 23 § 7.24.2.1 and 7.24.2.2 document how rand() and srand() are
> expected to behave. In particular:
> "The srand function uses the
13 matches
Mail list logo
