-
Notifications
You must be signed in to change notification settings - Fork 50
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
inhibit ADL when invoking rules #255
Comments
How do we do that? |
No you just put the function call in parenthesis, e.g. |
When we call a library function template with types that come from the user, we must ensure that the call inhibits ADL. Otherwise, the sneaky little bastard users can make our algorithm do something it is not designed to do, which is call an entirely different function under control of the user. Two easy ways to inhibit ADL:
Here, ADL can't hurt us because we aren't calling a free function. There is no argument-dependent lookup: return r.parse(it, end); The old For instance, the user can hijack our encoding functions and possibly our comparison operators. We need to find places in our code where we call our own function templates with user-defined objects. Another one: https://github.com/boostorg/url/blob/develop/include/boost/url/detail/encode.hpp#L114 return encode_unsafe( The call to Now if we are calling into detail:: and it has a namespace qualifier, ADL is already inhibited. e.g. if the above read In practice, users don't try to hijack our functions (although this has been known to happen sometimes when a company needs to work around a bug in a library whose source they cannot modify). it can happen when there is very complicated code, people aren't paying attention, and a series of bad luck bad decisions cause the wrong function to be called from our library because of a user overload (edited) |
algorithms which pass rules must inhibit ADL in the function call. grammar and rfc need review.
The text was updated successfully, but these errors were encountered: