Jim Meyering wrote:
> I've been using config/srclist.txt, but if this annotation
> might help you, you're welcome to add it.
Thanks. Done.
Bruno
Bruno Haible <[EMAIL PROTECTED]> wrote:
> How about this, as a reminder that we want to look periodically at the
> changes done in glibc for this functionality? Or is config/srclist.txt
> your preferred way of remembering this?
Hi Bruno,
I've been using config/srclist.txt, but if this annotation
Hi Jim,
How about this, as a reminder that we want to look periodically at the
changes done in glibc for this functionality? Or is config/srclist.txt
your preferred way of remembering this?
Bruno
--- modules/random_r.orig 2008-11-02 19:06:59.0 +0100
+++ modules/random_r2008-11
> >> 2008-10-23 Simon Josefsson <[EMAIL PROTECTED]>
> >> Bruno Haible <[EMAIL PROTECTED]>
> >>
> >>* lib/stdlib.in.h (@GNULIB_RANDOM_R@): Include stdint.h.
> >>* modules/random_r (Depends-on): Add stdint.
>
> Looks fine. You're welcome to push it.
Applied.
Bruno
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> If you put a #include inside an extern "C" { ... } block, like this, it
>> yields
>> a syntax error in C++ mode on some platforms. Better put the #include
>> before the extern "C" block, like this:
>
> I lik
Bruno Haible <[EMAIL PROTECTED]> writes:
> If you put a #include inside an extern "C" { ... } block, like this, it yields
> a syntax error in C++ mode on some platforms. Better put the #include
> before the extern "C" block, like this:
I like the patch better. Jim?
/Simon
>
> 2008-10-23 Simon
Bruno Haible <[EMAIL PROTECTED]> writes:
> If you put a #include inside an extern "C" { ... } block, like this, it yields
> a syntax error in C++ mode on some platforms. Better put the #include
> before the extern "C" block, like this:
Ah, that's useful information to document somewhere. I pushe
Simon Josefsson wrote:
> --- a/lib/stdlib.in.h
> +++ b/lib/stdlib.in.h
> @@ -220,6 +220,8 @@ extern int putenv (char *string);
> #if @GNULIB_RANDOM_R@
> # if [EMAIL PROTECTED]@
>
> +# include
> +
> # ifndef RAND_MAX
> # define RAND_MAX 2147483647
> # endif
If you put a #include inside
Mingw32 results in:
./stdlib.h:260: error: expected declaration specifiers or '...' before 'int32_t'
The patch below should fix it, although untested.
/Simon
diff --git a/ChangeLog b/ChangeLog
index 47913b9..84e16d0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2008-10-23 Simon Jose
Hmph. I posted stale format-patch output.
FYI, the actual change *does* add the suggested
#include
to random_r.c.
Thanks for the thorough review.
Here's an incremental addressing the things you spotted.
I would have spotted the decl-after-stmt problems but for a bug in
gcc-4.3 and newer: http://thread.gmane.org/gmane.comp.gcc.bugs/228246
I'll squash it into the first one and apply shortly.
>From a07b7f3a6990
On Wed, Oct 22, 2008 at 10:06:28PM +0200, Jim Meyering wrote:
> I saw that there was no random-number generating module in gnulib,
> and certainly nothing reentrant, so took glibc's random_r.c and did this:
I need random() and drand48() to port some Unix program to Windows.
Win32 doesn't have eith
Jim Meyering <[EMAIL PROTECTED]> writes:
> I saw that there was no random-number generating module in gnulib,
> and certainly nothing reentrant, so took glibc's random_r.c and did this:
Actually there is gc-gnulib.c and gc-libgcrypt.c which both provides
random numbers, although they are intended
Jim Meyering wrote:
> I saw that there was no random-number generating module in gnulib,
> and certainly nothing reentrant, so took glibc's random_r.c and did this:
Very nice!
> diff --git a/doc/glibc-functions/random_r.texi
> b/doc/glibc-functions/random_r.texi
> index 50081b6..96f9384 100644
>
+0200
Subject: [PATCH] random_r: new module
* modules/random_r: New file.
* m4/random_r.m4: New file.
* lib/random_r.c: New file, from glibc.
* modules/random_r-tests: New file.
* tests/test-random_r.c: New file.
* lib/stdlib.in.h (srandom_r, initstate_r, setstate_r, random_r): Declare.
(RAND_MAX)
15 matches
Mail list logo