On Wed, Jul 03, 2024 at 05:07:10PM -0400, Thomas Dickey wrote:
> On Wed, Jul 03, 2024 at 11:03:09AM -0400, Boyuan Yang wrote:
> > X-Debbugs-CC: t...@invisible-island.net
> >
> > 在 2024-07-03星期三的 16:28 +0200，Kristian Nielsen写道：
> > > Package: mawk
> > > Version: 1.3.4.20240622-1
> > > Severity: normal
> > >
> > > Dear Maintainer,
> > >
> > > Running mawk produces wrong output from rand() on i386:
> > >
> > > $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> > > 0.158578
> > > $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> > > -0.276944
> > > $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> > > -0.387807
> > > $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> > > 0.470306
> > >
> > > The result of rand() should never be negative; and it should be
> > > deterministic after calling srand().
> > >
> > > This occurs on i386 (tested in sbuild --arch=i386 as part of debugging a
> > > reproducible build problem of package openscad).
> > >
> > > The expected output is the same value between 0 and 1, for example:
> > >
> > > $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> > > 0.559536
> > > $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> > > 0.559536
> > > $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> > > 0.559536
> > >
> > > The longer story, for completeness: I am the maintainer for openscad, and
> > > I
> > > see openscad sometimes failing to build reproducibly on (only) i386 during
> > > the past year. The root cause seems to be a test script that calls awk and
> > > behaves unexpectedly due to getting a negative number out of rand().
> > >
> > > The problem does not seem to occur on amd64 or arm64. Openscad doesn't
> > > build
> > > on armhf, so not sure if the problem in mawk is specific to i386 or may be
> > > specific to 32-bit for example.
> >
> > Ack. Reproducible on Debian Sid (mawk/1.3.4.20240622), not reproducible on
> > Debian 12
> > Bookworm (mawk/1.3.4.20200120). Likely a regression since 2020.
>
> odd - I can reproduce the problem, but what I'm seeing is older.
> I'll investigate further.
what I see is a problem with the configurable feature to use the system
srand/rand functions. Apparently the relatively new configure check
(and availability) for arc4random_stir/arc4random is not being scaled
properly.
The other bug that I see is that if the system rand/srand is used,
then srand has no effect in the script. That is a drawback to the
new/improved(?) arc4random functions: their developers chose to not support an
equivalent to srand.
This bug can be resolved by adding --enable-builtin-srand to the configure
options. The issue with repeatability has come up before - see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=63843
but the scaling is actually a bug. The configure script's choice of
random functions is a little awkward to work around other than by
setting the configure option (actually a small patch to the configure script
would work, by changing this line:
for cf_func in arc4random_stir/arc4random srandom/random
srand48/lrand48 srand/rand
to
for cf_func in srandom/random srand48/lrand48 srand/rand
but I seem to recall that doesn't mesh with dpkg-buildpackage (ymmv).
--
Thomas E. Dickey <dic...@invisible-island.net>
https://invisible-island.net
signature.asc
Description: PGP signature
