emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/2] Add module functions to convert from and to big integers


From: Philipp Stephani
Subject: Re: [PATCH 2/2] Add module functions to convert from and to big integers.
Date: Wed, 24 Apr 2019 19:28:32 +0200

Am Mi., 24. Apr. 2019 um 19:23 Uhr schrieb Eli Zaretskii <address@hidden>:
>
> > From: Philipp Stephani <address@hidden>
> > Date: Wed, 24 Apr 2019 19:15:13 +0200
> > Cc: Paul Eggert <address@hidden>, Emacs developers <address@hidden>,
> >       Philipp Stephani <address@hidden>
> >
> > > > 1. Don't support these functions at all if GMP isn't available (i.e.
> > > > signal an error unconditionally)
> > > > 2. Add another preprocessor macro that would stop emacs-module.h from
> > > > including gmp.h.
> > > >
> > > > (1) seems a bit easier and cleaner, but means that we wouldn't support
> > > > these functions if Emacs isn't compiled with GMP support.
> > >
> > > I don't think I understand (2): how would you declare GMP-related data
> > > types used in emacs-module.c, if you don't include gmp.h?
> >
> > It would require the user (or rather, Emacs) to include gmp.h or
> > mini-gmp.h before including emacs-module.h. I.e.:
> >
> > #ifndef EMACS_MODULE_DO_NOT_INCLUDE_GMP_H
> > #include <gmp.h>
> > #endif
>
> Ah, okay.  But then what would emacs-module.c do with these 2 new APIs
> if gmp.h was not included?

It would include mini-gmp.h instead before including emacs-module.h.
I'm testing this right now, but I think it should work.

>
> > > And there might be option (3): have emacs-module.h duplicate the
> > > portion of mini-gmp.h that are needed when gmp.h isn't available.
> > > It's a bit inelegant, and maintenance burden, but maybe not grave
> > > enough to decide that wer cannot support bignums without a real GMP.
> >
> > I don't think we should replicate internal data structures of
> > third-party libraries. It's really ugly.
>
> mini-gmp.h is not third-party, it's Emacs.

Still, replicating internal data structures and making sure that they
stay ABI-compatible is too risky and too much of a burden.

>
> The problem I'm struggling with is how can we defend lack of support
> of bignums in modules when Emacs itself does support them?

I'd definitely prefer supporting bignums if possible. The question is
just whether it's possible.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]