On Fri, 2018 Jun 22 16:44+0100, p...@hermes.cam.ac.uk wrote:
> >
> > That won't be a problem, because an -I$(builddir)/src would be part
> > of the #includes. (Note that #include<> typically searches the list
> > of -I directories before looking in the system directories.)
>
> ... but we'd need "a
On Wed, 16 May 2018, Daniel Richard G. wrote:
> > ... but would this not have the effect of including an *installed*
> > version of pcre2.h from /usr/include instead of from the build or
> > source trees?
>
> That won't be a problem, because an -I$(builddir)/src would be part of
> the #includes.
On Thu, 2018 Jun 21 17:17+0100, p...@hermes.cam.ac.uk wrote:
>
> > * Currently, the generic pcre2.h header (under src/) in the source
> > tree is used instead of the generated pcre2.h in the build tree.
> > This is due to the use of #include"pcre2.h" instead of
> > #include. Would it be all r
On Mon, 7 May 2018, Daniel Richard G. wrote:
> * Currently, the generic pcre2.h header (under src/) in the source tree
> is used instead of the generated pcre2.h in the build tree. This is
> due to the use of #include"pcre2.h" instead of #include.
> Would it be all right to change all instan
On Thu, 21 Jun 2018, I wrote:
> What's the best way to solve that? Does
>
> #if defined(PCRE2_HAVE_STDINT_H) && PCRE2_HAVE_STDINT_H != 1
>
> or
>
> #if defined(PCRE2_HAVE_STDINT_H) && PCRE2_HAVE_STDINT_H
>
> do any better? There must be some way to test for that without causing a
> warning.
On Wed, 20 Jun 2018, Daniel Richard G. wrote:
> Note that Autoconf is not setting the variables to zero when the headers
> are not found. On an old FreeBSD system here, for example, the generated
> pcre2.h contains
>
> #define PCRE2_HAVE_STDINT_H
> #define PCRE2_HAVE_INTTYPES_H 1
>
>
Hi Philip,
On Wed, 2018 Jun 20 18:13+0100, p...@hermes.cam.ac.uk wrote:
>
> My turn to apologise for delay; other things took longer than intended
> and Life keeps interfering. Anyway, I am at last working through the
> issues discussed in our most recent correspondence. I have just
> committed a
On Mon, 7 May 2018, Daniel Richard G. wrote:
> Apologies for the delay; many fires to put out last week.
My turn to apologise for delay; other things took longer than intended
and Life keeps interfering. Anyway, I am at last working through the
issues discussed in our most recent correspondence
On Wed, 16 May 2018, Daniel Richard G. wrote:
> Hi Philip,
Hi Daniel,
Thanks again for your thoughts and ideas. I'm afraid I still haven't
looked at this, having been distracted by doing some updates to my music
typesetting software that have turned into rather more than I originally
envisage
Hi Philip,
On Wed, 2018 May 9 17:38+0100, p...@hermes.cam.ac.uk wrote:
> Hi Daniel,
>
> Thanks for your messages and your efforts. I haven't yet looked
> seriously at your new patches. However, I should say that for many
> years I stuck religiously to C90 in all PCRE code, until PCRE2 came
> alo
Hi Daniel,
Thanks for your messages and your efforts. I haven't yet looked
seriously at your new patches. However, I should say that for many years
I stuck religiously to C90 in all PCRE code, until PCRE2 came along. By
that stage I felt it was probably time to allow some newer C things
(e.g.
Hi Philip,
On Fri, 2018 Apr 27 17:55+0100, p...@hermes.cam.ac.uk wrote:
> On Thu, 19 Apr 2018, I wrote:
>
> > > * Test 6 still crashes due to running out of stack space, only in
> > > this case, it's a very deep call stack that is the issue. I had
> > > to add /STACK:300 to the linker inv
Hi Philip,
Apologies for the delay---I had a number of fires to put out this week.
Thank you for looking at this.
On Thu, 2018 Apr 19 18:18+0100, p...@hermes.cam.ac.uk wrote:
>
> > * pcre2_dfa_match.c: Several invocations of pcre2test were crashing
> > due to _chkstk(). Meaning, the program ra
Hi Philip,
Apologies for the delay; many fires to put out last week.
On Sun, 2018 Apr 29 16:20+0100, p...@hermes.cam.ac.uk wrote:
> On Sat, 28 Apr 2018, I wrote:
>
> > So the problem is why is the match limit not biting in your
> > environment? Did you change the default when you build PCRE2?
>
>
On Sat, 28 Apr 2018, I wrote:
> So the problem is why is the match limit not biting in your
> environment? Did you change the default when you build PCRE2?
I now think you must have done so, because when I build with
--with-match-limit=40 I get the same errors as you did.
I have now pat
On Thu, 5 Apr 2018, Daniel Richard G. wrote:
> * Test 6 also fails because line 4932 of testinput6 contains a Ctrl-Z
> character, which on DOS/Windows indicates EOF.
I have removed that character. That test looks to have come from a
fuzzer as it is so weird. Removing the character does not al
On Thu, 19 Apr 2018, I wrote:
> > * Test 6 still crashes due to running out of stack space, only in this
> > case, it's a very deep call stack that is the issue. I had to add
> > /STACK:300 to the linker invocation for this issue to go away.
>
> This is DFA matching again. On Linux it run
On Thu, 5 Apr 2018, Daniel Richard G. wrote:
> I have been building and testing PCRE2 on Windows, using somewhat older
> versions of Visual Studio (required by my employer for customer-system
> compatibility). I have found a few issues and have attached a patch
> (against r929) for a couple of the
On Thu, 5 Apr 2018, Daniel Richard G. wrote:
> I have been building and testing PCRE2 on Windows, using somewhat older
> versions of Visual Studio (required by my employer for customer-system
> compatibility). I have found a few issues and have attached a patch
> (against r929) for a couple of the
19 matches
Mail list logo
