-
Notifications
You must be signed in to change notification settings - Fork 583
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add C++ Pattern Validation #286
Conversation
Signed-off-by: Asra Ali <asraa@google.com>
This looks fine to me, but I'm not terribly familiar with C++ enough to say if this is ideal or not. Looking in Envoy, the RE2 usages use a |
templates/cc/msg.go
Outdated
|
||
{{ if has .Rules "Items"}}{{ if .Rules.Items }} | ||
{{ if has .Rules.Items.GetString_ "Pattern" }} {{ if .Rules.Items.GetString_.Pattern }} | ||
const re2::RE2 {{ lookup .Field "Pattern" }}(std::string({{ lit .Rules.Items.GetString_.GetPattern }}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The construction of a std::string here doesn't seem terrible; I don't think there's a better way to deal with null-terminated strings unless you want to introduce absl/std::string_view. That would save a copy on startup.
(Sorry just getting back to this after KubeCon) Oh, thanks Chris and Alex. I think we can get the best of both worlds with that |
Signed-off-by: Asra Ali <asraa@google.com>
I used |
I assume we're validating the regex when generating the code, so we shouldn't see invalid regexes during validation. I think the behavior of failing loudly is reasonable. |
Envoy now uses RE2 as a safe regex engine instead of std::regex (envoyproxy/envoy#7878). Because PGV already requires patterns to use RE2 syntax, one option is to use RE2 for C++ patterns as well. This implements it, for use in strings, bytes, repeated items, and may key/value pattern validation.
Implements #22
WIP: I ran in to difficulty creating the regex because a regex containing a null character would get cut off... for example, the ascii character test used the pattern,
^[\x00-x7f]+$
, and consuming this as a string resulted in creating a null-terminated string pattern^[
instead of the actual pattern. I think this might be a problem across most of the C++ code? That's why there's a terrible string construction in the pattern creation.Signed-off-by: Asra Ali asraa@google.com