Re: [netmod] regular expression flavours (again)

Carsten Bormann <> Fri, 14 June 2019 10:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84536120178 for <>; Fri, 14 Jun 2019 03:45:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VnHil4Q9qWEP for <>; Fri, 14 Jun 2019 03:45:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 540EE120159 for <>; Fri, 14 Jun 2019 03:45:31 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 45QHLw6v8zz100L; Fri, 14 Jun 2019 12:45:28 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Fri, 14 Jun 2019 12:45:28 +0200
Cc: Juergen Schoenwaelder <>, Robert Varga <>, NETMOD WG <>
X-Mao-Original-Outgoing-Id: 582201926.407581-d4a8e5626d374ee514a8fdd56116bbb7
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: "Rob Wilton (rwilton)" <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [netmod] regular expression flavours (again)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Jun 2019 10:45:35 -0000

On Jun 14, 2019, at 12:08, Rob Wilton (rwilton) <> wrote:
> Or perhaps we could define a regex language that worked with normal implementations without requiring any conversion.

Unlikely, as it is easy to write an regex that inadvertently triggers some “feature" in a specific flavor.  So you would need to list all the current and future idiosyncrasies of all flavors and outlaw them.  Worse, what you have outlawed may be *the* valid way to represent something in some other dialect, so the specifier needs to jump through hoops to work around that or simply cannot write down the regex needed.  Also, all those features that are subtly different between flavors (starting with ., \s, …) can’t be used.

The approach probably works for [A-Fa-f0-9]+, but becomes icky for anything more complicated quickly.  (And, actually, XSD regexes are very close to what you would come up with, anyway, except for “features” like character class subtraction or block escapes.)

Oh, and defining “normal implementations” is left as an exercise to the reader :-)

What we could do (and that would be quite useful, I think) is *document* the subset of XSD regexes that actually has the same meaning in PCRE2, Java8, JavaScript, .NET and a few more real-world regex languages after adding the necessary anchors in those languages.

Grüße, Carsten