WL#7582: Refactor strings: use of (const char *) in LEX_USER
Affects: Server-5.7
—
Status: Complete
Safe refactoring changes are needed while refactoring strings in the server in order to minimize merge complexity. To recap: - the server codebase now actively uses (char *) and LEX_STRING to deal with strings; - the reason for this is mostly legacy. In other words, even immutable strings are represented as (char *). - new strings will be mostly dealing with (const char *); - the idea of "safe refactoring changes" is to change (char *) to (const char *) where possible. Those changes are essentially no-change, in the sense that they don't change the behaviour. Because of that the changes can be pushed directly to trunk. This WL is to change (char *) and LEX_STRING to (const char *) and LEX_CSTRING respectively in the LEX_USER structure and related functions. This WL can also be seen as a pre-requisite for "Define and prove methodology to switch to new strings" because the "safe refactoring changes" will be a part of the methodology. User Documentation ================== Code refectoring. No user documentation needed.
NF1: Code refactoring should not effect the current behavior. NF2: Should work on all platforms
The worklog does refactor of LEX_USER struct and related functions/subsystems that deal with LEX_USER. Refactoring involves changing char* to const char* and usage of LEX_CSTRING with respect to char* member fields. Related change involve const correctness of function prototypes and passing const references around functions when and as required. This refactoring is in accordance with WL#7286 which would allow for a 'safe' transitional refactor as per the description provided there to 'new string' classes and framework. The data members user, host, password, plugin and auth are modified to have type LEX_CSTRING of LEX_USER. This results in a cascade of class/struct data variables and functions which has undergone which are described below. The changes are to be done should be logically coherent and touch some related subsystes and thus at some point const_cast is used not to propagate the changes further. In the case of LEX_USER refactoring, const_cast is only when calling the acl_getroot function. In terms of classses and their data members which is changed to LEX_CSTRING is listed below: 1. LEX_USER (sql/structs.h)hanges in function prototypes, functions and class/struct member LEX_CSTRING user LEX_CSTRING host LEX_CSTRING password LEX_CSTRING plugin LEX_CSTRING auth 2. ACL_USER (sql/auth/sql_auth_cache.h) LEX_CSTRING plugin 3. MPVIO_EXT (sql/auth/sql_authentication.h) LEX_CSTRING acl_user_plugin; 4. Change of following variables in sql/auth/sql_authentication.h to LEX_CSTRING (1) native_password_plugin_name (2) old_password_plugin_name (3) sha256_password_plugin_name (4) validate_password_plugin_name (5) default_auth_plugin_name 5. Event_time (sql/event_data_objects.h) LEX_CSTRING m_definer_user LEX_CSTRING m_definer_host 6. Event_job_data (sql/event_data_objects.h) LEX_CSTRING m_definer_userp LEX_CSTRING m_definer_host 7. THD (sql/sql_class.h) LEX_CSTRING m_invoker_user LEX_CSTRING m_invoker_host The function names whose prototypes or other changes that are modified as part of the refactoring include: 1. optimize_plugin_compare_by_pointer 2. acl_insert_user 3. ACL_PROXY_USER::store_pk 4. ACL_PROXY_USER::store_data_record 5. acl_update_user 6. do_auth_once 7. check_change_password 8. plugin_is_ready 9. create_string (sp.cc) 10. sp_head::set_definer 11. make_lex_string_root 12. make_lex_string 13. change_security_context 14. check_string_byte_length 15. check_host_name 16. check_string_byte_length 17. check_string_char_length 18. plugin_find_internal 19. plugin_status 20. plugin_lock_by_name 21. plugin_find_by_type 22. append_definer 23. reconstruct_definer_clause The refactoring has been done to some cohesive set of functions that relates to the authentication subsystem with some changes in plugin & stored procedure layer. Refactoring has been stopped and char* string is passed around as changes need to be done at storage engine handler layer or certain low-level platform API(memroot,string related functionality) that will affect every part of the code.
Copyright (c) 2000, 2024, Oracle Corporation and/or its affiliates. All rights reserved.