I could also use some help with autotools and the Perl test scripts <
I am a novice at both :) >
Here is a bit of test code I came up with. Do you think this is
necessary and or the right approach for testing with extreme values of
double and long long?
>From 4a6e84061fbf2180cf4efec45a215dd8af6481b1 Mon Sep 17 00:00:00 2001
From: Pete Dietl <petedi...@gmail.com>
Date: Mon, 9 Dec 2024 17:06:55 -0800
Subject: [PATCH] arith_tests
---
configure.ac | 34 ++++++++++++++++++++++++++++++
tests/config-flags.pm.in | 24 +++++++++++----------
tests/scripts/functions/add | 42 +++++++++++++++++++++++++++++++++++++
3 files changed, 89 insertions(+), 11 deletions(-)
create mode 100644 tests/scripts/functions/add
diff --git a/configure.ac b/configure.ac
index d9abc0d2..7b27dc21 100644
--- a/configure.ac
+++ b/configure.ac
@@ -555,6 +555,40 @@ AC_CONFIG_FILES([build.cfg tests/config-flags.pm \
# Put build.sh in the build directory so it's easy to find
AC_CONFIG_LINKS([build.sh:build.sh])
+AC_MSG_CHECKING([for LLONG_MAX and LLONG_MIN values])
+AC_LINK_IFELSE(
+ [AC_LANG_PROGRAM(
+[[
+#include <limits.h>
+#include <stdio.h>
+]],
+[[
+#ifdef LLONG_MAX
+ printf("%lld\n%lld\n", (long long)LLONG_MAX, (long long)LLONG_MIN);
+ return 0;
+#else
+ return 1;
+#endif
+]]
+ )],
+ [ # Linking succeeded
+ AC_MSG_RESULT([yes])
+ LLVALS=`./conftest`
+ rm -f conftest conftest.c
+ LONG_LONG_INT_MAX=`echo "$LLVALS" | sed -n '1p'`
+ LONG_LONG_INT_MIN=`echo "$LLVALS" | sed -n '2p'`
+ ],
+ [ # Linking failed
+ AC_MSG_RESULT([no])
+ LONG_LONG_INT_MAX=""
+ LONG_LONG_INT_MIN=""
+ ],
+AC_MSG_ERROR([This must succeed])
+)
+
+AC_SUBST([LONG_LONG_INT_MAX], [$LONG_LONG_INT_MAX])
+AC_SUBST([LONG_LONG_INT_MIN], [$LONG_LONG_INT_MIN])
+
# OK, do it!
AC_OUTPUT
diff --git a/tests/config-flags.pm.in b/tests/config-flags.pm.in
index 90cd9801..8e2a80f7 100644
--- a/tests/config-flags.pm.in
+++ b/tests/config-flags.pm.in
@@ -4,17 +4,19 @@
# during the tests.
%CONFIG_FLAGS = (
- AM_LDFLAGS => '@AM_LDFLAGS@',
- AR => '@AR@',
- CC => '@CC@',
- CFLAGS => '@CFLAGS@',
- CPP => '@CPP@',
- CPPFLAGS => '@CPPFLAGS@',
- GUILE_CFLAGS => '@GUILE_CFLAGS@',
- GUILE_LIBS => '@GUILE_LIBS@',
- LDFLAGS => '@LDFLAGS@',
- LIBS => '@LIBS@',
- USE_SYSTEM_GLOB => '@USE_SYSTEM_GLOB@'
+ AM_LDFLAGS => '@AM_LDFLAGS@',
+ AR => '@AR@',
+ CC => '@CC@',
+ CFLAGS => '@CFLAGS@',
+ CPP => '@CPP@',
+ CPPFLAGS => '@CPPFLAGS@',
+ GUILE_CFLAGS => '@GUILE_CFLAGS@',
+ GUILE_LIBS => '@GUILE_LIBS@',
+ LDFLAGS => '@LDFLAGS@',
+ LIBS => '@LIBS@',
+ USE_SYSTEM_GLOB => '@USE_SYSTEM_GLOB@',
+ LONG_LONG_INT_MAX => '@LONG_LONG_INT_MAX@',
+ LONG_LONG_INT_MIN => '@LONG_LONG_INT_MIN@'
);
1;
diff --git a/tests/scripts/functions/add b/tests/scripts/functions/add
new file mode 100644
index 00000000..3c5576f2
--- /dev/null
+++ b/tests/scripts/functions/add
@@ -0,0 +1,42 @@
+# -*-perl-*-
+
+use Math::BigInt;
+
+$description = "Test the add function.\n";
+
+$details = "Try various uses of add and ensure they all give the correct
+results.\n";
+
+
+$llong_max = get_config('LONG_LONG_INT_MAX');
+$llong_min = get_config('LONG_LONG_INT_MIN');
+
+run_make_test('# Identity
+.RECIPEPREFIX = >
+all:
+> @echo 0_1 $(add 0)
+> @echo 0_2 $(add 1)
+> @echo 0_3 $(add -4)
+> @echo 0_4 $(add ' . $llong_min . ')
+> @echo 0_5 $(add ' . $llong_max . ')
+', '', '0_1 0
+0_2 1
+0_3 -4
+0_4 ' . $llong_min . '
+0_5 ' . $llong_max . '
+');
+
+run_make_test('# Positive addition
+.RECIPEPREFIX = >
+all:
+> @echo 0_1 $(add 0,1)
+> @echo 0_2 $(add 1,0)
+> @echo 0_3 $(add 1, 2, 3,4)
+> @echo 0_4 $(add ' . $llong_min . ',1)
+', '', '0_1 1
+0_2 1
+0_3 10
+0_4 ' . Math::BigInt->new($llong_min)->badd(1)->bstr() . '
+');
+
+1;
--
2.43.0
On Mon, Dec 9, 2024 at 12:50 PM Paul Smith <psm...@gnu.org> wrote:
>
> On Mon, 2024-12-09 at 01:49 -0800, Pete Dietl wrote:
> > Mon, 9 Dec 2024 10:37:14 +0100, Jouke Witteveen wrote:
> > > What I remember from the original thread is that we first needed a
> > > good proposal. I'm afraid the existence of the implementation
> > > suggested now sidesteps the discussion on what functionality is
> > > actually desirable.
> >
> > Yeah I'm totally open to discussing a proposal further. I just felt
> > like having some working prototype implemented would be useful.
>
> In my opinion the patch is a proposal. If we decide it's best to do
> something completely different, then that's what we'll do. No doubt
> whatever we decide the user interface should be, at least big chunks of
> this code can be re-used anyway. Hopefully this won't be a shock to
> Pete :)
>
> I agree that the big open question from the previous discussion was,
> multiple individual functions versus one function that accepts a "math
> string". And if the latter, what is the syntax of that string. I
> liked the idea of a single function, as it seems simpler to use, but
> certainly it requires more decisions and discussion.
>
> > > I don't see the advantage in creating this special case. If someone
> > > wants the negation of a value, wouldn't they just write "-$V" instead
> > > of "$(sub $V)"?
> >
> > This feels similar to many concerns raised in the original thread
> > four years ago. In this particular case, "-$V" could result in two
> > consecutive minus signs, which is probably not what we want.
>
> I'm not sure why not, as long as the code handles it (I don't think
> this code does, admittedly). Can't you just consider --5 to be the
> same as -(-5), or 5, which is the same thing that $(sub -5) gives (I
> think)?
>
> > personally I still think arithmetic operators may be too much feature
> > creep altogether.
>
> I think I don't agree. For one thing we already have the concept of
> "numbers", because we provide the $(words ...) and, maybe less
> convincingly, $(word ...) functions. It's just that we can't really do
> much with them yet.
>
> I get the instinct to keep the language "clean" but in the end, people
> want to write build tools more than they want a clean language :).
> Being able to do basic math without having to shell out (not portable)
> or link with Guile or write some C code for a loadable module, doesn't
> seem like we're going out too far on the ledge.
>
