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:
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
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
On 2023-11-13 09:42, Corinna Vinschen wrote:
Hi Pedro,
On Nov 11 18:29, Pedro Luis Castedo Cepeda wrote:
OK. It's not a newlib problem but a GLib one as it is relaying on common but
non-standard strftime implementation details.
I attach a short program more focused in g_date_strftime
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
Hi Mark,
On Nov 13 01:46, Mark Geisert wrote:
> Minor updates to profiler and gmondump, which share some code:
> - fix operation of error() so it actually works as intended
> - resize 4K-size auto buffer reservations to BUFSIZ (==1K)
> - remove trailing '\n' from 2nd arg on error() calls
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
Hi Pedro,
On Nov 11 18:29, Pedro Luis Castedo Cepeda wrote:
> OK. It's not a newlib problem but a GLib one as it is relaying on common but
> non-standard strftime implementation details.
>
> I attach a short program more focused in g_date_strftime implementation so
> it can be evaluated if it
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
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
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
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
Version 0.1.0-1 of python-rfc6555 has been uploaded to the Cygwin
distribution servers, and should be coming soon to a mirror near you.
python-rfc6555 is an implementation of the RFC 6555 "Happy Eyeballs"
algorithm for improving connection speeds from IPv4/IPv6 dual-stack
systems to some
Minor updates to profiler and gmondump, which share some code:
- fix operation of error() so it actually works as intended
- resize 4K-size auto buffer reservations to BUFSIZ (==1K)
- remove trailing '\n' from 2nd arg on error() calls everywhere
- provide consistent annotation of Windows error
On Sun, 12 Nov 2023, Mark Geisert wrote:
Hi folks,
I want to submit a patch that fixes 'profiler'. The Fixes: line of the patch
commentary should reference the original addition of profiler to the Cygwin
source tree.
Using the gitweb interface, the commit display of profiler.cc shows:
19 matches
Mail list logo
