Re: cygwin.cygwin.narkive.com

[Backwoods BC via Cygwin]

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/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

cygwin.cygwin.narkive.com

[Glenn Bogdan via Cygwin]

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, etc.

May I send some information to you about our VOIP service?

Best regards,
Glenn Bogdan | TeleSpecialist

*24X7 OnTop LLC*
5859 McDovie Ave, Woodland Hills, CA 91367
Other Presence: MA | WA | CO | ID | DE | CT | UT | GA and FL
If you want to put an end to our email, please reply with RULE-OUT.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: rand is not ISO C compliant in Cygwin

[Glenn Strauss via Cygwin]

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 different
> wording. This POSIX page says:
>"The functionality described on this reference page is aligned
> with the ISO C standard. Any conflict between the requirements
> described here and the ISO C standard is unintentional. This
> volume of POSIX.1-2017 defers to the ISO C standard."
> 
> In ISO C 99 § 7.20.2, the only relevant sentence is:
> 
>   "The srand function uses the argument as a seed for a new sequence
>of pseudo-random numbers to be returned by subsequent calls to rand.
>If srand is then called with the same seed value, the sequence of
>pseudo-random numbers shall be repeated."
> 
> In ISO C 11 § 7.22.2 and ISO C 17 § 7.22.2, additionally two sentences
> were inserted:
> 
>   "The rand function is not required to avoid data races with other
>calls to pseudo-random sequence generation functions."
> 
>   "The srand function is not required to avoid data races with other
>calls to pseudo-random sequence generation functions."
> 
> ISO C 23 (which is still is draft state, but compared to the draft
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf I cannot
> see any change regarding rand() in the changes summary
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3148.doc) has the
> same wording.
> 
> POSIX does not have these two sentences, but instead has:
> 
>   "The rand() function need not be thread-safe."

I read the above as requiring *reentrancy*, but not *thread-safety*.

If multiple threads are accessing rand() and rand() accesses global
state, the global state should not get corrupted; the sequence
generated by rand() should remain intact.  Since thread-safety is not
guaranteed, is it theoretically possible that multiple threads enter
rand() at nearly the same time and both get the *same* random value in
the sequence.  (Whether or not that is undesirable behavior is
application-specific.)  A mutex can avoid this theoretical duplication,
as can using thread-local state (with difference seeds) instead of
global state.  If the seed value is the same in multiple threads using
thread-local state, the sequence of random values generated in each
thread will be repeated in each thread.  This may be surprising behavior
to some when srand() is called, then multiple threads spawned, and each
thread subsequently gets the same sequence of values from rand().

If the global state is a single item and atomics can be used to access
and update the global state, then an implemntation can use atomics
instead of mutexes to achieve thread-safety, which is allowed by the
standards, but not required for rand().

Cheers, Glenn

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: rand is not ISO C compliant in Cygwin

[Bruno Haible via Cygwin]

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 reference page is aligned
with the ISO C standard. Any conflict between the requirements
described here and the ISO C standard is unintentional. This
volume of POSIX.1-2017 defers to the ISO C standard."

In ISO C 99 § 7.20.2, the only relevant sentence is:

  "The srand function uses the argument as a seed for a new sequence
   of pseudo-random numbers to be returned by subsequent calls to rand.
   If srand is then called with the same seed value, the sequence of
   pseudo-random numbers shall be repeated."

In ISO C 11 § 7.22.2 and ISO C 17 § 7.22.2, additionally two sentences
were inserted:

  "The rand function is not required to avoid data races with other
   calls to pseudo-random sequence generation functions."

  "The srand function is not required to avoid data races with other
   calls to pseudo-random sequence generation functions."

ISO C 23 (which is still is draft state, but compared to the draft
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf I cannot
see any change regarding rand() in the changes summary
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3148.doc) has the
same wording.

POSIX does not have these two sentences, but instead has:

  "The rand() function need not be thread-safe."

> RATIONAL
> 
>   The ISO C standard rand() and srand() functions allow per-process
>   ^ (not requires)
> 
>   pseudo-random streams shared by all threads.

Indeed, "requires" would fit better here, IMO, because the texts of
both ISO C and POSIX have multithreading in mind and still talk about
"subsequent calls to rand" — which makes a reference to time, but not
to threads.

> Ok, so, *iff* rand/srand share per-process state, then they have to
> use locking to prevent MT interference.

... if the implementor wants to prevent MT interference (which both
ISO C and POSIX allows).

> POSIX continues:
> 
>   With regard to rand(), there are two different behaviors that may be
>   wanted in a multi-threaded program:
> 
>   1. A single per-process sequence of pseudo-random numbers that is
>  shared by all threads that call rand()
> 
>   2. A different sequence of pseudo-random numbers for each thread that
>  calls rand()
> ^^

This paragraph continues after the two items:
   "This is provided by the modified thread-safe function based on whether
the seed value is global to the entire process or local to each thread."

My understanding of this paragraph is:
  - If an application wants 1., they can use rand_r with SEED pointing
to a global variable.
  - If an application wants 2., they can use rand_r with SEED pointing
to a per-thread variable.

> I read this as the newlib technique being one way of correctly
> implementing rand/srand, no?

I don't think so. The critical sentence is the one with
"subsequent calls to rand".

Bruno




-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: random is not multithread-safe in Cygwin

[Corinna Vinschen via Cygwin]

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 lock anything in random() and generates the same
> > error when running the same test app.
> > 
> > Why is that ok for FreeBSD?
> 
> It is not OK in FreeBSD, either. This is what I noted in the Gnulib manual:
> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=doc/posix-functions/random.texi
> 
> But it is MT-safe in NetBSD (in the '#ifndef SMALL_RANDOM' branch):
> http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/stdlib/random.c?rev=1.7=text/x-cvsweb-markup

Ok, I pushed a patch(*) to make the random(3) functions thread-safe, more
or less following NetBSDs lead.  If you get a chance, give the next test
release cygwin-3.5.0-0.459.gd223f095905a a try.

The patch will be part of the next release, 3.4.10.


Thanks,
Corinna

(*) https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;h=06e463223b95

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH] fix(libc): Fix handle of %E & %O modifiers at end of format string

[Brian Inglis]

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 implementation so
it can be evaluated if it worths addressing this corner case.


Tricky.  I wonder what the GLib test is actually trying to accomplish.

POSIX has this to say:

   RETURN VALUE
 If the total number of resulting bytes including the  terminating
 null byte  is not more than maxsize, these functions shall return
 the number of bytes placed into the array pointed to by s, not
 including the  terminating NUL character. Otherwise, 0 shall be
 returned and the contents of the array are unspecified.

   ERRORS
 No errors are defined.

But, and that's the big problem, POSIX does *not* provide for the
error case, because it doesn't allow an error like using an incorrect
format string to occur.  Using an incorrect or undefined format code
is just not part of the standard.

And the Linux man page has an interesting extension to the above
POSIX RETURN VALUE section:

 Note  that  the  return value 0 does not necessarily indicate an
 error.  For example, in many locales %p yields an empty string.  An
 empty  format string will likewise yield an empty string.

and additionally in the BUGS section:

 If the output string would exceed max bytes, errno is  not  set.
 This makes it impossible to distinguish this error case from cases
 where the format  string  legitimately  produces  a  zero-length
 output  string.  POSIX.1-2001 does not specify any errno settings
 for strftime().

So the below case tested by GLib is entirely out of scope of the
standard.


C 2023 draft says:

"7.29.3.5 The strftime function
...
Returns
8   If the total number of resulting characters including the terminating null
character is not more than maxsize, the strftime function returns the number of 
characters placed into the array pointed to by s not including the terminating 
null character. Otherwise, zero is returned and the members of the array have an 
indeterminate representation."


GLib is not tested under Cygwin/newlib only VS2017 and Msys2-Mingw32 native 
Windows:


https://gitlab.gnome.org/GNOME/glib/-/issues/2604

https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2480/diffs

https://gitlab.gnome.org/malureau/glib/-/pipelines/366193/test_report

[may need to navigate not always obvious "tabs"]

Should raise a followup issue there - and point out it is not a Win32 issue - it 
is another POSIX alternate libc issue - hosted under a Win64 environment.


--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Re: random is not multithread-safe in Cygwin

[Bruno Haible via Cygwin]

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 the same test app.
> 
> Why is that ok for FreeBSD?

It is not OK in FreeBSD, either. This is what I noted in the Gnulib manual:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=doc/posix-functions/random.texi

But it is MT-safe in NetBSD (in the '#ifndef SMALL_RANDOM' branch):
http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/stdlib/random.c?rev=1.7=text/x-cvsweb-markup

Bruno




-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: random is not multithread-safe in Cygwin

[Brian Inglis via Cygwin]

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-2017
is thread-safe unless explicitly stated otherwise."
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 the same test app.
Why is that ok for FreeBSD?


It appears that random(3) is intended to provide a single random series during 
execution of a program with simple needs; behaviour is not reproducible when 
threaded, says POSIX, newlib, and Linux (below).


From POSIX The Open Group Base Specifications Issue 7, 2018 edition IEEE Std 
1003.1-2017 Volume 2: System Interfaces and initstate(3p) to which random(3p) 
refers and defers but does not link or .so:


"NAME
   random — generate pseudo‐random number

SYNOPSIS
   #include 

   long random(void);

DESCRIPTION
   Refer to initstate()."

* That's all folks!

"NAME
initstate, random, setstate, srandom - pseudo-random number functions
...
APPLICATION USAGE
...
Threaded applications should use erand48(), nrand48(), or jrand48() instead of 
random() when an independent random number sequence in multiple threads is 
required."


From newlib:

"NAME
   random, srandom - pseudo-random numbers
...
NOTES
   random and srandom are unsafe for multi-threaded applications.

   _XOPEN_SOURCE may be any value >= 500.

PORTABILITY
   random is required by XSI. This implementation uses the same algorithm 
as rand."


* Newlib, and presumably FreeBSD, do not support initstate, setstate, or > 8 
(for amd64/x86_64) bytes state.


From man-pages-linux random(3):

"CAVEATS
...
   The random() function should not be used in multithreaded programs where 
reproducible behavior is required.

   Use random_r(3) for that purpose."

* As usual, random_r(3) requires the caller to provide an initialized state 
vector buffer (of 8-256 bytes), allowing the caller to decide the amount of 
randomness and scope of the random series, and possibly call initstate_r(3), to 
control the seed.


--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH] Cygwin: Fix profiler error() definition and usage

[Corinna Vinschen]

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 everywhere
> - provide consistent annotation of Windows error number displays
> 
> Fixes: 9887fb27f6126 ("Cygwin: New tool: profiler")
> Fixes: 087a3d76d7335 ("Cygwin: New tool: gmondump")
> Signed-off-by: Mark Geisert 

Looks good basically, but I noticed some minor problem already
in the former version of this code:

> @@ -650,7 +652,7 @@ ctrl_c (DWORD)
>static int tic = 1;
>  
>if ((tic ^= 1) && !GenerateConsoleCtrlEvent (CTRL_C_EVENT, 0))
> -error (0, "couldn't send CTRL-C to child, win32 error %d\n",
> +error (0, "couldn't send CTRL-C to child, Windows error %d",
> GetLastError ());
>return TRUE;

GetLastError returns a DWORD == unsigned int. %u would be the
right format specifier.  Care to fix that, too?


Thanks,
Corinna

RE: [EXTERNAL] Re: rand is not ISO C compliant in Cygwin

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin]

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; but if the second, then no.

The problem with the first approach is, however, is the inability to adequately 
randomize your code (e.g. for testing).

You call srand() in the main() thread, and then spawn threads thinking they 
will inherit the randomization; but in fact, they all start off the same number 
sequence, regardless.

Anton Lavrentiev
Contractor NIH/NLM/NCBI


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH] fix(libc): Fix handle of %E & %O modifiers at end of format string

[Corinna Vinschen]

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 worths addressing this corner case.

Tricky.  I wonder what the GLib test is actually trying to accomplish.

POSIX has this to say:

  RETURN VALUE
If the total number of resulting bytes including the  terminating
null byte  is not more than maxsize, these functions shall return
the number of bytes placed into the array pointed to by s, not
including the  terminating NUL character. Otherwise, 0 shall be
returned and the contents of the array are unspecified.

  ERRORS
No errors are defined.

But, and that's the big problem, POSIX does *not* provide for the
error case, because it doesn't allow an error like using an incorrect
format string to occur.  Using an incorrect or undefined format code
is just not part of the standard.

And the Linux man page has an interesting extension to the above
POSIX RETURN VALUE section:

Note  that  the  return value 0 does not necessarily indicate an
error.  For example, in many locales %p yields an empty string.  An
empty  format string will likewise yield an empty string.

and additionally in the BUGS section:

If the output string would exceed max bytes, errno is  not  set.
This makes it impossible to distinguish this error case from cases
where the format  string  legitimately  produces  a  zero-length
output  string.  POSIX.1-2001 does not specify any errno settings
for strftime().

So the below case tested by GLib is entirely out of scope of the
standard.


Corinna

Re: rand is not ISO C compliant in Cygwin

[Corinna Vinschen via Cygwin]

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 use random(),
> > not rand().

I took a look into POSIX and I'm a bit puzzled now.  From
https://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html

RATIONAL

  The ISO C standard rand() and srand() functions allow per-process
  ^ (not requires)

  pseudo-random streams shared by all threads. Those two functions need
  not change, but there has to be mutual-exclusion that prevents
  interference between two threads concurrently accessing the random
  number generator.

Ok, so, *iff* rand/srand share per-process state, then they have to
use locking to prevent MT interference.  POSIX continues:

  With regard to rand(), there are two different behaviors that may be
  wanted in a multi-threaded program:

  1. A single per-process sequence of pseudo-random numbers that is
 shared by all threads that call rand()

  2. A different sequence of pseudo-random numbers for each thread that
 calls rand()
^^

I read this as the newlib technique being one way of correctly
implementing rand/srand, no?


Corinna


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: random is not multithread-safe in Cygwin

[Corinna Vinschen via Cygwin]

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 stated otherwise."
> 
> 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 the same test app.

Why is that ok for FreeBSD?


Corinna




> 
> On Cygwin 2.9.0 and 3.4.6, it is not multithread-safe.
> 
> How to reproduce:
> 1. Compile the attached program.
>$ x86_64-pc-cygwin-gcc foo.c
> 2. Run it.
>$ ./a.exe
> Expected: No output.
> Actual: Output such as
>   Expected value #367 not found in multithreaded results.
> 
> [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/initstate.html
> [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html
> [3] 
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_407

> /* Multithread-safety test for random().
>Copyright (C) 2023 Free Software Foundation, Inc.
> 
>This program is free software: you can redistribute it and/or modify
>it under the terms of the GNU General Public License as published by
>the Free Software Foundation, either version 3 of the License, or
>(at your option) any later version.
> 
>This program is distributed in the hope that it will be useful,
>but WITHOUT ANY WARRANTY; without even the implied warranty of
>MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>GNU General Public License for more details.
> 
>You should have received a copy of the GNU General Public License
>along with this program.  If not, see .  */
> 
> /* Written by Bruno Haible , 2023.  */
> 
> /* Whether to help the scheduler through explicit yield().
>Uncomment this to see if the operating system has a fair scheduler.  */
> #define EXPLICIT_YIELD 1
> 
> /* Number of simultaneous threads.  */
> #define THREAD_COUNT 4
> 
> /* Number of random() invocations operations performed in each thread.
>This value is chosen so that the unit test terminates quickly.
>To reliably determine whether a random() implementation is 
> multithread-safe,
>set REPEAT_COUNT to 100 and run the test 100 times:
>  $ for i in `seq 100`; do ./test-random-mt; done
>  */
> #define REPEAT_COUNT 100
> 
> /* Specification.  */
> #include 
> 
> #include 
> #include 
> #include 
> 
> #if EXPLICIT_YIELD
> # include 
> # define yield() sched_yield ()
> #else
> # define yield()
> #endif
> 
> /* This test runs REPEAT_COUNT invocations of random() in each thread and 
> stores
>the result, then compares the first REPEAT_COUNT among these
>  THREAD_COUNT * REPEAT_COUNT
>random numbers against a precomputed sequence with the same seed.  */
> 
> static void *
> random_invocator_thread (void *arg)
> {
>   long *storage = (long *) arg;
>   int repeat;
> 
>   for (repeat = 0; repeat < REPEAT_COUNT; repeat++)
> {
>   storage[repeat] = random ();
>   yield ();
> }
> 
>   return NULL;
> }
> 
> int
> main ()
> {
>   unsigned int seed = 19891109;
> 
>   /* First, get the expected sequence of random() results.  */
>   srandom (seed);
>   long *expected = (long *) malloc (REPEAT_COUNT * sizeof (long));
>   assert (expected != NULL);
>   {
> int repeat;
> for (repeat = 0; repeat < REPEAT_COUNT; repeat++)
>   expected[repeat] = random ();
>   }
> 
>   /* Then, run REPEAT_COUNT invocations of random() each, in THREAD_COUNT
>  separate threads.  */
>   pthread_t threads[THREAD_COUNT];
>   long *thread_results[THREAD_COUNT];
>   srandom (seed);
>   {
> int i;
> for (i = 0; i < THREAD_COUNT; i++)
>   {
> thread_results[i] = (long *) malloc (REPEAT_COUNT * sizeof (long));
> assert (thread_results[i] != NULL);
>   }
> for (i = 0; i < THREAD_COUNT; i++)
>   assert (pthread_create ([i], NULL, random_invocator_thread, 
> thread_results[i]) == 0);
>   }
> 
>   /* Wait for the threads to terminate.  */
>   {
> int i;
> for (i = 0; i < THREAD_COUNT; i++)
>   assert (pthread_join (threads[i], NULL) == 0);
>   }
> 
>   /* Finally, determine whether the threads produced the same sequence of
>  random() results.  */
>   {
> int expected_index;
> int result_index[THREAD_COUNT];
> int i;
> 
> for (i = 0; i < THREAD_COUNT; i++)
>   result_index[i] = 0;
> 
> for (expected_index = 0; expected_index < REPEAT_COUNT; expected_index++)
>   {
> long expected_value = expected[expected_index];
> 
> for (i = 0; i < THREAD_COUNT; i++)
>   {
> if (thread_results[i][result_index[i]] == expected_value)
>   {
>  

Re: rand is not ISO C compliant in Cygwin

[Corinna Vinschen via Cygwin]

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 here between plain newlib targets and Cygwin.

While Cygwin comes with it's own, table-based random() implementation
taken from BSD back in 2007, newlib's random is basically equivalent to
rand() for the sake of bare-metal and other targets with high memory
pressure.  We shouldn't change the latter since multi-threading
compliance is usually not much of a problem for that target audience.


Corinna


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: rand is not ISO C compliant in Cygwin

[Bruno Haible via Cygwin]

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:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: rand is not ISO C compliant in Cygwin

[Corinna Vinschen via Cygwin]

[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 argument as a seed for a new sequence
>of pseudo-random numbers to be returned by subsequent calls to rand.
>If srand is then called with the same seed value, the sequence of
>pseudo-random numbers shall be repeated. ...
>The srand function is not required to avoid data races with other
>calls to pseudo-random sequence generation functions. ..."
> 
> The two attached programs call srand() in one thread and then rand()
> in another thread. There is no data race, since the second thread
> is only created after the call to srand() has returned. The behaviour
> in Cygwin is that the values in the second thread ignore the srand()
> call done in the first thread.

Struct _reent is a kind of per-execution unit datastructure.  This
could be independent code blocks in bare-metal code, or threads in
Cygwin et al.  So the _reent struct also holds the seed state of the
rand and rand48 generators for a good reason.

But that's only half the picture, because newlib actually has two ways
of storing _reent data:  Either in a pre-thread struct _reent, or (if
_REENT_THREAD_LOCAL is defined) as per-member thread_local storage.

Theoretically, this could be easily fixed:

- Either we maintain a global struct _reent which could be used
  from rand().

- Or, in case of _REENT_THREAD_LOCAL, by making the rand48 data globally
  available as static data, rather than as thread_local data.

The rand() function would still not use locking but AFAICS that's
not actually required by POSIX or ISO C.

However, this is something I don't want to decide single-handedly,
so I'm asking how to go forward on the newlib ML.

As far as Cygwin alone is concerned, a patch like this one would suffice:

diff --git a/newlib/libc/stdlib/rand.c b/newlib/libc/stdlib/rand.c
index ba9cc80f2b21..2b48e7a725b1 100644
--- a/newlib/libc/stdlib/rand.c
+++ b/newlib/libc/stdlib/rand.c
@@ -58,6 +58,12 @@ on two different systems.
 #include 
 #include 
 
+#ifdef __CYGWIN__
+#define _RAND_REENT_GLOBAL_REENT
+#else
+#define _RAND_REENT_REENT
+#endif
+
 #ifdef _REENT_THREAD_LOCAL
 _Thread_local unsigned long long _tls_rand_next = 1;
 #endif
@@ -65,7 +71,7 @@ _Thread_local unsigned long long _tls_rand_next = 1;
 void
 srand (unsigned int seed)
 {
-  struct _reent *reent = _REENT;
+  struct _reent *reent = _RAND_REENT;
 
   _REENT_CHECK_RAND48(reent);
   _REENT_RAND_NEXT(reent) = seed;
@@ -74,7 +80,7 @@ srand (unsigned int seed)
 int
 rand (void)
 {
-  struct _reent *reent = _REENT;
+  struct _reent *reent = _RAND_REENT;
 
   /* This multiplier was obtained from Knuth, D.E., "The Art of
  Computer Programming," Vol 2, Seminumerical Algorithms, Third




> 
> How to reproduce the bug:
> 
> $ x86_64-pc-cygwin-gcc -Wall rand-in-posix-thread.c
> $ ./a
> 
> or
> 
> $ x86_64-pc-cygwin-gcc -Wall rand-in-isoc-thread.c
> $ ./a
> 
> Expected output:
> 
> Value from main thread: 1583559764
> Value from separate thread: 1583559764
> 
> Actual output:
> 
> Value from main thread: 1583559764
> Value from separate thread: 1481765933
> 

> #include 
> #include 
> #include 
> #include 
> 
> static void *
> rand_invocator_thread (void *arg)
> {
>   printf ("Value from separate thread: %d\n", rand ());
>   return NULL;
> }
> 
> int
> main ()
> {
>   unsigned int seed = 19891109;
> 
>   srand (seed);
>   printf ("Value from main thread: %d\n", rand ());
>   srand (seed);
>   pthread_t t;
>   assert (pthread_create (, NULL, rand_invocator_thread, NULL) == 0);
>   assert (pthread_join (t, NULL) == 0);
> 
>   return 0;
> }

> #include 
> #include 
> #include 
> #include 
> 
> static int
> rand_invocator_thread (void *arg)
> {
>   printf ("Value from separate thread: %d\n", rand ());
>   return 0;
> }
> 
> int
> main ()
> {
>   unsigned int seed = 19891109;
> 
>   srand (seed);
>   printf ("Value from main thread: %d\n", rand ());
>   srand (seed);
>   thrd_t t;
>   assert (thrd_create (, rand_invocator_thread, NULL) == thrd_success);
>   assert (thrd_join (t, NULL) == thrd_success);
> 
>   return 0;
> }

> 
> -- 
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

New: python-rfc6555 0.1.0-1

[Adam Dinwoodie via Cygwin-announce]

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 IPv4-only hosts.

This release includes the following Cygwin packages:

- python3-rfc6555
- python38-rfc6555
- python39-rfc6555

Enjoy!

Adam

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look at the 
"List-Unsubscribe: " tag in the email header of this message. It will be in the 
format:

List-Unsubscribe: , 


The easiest unsubscribe method is to visit the web page associated with the 
mailing list as seen above, and click Unsubscribe.

Alteratively, you can send email to the list server using the address given in 
the mailto: above.

If you need more information on unsubscribing, start reading here:

https://sourceware.org/lists.html#unsubscribe

Please read *all* of the information on unsubscribing that is available 
starting at this URL.

[PATCH] Cygwin: Fix profiler error() definition and usage

[Mark Geisert]

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 number displays

Fixes: 9887fb27f6126 ("Cygwin: New tool: profiler")
Fixes: 087a3d76d7335 ("Cygwin: New tool: gmondump")
Signed-off-by: Mark Geisert 

---
 winsup/utils/gmondump.c  |  8 ---
 winsup/utils/profiler.cc | 46 +---
 2 files changed, 29 insertions(+), 25 deletions(-)

diff --git a/winsup/utils/gmondump.c b/winsup/utils/gmondump.c
index 16b99594a..3472a147e 100644
--- a/winsup/utils/gmondump.c
+++ b/winsup/utils/gmondump.c
@@ -58,7 +58,7 @@ void
 note (const char *fmt, ...)
 {
   va_list args;
-  charbuf[4096];
+  charbuf[BUFSIZ];
 
   va_start (args, fmt);
   vsprintf (buf, fmt, args);
@@ -72,7 +72,7 @@ void
 warn (int geterrno, const char *fmt, ...)
 {
   va_list args;
-  charbuf[4096];
+  charbuf[BUFSIZ];
 
   va_start (args, fmt);
   sprintf (buf, "%s: ", pgm);
@@ -92,10 +92,12 @@ void __attribute__ ((noreturn))
 error (int geterrno, const char *fmt, ...)
 {
   va_list args;
+  charbuf[BUFSIZ];
 
   va_start (args, fmt);
-  warn (geterrno, fmt, args);
+  vsprintf (buf, fmt, args);
   va_end (args);
+  warn (geterrno, "%s", buf);
 
   exit (1);
 }
diff --git a/winsup/utils/profiler.cc b/winsup/utils/profiler.cc
index 520e29d12..b2e26d663 100644
--- a/winsup/utils/profiler.cc
+++ b/winsup/utils/profiler.cc
@@ -130,7 +130,7 @@ void
 note (const char *fmt, ...)
 {
   va_list args;
-  charbuf[4096];
+  charbuf[BUFSIZ];
 
   va_start (args, fmt);
   vsprintf (buf, fmt, args);
@@ -144,7 +144,7 @@ void
 warn (int geterrno, const char *fmt, ...)
 {
   va_list args;
-  charbuf[4096];
+  charbuf[BUFSIZ];
 
   va_start (args, fmt);
   sprintf (buf, "%s: ", pgm);
@@ -164,10 +164,12 @@ void __attribute__ ((noreturn))
 error (int geterrno, const char *fmt, ...)
 {
   va_list args;
+  charbuf[BUFSIZ];
 
   va_start (args, fmt);
-  warn (geterrno, fmt, args);
+  vsprintf (buf, fmt, args);
   va_end (args);
+  warn (geterrno, "%s", buf);
 
   exit (1);
 }
@@ -263,15 +265,15 @@ start_profiler (child *c)
 note ("*** start profiler thread on pid %lu\n", (ulong) c->pid);
   c->context = (CONTEXT *) calloc (1, sizeof (CONTEXT));
   if (!c->context)
-error (0, "unable to allocate CONTEXT buffer\n");
+error (0, "unable to allocate CONTEXT buffer");
   c->context->ContextFlags = CONTEXT_CONTROL;
   c->hquitevt = CreateEvent (NULL, TRUE, FALSE, NULL);
   if (!c->hquitevt)
-error (0, "unable to create quit event\n");
+error (0, "unable to create quit event");
   c->profiling = 1;
   c->hprofthr = CreateThread (NULL, 0, profiler, (void *) c, 0, );
   if (!c->hprofthr)
-error (0, "unable to create profiling thread\n");
+error (0, "unable to create profiling thread");
 
   /* There is a temptation to raise the execution priority of the profiling
* threads.  Don't do this, or at least don't do it this way.  Testing
@@ -321,7 +323,7 @@ dump_profile_data (child *c)
 
   fd = open (filename, O_CREAT | O_TRUNC | O_WRONLY | O_BINARY);
   if (fd < 0)
-error (0, "dump_profile_data: unable to create %s\n", filename);
+error (0, "dump_profile_data: unable to create %s", filename);
 
   memset (, 0, sizeof (hdr));
   hdr.lpc = s->textlo;
@@ -427,7 +429,7 @@ add_thread (DWORD pid, DWORD tid, HANDLE h, WCHAR *name)
   child *c = get_child (pid);
 
   if (!c)
-error (0, "add_thread: pid %lu not found\n", (ulong) pid);
+error (0, "add_thread: pid %lu not found", (ulong) pid);
 
   thread_list *t = (thread_list *) calloc (1, sizeof (thread_list));
   t->tid = tid;
@@ -444,7 +446,7 @@ remove_thread (DWORD pid, DWORD tid)
   child *c = get_child (pid);
 
   if (!c)
-error (0, "remove_thread: pid %lu not found\n", (ulong) pid);
+error (0, "remove_thread: pid %lu not found", (ulong) pid);
 
   thread_list *t = c->threads;
   while (t)
@@ -463,7 +465,7 @@ remove_thread (DWORD pid, DWORD tid)
   t = t->next;
 }
 
-  error (0, "remove_thread: pid %lu tid %lu not found\n",
+  error (0, "remove_thread: pid %lu tid %lu not found",
  (ulong) pid, (ulong) tid);
 }
 
@@ -475,9 +477,9 @@ read_child (void *buf, SIZE_T size, void *addr, HANDLE h)
   if (debugging)
 note ("read %d bytes at %p from handle %d\n", size, addr, h);
   if (0 == ReadProcessMemory (h, addr, buf, size, ))
-error (0, "read_child: failed\n");
+error (0, "read_child: failed");
   if (len != size)
-error (0, "read_child: asked for %d bytes but got %d\n", size, len);
+error (0, "read_child: asked for %d bytes but got %d", size, len);
 }
 
 IMAGE_SECTION_HEADER *
@@ -497,7 +499,7 @@ find_text_section (LPVOID base, HANDLE h)
   IMAGE_NT_HEADERS *inth = (IMAGE_NT_HEADERS *) ptr;
   read_child ((void *) 

Re: Which git hash to supply on Fixes: line -- never mind

[Mark Geisert]

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:
authorMark Geisert   2021-07-15 21:49:55 -0700
committer Jon Turney  2021-07-19 13:28:37 +0100
commit  9bd6c0b2b1081ae72d8273038309887fb27f6126 (patch)
tree360d7d3cc748683eb9e63729a7e52a62012730e4 /winsup/utils/profiler.cc
parent  Cygwin: cfsetspeed: allow speed to be a numerical baud rate (diff)

Do I use the last 13 nibbles of the "commit" hash or the "tree" hash?


Never mind; I've figured it out.  It's the "commit" hash, which I 
determined by 'git log profiler.cc'.  Obvious in hindsight.

Cheers,

..mark