[20510] in Kerberos_V5_Development
Re: Using std::regex for pkinit on Windows
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sat Nov 23 17:25:53 2024
Message-ID: <e1859217-36d7-4e6e-86d1-fc920944133e@mit.edu>
Date: Sat, 23 Nov 2024 17:25:29 -0500
MIME-Version: 1.0
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: krbdev@mit.edu
Content-Language: en-US
From: "Greg Hudson" <ghudson@mit.edu>
In-Reply-To: <202411231838.4ANIco9l016749@hedwig.cmf.nrl.navy.mil>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: krbdev-bounces@mit.edu
On 11/23/24 13:38, Ken Hornstein wrote:
> In terms of mechanics, are you thinking of having every caller make
> calls into krb5int_regcomp() (and associated functions) and put the
> compatibility glue in libkrb5support?
The ideal would be that code using regular expressions would include a
<k5-regex.h> from src/include and use the POSIX APIs. On POSIX
platforms this header would include <regex.h> and otherwise do nothing;
on Windows it would #define the POSIX symbols to k5_ symbols implemented
in libkrb5support.
If it's not possible to express the POSIX API perfectly in terms of
std::regex, then we can invent a least-common-denominator API with k5_
names. In that case, k5-regex.h would use macros or inline functions to
express the common API in terms of the POSIX ones on POSIX platforms,
and they would be implemented in libkrb5support otherwise.
> There is some support for older regular expression libraries that use
> the functions compile() and re_comp().
It looks like we used to have this for an2ln in 1.11, and I got rid of
it for 1.12. Nobody has complained about it. So I think we can safely
assume POSIX regex.h for Unix-like platforms, and expunge any
compatibility code using older regex APIs.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
