Paul Eggert wrote:
> On 12/16/19 2:12 AM, arn...@skeeve.com wrote:
> > What about
> >
> > typedef ptrdiff_t dfa_size_t
>
> That declaration would imply that the type is specific to DFAs. However, the
> type is used (with exactly the same meaning) in a lot of other places. This is
> why I use
On 12/16/19 2:12 AM, arn...@skeeve.com wrote:
> What about
>
> typedef ptrdiff_t dfa_size_t
That declaration would imply that the type is specific to DFAs. However, the
type is used (with exactly the same meaning) in a lot of other places. This is
why I used the more-generic name "idx_t" in
Paul Eggert wrote:
> On 12/15/19 12:14 AM, arn...@skeeve.com wrote:
>
> > int64_t is just as standard as ptrdiff_t and just as clear.
>
> Actually, int64_t is optional (as even C18 and POSIX-2018 do not require it),
> whereas ptrdiff_t has been required since C89. More importantly, int64_t would
On 12/15/19 12:14 AM, arn...@skeeve.com wrote:
> int64_t is just as standard as ptrdiff_t and just as clear.
Actually, int64_t is optional (as even C18 and POSIX-2018 do not require it),
whereas ptrdiff_t has been required since C89. More importantly, int64_t would
be overkill on 32-bit GNU/Linux
OK. I skimmed the links. But why not write the code to say what
we mean? For example:
#include
typedef int64_t dfa_size_t;
extern void dfaparse (char const *, dfa_size_t, struct dfa *);
extern void dfacomp (char const *, dfa_size_t, struct dfa *, bool);
I see that Paul has made the change to the API over my objections.
I made the change while responding to Bruno's objections, but before
seeing yours. Ooops. Sorry about that. However, I hope the followup
emails have addressed your comments, at least to some extent.
Paul, can you point to a
On Fri, Dec 13, 2019 at 4:08 AM wrote:
> arn...@skeeve.com write:
>
> > But I really don't want ptrdiff_t in the API.
>
> I see that Paul has made the change to the API over my objections.
>
> Jim --- do you have an opinion on this?
Hi Aharon,
I used to feel the way you do. However, given the wa
arn...@skeeve.com wrote:
> But I really don't want ptrdiff_t in the API.
I see that Paul has made the change to the API over my objections.
Jim --- do you have an opinion on this?
Thanks,
Arnold
Hi Paul.
Paul Eggert wrote:
> On 12/11/19 11:31 PM, arn...@skeeve.com wrote:
>
> > 1,$s/ptrdiff_t/ssize_t/g
>
> ssize_t can be narrower than ptrdiff_t, so it's not a good type to use
> for this notion. Its original motivation was "the type that 'read'
> returns", and on systems where 'read
On 12/11/19 11:31 PM, arn...@skeeve.com wrote:
1,$s/ptrdiff_t/ssize_t/g
ssize_t can be narrower than ptrdiff_t, so it's not a good type to use
for this notion. Its original motivation was "the type that 'read'
returns", and on systems where 'read' can return at most INT_MAX,
ssize_t
arn...@skeeve.com wrote:
> Other than this, I think internally too, I'd prefer that you
>
> 1,$s/ptrdiff_t/ssize_t/g
I did this, just to see. gawk passes its test suite, both in
64- and 32-bit mode.
FWIW.
Thanks,
Arnold
Hi Paul.
Paul Eggert wrote:
> https://lists.gnu.org/r/bug-gnulib/2019-12/msg00058.html
> https://lists.gnu.org/r/bug-gnulib/2019-12/msg00059.html
Looking at this:
| @@ -1733,11 +1733,11 @@ add_utf8_anychar (struct dfa *dfa)
| /* f0-f7: 4-byte sequence. */
| CHARCLASS_INIT (0, 0, 0,
Hi Paul.
Paul Eggert wrote:
> On 3/22/19 7:49 PM, Norihiro Tanaka wrote:
> > Missing a patch for dfa. Re-send correct patch file.
>
> Thanks, I installed the DFA-relevant parts of your proposed fix into
> Gnulib. (The grep parts still need doing.) I also installed the attached
> commentary fo
On 3/22/19 7:49 PM, Norihiro Tanaka wrote:
Missing a patch for dfa. Re-send correct patch file.
Thanks, I installed the DFA-relevant parts of your proposed fix into
Gnulib. (The grep parts still need doing.) I also installed the attached
commentary followup.
While I was at it I installed a
Hi.
Norihiro Tanaka wrote:
> Missing a patch for dfa. Re-send correct patch file.
Paul - is this going to be merged into GNULIB? If so, I'll put it into
gawk now; I want to make a release soon.
Thanks,
Arnold
[
On 3/22/19 9:59 PM, Budi wrote:
> How make grep walking through FS by scanning breadth first instead of
>
> On 3/23/19, Budi wrote:
>> How make grep walinh through FS by scanning breadth first instead of
>> the usual depth
>>
>> On 3/23/19, Norihiro Tanaka wrote:
>>> On Sat, 23 Mar 2019 08:06:35
How make grep walinh through FS by scanning breadth first instead of
the usual depth
On 3/23/19, Norihiro Tanaka wrote:
> On Sat, 23 Mar 2019 08:06:35 +0900
> Norihiro Tanaka wrote:
>
>> A kwset matcher is not built in a grep matcher after token re-order is
>> introduced in commit 5c7a0371823876
How make grep walking through FS by scanning breadth first instead of
On 3/23/19, Budi wrote:
> How make grep walinh through FS by scanning breadth first instead of
> the usual depth
>
> On 3/23/19, Norihiro Tanaka wrote:
>> On Sat, 23 Mar 2019 08:06:35 +0900
>> Norihiro Tanaka wrote:
>>
>>> A
On Sat, 23 Mar 2019 08:06:35 +0900
Norihiro Tanaka wrote:
> A kwset matcher is not built in a grep matcher after token re-order is
> introduced in commit 5c7a0371823876cca7a1347fa09ca26bbbff0c98 in dfa.
> It caused performance degradation in some typical cases. This bug is
> introduced in grep-3
a);
kwsmusts (dc);
+ dfacomp (NULL, 0, dc->dfa, 1);
free (motif);
--
1.7.1
From 60d47e1d9a5af18eeb61719c7ac8c8ae097a06e4 Mon Sep 17 00:00:00 2001
From: Norihiro Tanaka
Date: Sat, 23 Mar 2019 07:39:04 +0900
Subject: [PATCH] grep: a kwset matcher not work in a grep matcher
A kwset m
20 matches
Mail list logo
