On Mon, Nov 15, 2021 at 03:24:41PM -0800, Paul Eggert wrote:
> On 11/15/21 12:49, Carlo Marcelo Arenas Belón wrote:
>
> > Apologies, I realize it is difficult to talk about code in abstract when
> > not inlined, but I think it will better addressed by "fixing" it as shown
> > in the attached patch
On 11/15/21 12:49, Carlo Marcelo Arenas Belón wrote:
Apologies, I realize it is difficult to talk about code in abstract when
not inlined, but I think it will better addressed by "fixing" it as shown
in the attached patch.
That patch isn't right, because the relevant code inside libpcre2 uses
On Mon, Nov 15, 2021 at 08:17:02AM -0800, Paul Eggert wrote:
> On 11/14/21 20:44, Carlo Arenas wrote:
>
> > > This shouldn't be a problem in practice. Surely PCRE2_SIZE_MAX is for
> > > forward compatibility to a potential future version of PCRE2 that may
> > > define PCRE2_SIZE to be some other t
On 11/14/21 20:44, Carlo Arenas wrote:
This shouldn't be a problem in practice. Surely PCRE2_SIZE_MAX is for
forward compatibility to a potential future version of PCRE2 that may
define PCRE2_SIZE to be some other type. For PCRE2 10.20 and earlier
PCRE2_SIZE is hardwired to size_t, so there is o
On Sun, Nov 14, 2021 at 7:18 PM Paul Eggert wrote:
> On 11/14/21 14:25, Carlo Arenas wrote:
> > using idx_t instead of size_t should be fine (if only halves the max
> > size of the objects managed), but I am concerned that assuming
> > PCRE2_SIZE_MAX is always equivalent to SIZE_MAX (as done in pa
On 11/14/21 14:25, Carlo Arenas wrote:
the one in patch6 where a uint32_t option is doubled, triggers
warnings because of comparing an unsigned variable with 0 AFAIK, but
there are several of those in the upstream gnulib so presumably not a
concern?
Yes, that's right. intprops.h can generate t
On 11/14/21 14:44, Jeffrey Walton wrote:
GNU Hurd may not have SIZE_MAX defined.
I doubt whether that's an issue with recent Hurd. And even if it is,
Gnulib will arrange for a substitute SIZE_MAX in stdint.h (this is for
ancient, pre-C99 compilers) that will work just fine. So we're OK here.
On Sun, Nov 14, 2021 at 3:18 PM Carlo Arenas wrote:
> On Sun, Nov 14, 2021 at 2:45 PM Jeffrey Walton wrote:
> > On Sun, Nov 14, 2021 at 5:26 PM Carlo Arenas wrote:
> > > On Sun, Nov 14, 2021 at 12:45 PM Paul Eggert wrote:
> > > > ...
> > > using idx_t instead of size_t should be fine (if only h
On Sun, Nov 14, 2021 at 2:45 PM Jeffrey Walton wrote:
>
> On Sun, Nov 14, 2021 at 5:26 PM Carlo Arenas wrote:
> > On Sun, Nov 14, 2021 at 12:45 PM Paul Eggert wrote:
> > > ...
> > using idx_t instead of size_t should be fine (if only halves the max
> > size of the objects managed), but I am conc
On Sun, Nov 14, 2021 at 5:26 PM Carlo Arenas wrote:
> ...
> I seem to be unlucky; getting certificate errors in Debian sid, FTBFS
> errors when building the info in macOS, but the latest master was able
> to run `make dist` successfully in Debian 10, so it is just likely a
> PBKAC problem.
'sudo
On Sun, Nov 14, 2021 at 5:26 PM Carlo Arenas wrote:
> On Sun, Nov 14, 2021 at 12:45 PM Paul Eggert wrote:
> > ...
> using idx_t instead of size_t should be fine (if only halves the max
> size of the objects managed), but I am concerned that assuming
> PCRE2_SIZE_MAX is always equivalent to SIZE_M
On Sun, Nov 14, 2021 at 12:45 PM Paul Eggert wrote:
>
> On 11/9/21 02:58, Carlo Marcelo Arenas Belón wrote:
> > Sadly, hadn't been able to generate a release,
>
> Does this mean you're having trouble running 'make dist'? If so, what's
> the trouble?
I seem to be unlucky; getting certificate error
On 11/9/21 02:58, Carlo Marcelo Arenas Belón wrote:
Sadly, hadn't been able to generate a release,
Does this mean you're having trouble running 'make dist'? If so, what's
the trouble?
it seems to be ready for some broader testing, specially if the
attached patch is applied on top of a 10.3
Sadly, hadn't been able to generate a release, so testing is somehow
limited to platforms where I can hack a bootstrap (macOS / a few Linux),
but it seems to be ready for some broader testing, specially if the
attached patch is applied on top of a 10.37 release (tested that way
in OpenBSD i386)
Ch
14 matches
Mail list logo
