Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-21978

make my_vsnprintf to use gcc-compatible format extensions

Details

    Description

      my_vsnprintf() is used internally in the server as a portable printf replacement. And it's also exported to plugins as a service.

      It supports a subset of printf formats and three extensions:

      • %`s means that a string should be quoted like an `identifier`
      • %b means that it's a binary string, not zero-terminated; printing won't stop at \0, so one should always specify the field width (like %.100b)
      • %M is used in error messages and prints the integer (errno) and the corresponding strerror() for it
      • %T takes string and print it like %s but if the string should be truncated puts "..." at the end

      gcc knows printf formats and check whether actual arguments match the format string and issue a warning if they don't. Unfortunately there seems to be no easy way to teach gcc our extensions, so for now we have to disable printf format checks.

      An better approach would be to use gcc compatible format extensions, like Linux kernel does. We should migrate to a different syntax for our extensions

      • %sQ to mean "print as an identifier"
      • %sB to mean "print a binary string"
      • %iE to mean "print an errno"
      • %sT to put a "..." as truncation indicator

      It'll also need %sS as a synonym for %s as a form of escaping. In case someone needs to print a string, followed by T — using %sT will not do it anymore, so %sST can be used instead.

      Old formats can still be supported or they can be removed. The major version of the service should be increased either way to signal an incompatible change (different semantics for, e.g., %sT).

      All error messages and all usages of my_vsnprintf should be changed to use the new syntax. One way to do it is to disable old syntax conditonally, only in debug builds. All gcc printf format checks should be enabled.

      Attachments

        Issue Links

          blocks

          Task - A task that needs to be done. MDEV-35601 Use my_vsnprintf extension %sQ where appropriate

          • Trivial - Cosmetic problem like misspelt words or misaligned text.
          • Open
          relates to

          Task - A task that needs to be done. MDEV-19784 C++11 protectors for my_error

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • In Review

          Epic - Created by Jira Software - do not edit or delete. Issue type for a big user story that needs to be broken down. MDEV-35460 Phase out integer typedefs and macros in favor of C/C++ Standard ones

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open

          Bug - A problem which impairs or prevents the functions of the product. MDEV-35498 InnoDB logger class causes significant code bloat

          • Major - Major loss of function.
          • Open

          Task - A task that needs to be done. MDEV-35600 Reconsider charset-specific snprintf’s vs. my_snprintf_ex

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open

          Bug - A problem which impairs or prevents the functions of the product. MDEV-22545 my_vsnprintf behaves not as in C standard

          • Blocker - Blocks development and/or testing work, production could not run.
          • Closed
          split to

          Task - A task that needs to be done. MDEV-35451 Add printf format for GTID

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open

          Bug - A problem which impairs or prevents the functions of the product. MDEV-35597 SST error might be printing literal %M

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open

          Activity

            Ascending order - Click to sort in descending order
            serg Sergei Golubchik created issue -
            serg Sergei Golubchik made changes -
            Field Original Value New Value
            Description {{my_vsnprintf()}} is used internally in the server as a portable {{printf}} replacement. And it's also exported to plugins as a service.

            It supports a subset of {{printf}} formats and three extensions:
            * {{%`s}} means that a string should be quoted like an {{`identifier`}}
            * {{%b}} means that it's a binary string, not zero-terminated; printing won't stop at {{\0}}, so one should always specify the field width (like {{%.100b}})
            * {{%M}} is used in error messages and prints the integer (errno) and the corresponding {{strerror()}} for it

            gcc knows {{printf}} formats and check whether actual arguments match the format string and issue a warning if they don't. Unfortunately there seems to be no easy way to teach gcc our extensions, so for now we have to disable {{printf}} format checks.

            An better approach would be to use gcc compatible format extensions, like Linux kernel does. We should migrate to a different syntax for our extensions
            * {{%sI}} to mean "print as an identifier"
            * {{%sB}} to mean "print a binary string"
            * {{%sE}} to mean "print an errno"

            old formats can still be supported or they can be removed and in the latter case the major version of the service should be increased to signal an incompatible change.

            All error messages and all usages of {{my_vsnprintf}} should be changed to use the new syntax and gcc {{printf}} format checks should be enabled.             		{{my_vsnprintf()}} is used internally in the server as a portable {{printf}} replacement. And it's also exported to plugins as a service.

            It supports a subset of {{printf}} formats and three extensions:
            * {{%`s}} means that a string should be quoted like an {{`identifier`}}
            * {{%b}} means that it's a binary string, not zero-terminated; printing won't stop at {{\0}}, so one should always specify the field width (like {{%.100b}})
            * {{%M}} is used in error messages and prints the integer (errno) and the corresponding {{strerror()}} for it

            gcc knows {{printf}} formats and check whether actual arguments match the format string and issue a warning if they don't. Unfortunately there seems to be no easy way to teach gcc our extensions, so for now we have to disable {{printf}} format checks.

            An better approach would be to use gcc compatible format extensions, like Linux kernel does. We should migrate to a different syntax for our extensions
            * {{%sI}} to mean "print as an identifier"
            * {{%sB}} to mean "print a binary string"
            * {{%uE}} to mean "print an errno"

            old formats can still be supported or they can be removed and in the latter case the major version of the service should be increased to signal an incompatible change.

            All error messages and all usages of {{my_vsnprintf}} should be changed to use the new syntax and gcc {{printf}} format checks should be enabled.
            elenst Elena Stepanova made changes -
            Summary make my_vsnprintf to use gcc-compatibe format extensions make my_vsnprintf to use gcc-compatible format extensions
            serg Sergei Golubchik made changes -
            monty Michael Widenius made changes -
            Description {{my_vsnprintf()}} is used internally in the server as a portable {{printf}} replacement. And it's also exported to plugins as a service.

            It supports a subset of {{printf}} formats and three extensions:
            * {{%`s}} means that a string should be quoted like an {{`identifier`}}
            * {{%b}} means that it's a binary string, not zero-terminated; printing won't stop at {{\0}}, so one should always specify the field width (like {{%.100b}})
            * {{%M}} is used in error messages and prints the integer (errno) and the corresponding {{strerror()}} for it

            gcc knows {{printf}} formats and check whether actual arguments match the format string and issue a warning if they don't. Unfortunately there seems to be no easy way to teach gcc our extensions, so for now we have to disable {{printf}} format checks.

            An better approach would be to use gcc compatible format extensions, like Linux kernel does. We should migrate to a different syntax for our extensions
            * {{%sI}} to mean "print as an identifier"
            * {{%sB}} to mean "print a binary string"
            * {{%uE}} to mean "print an errno"

            old formats can still be supported or they can be removed and in the latter case the major version of the service should be increased to signal an incompatible change.

            All error messages and all usages of {{my_vsnprintf}} should be changed to use the new syntax and gcc {{printf}} format checks should be enabled.             		{{my_vsnprintf()}} is used internally in the server as a portable {{printf}} replacement. And it's also exported to plugins as a service.

            It supports a subset of {{printf}} formats and three extensions:
            * {{%`s}} means that a string should be quoted like an {{`identifier`}}
            * {{%b}} means that it's a binary string, not zero-terminated; printing won't stop at {{\0}}, so one should always specify the field width (like {{%.100b}})
            * {{%M}} is used in error messages and prints the integer (errno) and the corresponding {{strerror()}} for it

            gcc knows {{printf}} formats and check whether actual arguments match the format string and issue a warning if they don't. Unfortunately there seems to be no easy way to teach gcc our extensions, so for now we have to disable {{printf}} format checks.

            An better approach would be to use gcc compatible format extensions, like Linux kernel does. We should migrate to a different syntax for our extensions
            * {{%sI}} to mean "print as an identifier"
            * {{%sB}} to mean "print a binary string"
            * {{%uE}} to mean "print an errno"

            Padding with ... if string is too long should only be used for identifiers.

            old formats can still be supported or they can be removed and in the latter case the major version of the service should be increased to signal an incompatible change.

            All error messages and all usages of {{my_vsnprintf}} should be changed to use the new syntax and gcc {{printf}} format checks should be enabled.
            serg Sergei Golubchik made changes -
            Description {{my_vsnprintf()}} is used internally in the server as a portable {{printf}} replacement. And it's also exported to plugins as a service.

            It supports a subset of {{printf}} formats and three extensions:
            * {{%`s}} means that a string should be quoted like an {{`identifier`}}
            * {{%b}} means that it's a binary string, not zero-terminated; printing won't stop at {{\0}}, so one should always specify the field width (like {{%.100b}})
            * {{%M}} is used in error messages and prints the integer (errno) and the corresponding {{strerror()}} for it

            gcc knows {{printf}} formats and check whether actual arguments match the format string and issue a warning if they don't. Unfortunately there seems to be no easy way to teach gcc our extensions, so for now we have to disable {{printf}} format checks.

            An better approach would be to use gcc compatible format extensions, like Linux kernel does. We should migrate to a different syntax for our extensions
            * {{%sI}} to mean "print as an identifier"
            * {{%sB}} to mean "print a binary string"
            * {{%uE}} to mean "print an errno"

            Padding with ... if string is too long should only be used for identifiers.

            old formats can still be supported or they can be removed and in the latter case the major version of the service should be increased to signal an incompatible change.

            All error messages and all usages of {{my_vsnprintf}} should be changed to use the new syntax and gcc {{printf}} format checks should be enabled.             		{{my_vsnprintf()}} is used internally in the server as a portable {{printf}} replacement. And it's also exported to plugins as a service.

            It supports a subset of {{printf}} formats and three extensions:
            * {{%`s}} means that a string should be quoted like an {{`identifier`}}
            * {{%b}} means that it's a binary string, not zero-terminated; printing won't stop at {{\0}}, so one should always specify the field width (like {{%.100b}})
            * {{%M}} is used in error messages and prints the integer (errno) and the corresponding {{strerror()}} for it

            gcc knows {{printf}} formats and check whether actual arguments match the format string and issue a warning if they don't. Unfortunately there seems to be no easy way to teach gcc our extensions, so for now we have to disable {{printf}} format checks.

            An better approach would be to use gcc compatible format extensions, like Linux kernel does. We should migrate to a different syntax for our extensions
            * {{%sI}} to mean "print as an identifier"
            * {{%sB}} to mean "print a binary string"
            * {{%uE}} to mean "print an errno"
            * {{%sT}} to put a "..." as truncation indicator

            old formats can still be supported or they can be removed and in the latter case the major version of the service should be increased to signal an incompatible change.

            All error messages and all usages of {{my_vsnprintf}} should be changed to use the new syntax and gcc {{printf}} format checks should be enabled.
            serg Sergei Golubchik made changes -
            Rank Ranked higher
            serg Sergei Golubchik made changes -
            Priority Minor [ 4 ] Major [ 3 ]
            nikitamalyavin Nikita Malyavin made changes -
            serg Sergei Golubchik made changes -
            Labels beginner-friendly beginner-friendly gsoc21
            serg Sergei Golubchik made changes -
            Fix Version/s 10.7 [ 24805 ]
            Fix Version/s 10.6 [ 24028 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.8 [ 26121 ]
            Fix Version/s 10.7 [ 24805 ]
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 105761 ] MariaDB v4 [ 131238 ]
            danblack Daniel Black added a comment -

            wlad suggested %lluH , for Humanized formatting (MDEV-27158)

            danblack Daniel Black added a comment - wlad suggested %lluH , for Humanized formatting ( MDEV-27158 )
            serg Sergei Golubchik made changes -
            Fix Version/s 10.9 [ 26905 ]
            Fix Version/s 10.8 [ 26121 ]
            cvicentiu Vicențiu Ciorbaru made changes -
            Summary make my_vsnprintf to use gcc-compatible format extensions make my_vsnprintf to use gcc-compatible format extensions (Part-time project)
            cvicentiu Vicențiu Ciorbaru made changes -
            Labels beginner-friendly gsoc21 beginner-friendly gsoc21 gsoc22
            serg Sergei Golubchik made changes -
            Fix Version/s 10.10 [ 27530 ]
            Fix Version/s 10.9 [ 26905 ]
            blueskyson Lin, Cheng-Chieh added a comment -

            Hi, I'm a senior student of CSIE department of Cheng Kung University. I saw this task from Google Summer of Code 2022. I'm interested in this task but I haven't used or built MariaDB before. Can I assign this task?

            blueskyson Lin, Cheng-Chieh added a comment - Hi, I'm a senior student of CSIE department of Cheng Kung University. I saw this task from Google Summer of Code 2022. I'm interested in this task but I haven't used or built MariaDB before. Can I assign this task?
            serg Sergei Golubchik added a comment -

            blueskyson, the "Assignee" field in Jira can only be assigned to someone in a Developers group. But it doesn't matter much. If you'd like to do this task — please, by all means, do it, create a pull request, and pay no attention to the "Assignee" field.

            serg Sergei Golubchik added a comment - blueskyson , the "Assignee" field in Jira can only be assigned to someone in a Developers group. But it doesn't matter much. If you'd like to do this task — please, by all means, do it, create a pull request, and pay no attention to the "Assignee" field.
            serg Sergei Golubchik made changes -
            Description {{my_vsnprintf()}} is used internally in the server as a portable {{printf}} replacement. And it's also exported to plugins as a service.

            It supports a subset of {{printf}} formats and three extensions:
            * {{%`s}} means that a string should be quoted like an {{`identifier`}}
            * {{%b}} means that it's a binary string, not zero-terminated; printing won't stop at {{\0}}, so one should always specify the field width (like {{%.100b}})
            * {{%M}} is used in error messages and prints the integer (errno) and the corresponding {{strerror()}} for it

            gcc knows {{printf}} formats and check whether actual arguments match the format string and issue a warning if they don't. Unfortunately there seems to be no easy way to teach gcc our extensions, so for now we have to disable {{printf}} format checks.

            An better approach would be to use gcc compatible format extensions, like Linux kernel does. We should migrate to a different syntax for our extensions
            * {{%sI}} to mean "print as an identifier"
            * {{%sB}} to mean "print a binary string"
            * {{%uE}} to mean "print an errno"
            * {{%sT}} to put a "..." as truncation indicator

            old formats can still be supported or they can be removed and in the latter case the major version of the service should be increased to signal an incompatible change.

            All error messages and all usages of {{my_vsnprintf}} should be changed to use the new syntax and gcc {{printf}} format checks should be enabled.             		{{my_vsnprintf()}} is used internally in the server as a portable {{printf}} replacement. And it's also exported to plugins as a service.

            It supports a subset of {{printf}} formats and three extensions:
            * {{%`s}} means that a string should be quoted like an {{`identifier`}}
            * {{%b}} means that it's a binary string, not zero-terminated; printing won't stop at {{\0}}, so one should always specify the field width (like {{%.100b}})
            * {{%M}} is used in error messages and prints the integer (errno) and the corresponding {{strerror()}} for it

            gcc knows {{printf}} formats and check whether actual arguments match the format string and issue a warning if they don't. Unfortunately there seems to be no easy way to teach gcc our extensions, so for now we have to disable {{printf}} format checks.

            An better approach would be to use gcc compatible format extensions, like Linux kernel does. We should migrate to a different syntax for our extensions
            * {{%sI}} to mean "print as an identifier"
            * {{%sB}} to mean "print a binary string"
            * {{%uE}} to mean "print an errno"
            * {{%sT}} to put a "..." as truncation indicator

            old formats can still be supported or they can be removed and in the latter case the major version of the service should be increased to signal an incompatible change.

            All error messages and all usages of {{my_vsnprintf}} should be changed to use the new syntax. One way to do it is to disable old syntax conditonally, only in debug builds. All gcc {{printf}} format checks should be enabled.
            serg Sergei Golubchik made changes -
            Fix Version/s 10.11 [ 27614 ]
            Fix Version/s 10.10 [ 27530 ]
            blueskyson Lin, Cheng-Chieh added a comment -

            Sorry I'm too busy on my work now. Maybe other people can do this task.

            blueskyson Lin, Cheng-Chieh added a comment - Sorry I'm too busy on my work now. Maybe other people can do this task.
            serg Sergei Golubchik made changes -
            Fix Version/s 10.12 [ 28320 ]
            Fix Version/s 10.11 [ 27614 ]
            serg Sergei Golubchik made changes -
            Labels beginner-friendly gsoc21 gsoc22 beginner-friendly gsoc21 gsoc22 gsoc24
            serg Sergei Golubchik made changes -
            Summary make my_vsnprintf to use gcc-compatible format extensions (Part-time project) make my_vsnprintf to use gcc-compatible format extensions
            serg Sergei Golubchik made changes -
            Description {{my_vsnprintf()}} is used internally in the server as a portable {{printf}} replacement. And it's also exported to plugins as a service.

            It supports a subset of {{printf}} formats and three extensions:
            * {{%`s}} means that a string should be quoted like an {{`identifier`}}
            * {{%b}} means that it's a binary string, not zero-terminated; printing won't stop at {{\0}}, so one should always specify the field width (like {{%.100b}})
            * {{%M}} is used in error messages and prints the integer (errno) and the corresponding {{strerror()}} for it

            gcc knows {{printf}} formats and check whether actual arguments match the format string and issue a warning if they don't. Unfortunately there seems to be no easy way to teach gcc our extensions, so for now we have to disable {{printf}} format checks.

            An better approach would be to use gcc compatible format extensions, like Linux kernel does. We should migrate to a different syntax for our extensions
            * {{%sI}} to mean "print as an identifier"
            * {{%sB}} to mean "print a binary string"
            * {{%uE}} to mean "print an errno"
            * {{%sT}} to put a "..." as truncation indicator

            old formats can still be supported or they can be removed and in the latter case the major version of the service should be increased to signal an incompatible change.

            All error messages and all usages of {{my_vsnprintf}} should be changed to use the new syntax. One way to do it is to disable old syntax conditonally, only in debug builds. All gcc {{printf}} format checks should be enabled.             		{{my_vsnprintf()}} is used internally in the server as a portable {{printf}} replacement. And it's also exported to plugins as a service.

            It supports a subset of {{printf}} formats and three extensions:
            * {{%`s}} means that a string should be quoted like an {{`identifier`}}
            * {{%b}} means that it's a binary string, not zero-terminated; printing won't stop at {{\0}}, so one should always specify the field width (like {{%.100b}})
            * {{%M}} is used in error messages and prints the integer (errno) and the corresponding {{strerror()}} for it
            * {{%T}} takes string and print it like {{%s}} but if the string should be truncated puts "..." at the end

            gcc knows {{printf}} formats and check whether actual arguments match the format string and issue a warning if they don't. Unfortunately there seems to be no easy way to teach gcc our extensions, so for now we have to disable {{printf}} format checks.

            An better approach would be to use gcc compatible format extensions, like Linux kernel does. We should migrate to a different syntax for our extensions
            * {{%sI}} to mean "print as an identifier"
            * {{%sB}} to mean "print a binary string"
            * {{%uE}} to mean "print an errno"
            * {{%sT}} to put a "..." as truncation indicator

            old formats can still be supported or they can be removed and in the latter case the major version of the service should be increased to signal an incompatible change.

            All error messages and all usages of {{my_vsnprintf}} should be changed to use the new syntax. One way to do it is to disable old syntax conditonally, only in debug builds. All gcc {{printf}} format checks should be enabled.
            serg Sergei Golubchik made changes -
            Description {{my_vsnprintf()}} is used internally in the server as a portable {{printf}} replacement. And it's also exported to plugins as a service.

            It supports a subset of {{printf}} formats and three extensions:
            * {{%`s}} means that a string should be quoted like an {{`identifier`}}
            * {{%b}} means that it's a binary string, not zero-terminated; printing won't stop at {{\0}}, so one should always specify the field width (like {{%.100b}})
            * {{%M}} is used in error messages and prints the integer (errno) and the corresponding {{strerror()}} for it
            * {{%T}} takes string and print it like {{%s}} but if the string should be truncated puts "..." at the end

            gcc knows {{printf}} formats and check whether actual arguments match the format string and issue a warning if they don't. Unfortunately there seems to be no easy way to teach gcc our extensions, so for now we have to disable {{printf}} format checks.

            An better approach would be to use gcc compatible format extensions, like Linux kernel does. We should migrate to a different syntax for our extensions
            * {{%sI}} to mean "print as an identifier"
            * {{%sB}} to mean "print a binary string"
            * {{%uE}} to mean "print an errno"
            * {{%sT}} to put a "..." as truncation indicator

            old formats can still be supported or they can be removed and in the latter case the major version of the service should be increased to signal an incompatible change.

            All error messages and all usages of {{my_vsnprintf}} should be changed to use the new syntax. One way to do it is to disable old syntax conditonally, only in debug builds. All gcc {{printf}} format checks should be enabled.             		{{my_vsnprintf()}} is used internally in the server as a portable {{printf}} replacement. And it's also exported to plugins as a service.

            It supports a subset of {{printf}} formats and three extensions:
            * {{%`s}} means that a string should be quoted like an {{`identifier`}}
            * {{%b}} means that it's a binary string, not zero-terminated; printing won't stop at {{\0}}, so one should always specify the field width (like {{%.100b}})
            * {{%M}} is used in error messages and prints the integer (errno) and the corresponding {{strerror()}} for it
            * {{%T}} takes string and print it like {{%s}} but if the string should be truncated puts "..." at the end

            gcc knows {{printf}} formats and check whether actual arguments match the format string and issue a warning if they don't. Unfortunately there seems to be no easy way to teach gcc our extensions, so for now we have to disable {{printf}} format checks.

            An better approach would be to use gcc compatible format extensions, like Linux kernel does. We should migrate to a different syntax for our extensions
            * {{%sI}} to mean "print as an identifier"
            * {{%sB}} to mean "print a binary string"
            * {{%uE}} to mean "print an errno"
            * {{%sT}} to put a "..." as truncation indicator

            Perhaps it'll also need {{%sS}} and {{%uU}} as synonyms for {{%s}} and {{%u}}, as a form of escaping. In case someone needs to print a string, followed by {{I}} — using {{%sI}} will not do it anymore, so {{%sSI}} can be used instead.

            old formats can still be supported or they can be removed and in the latter case the major version of the service should be increased to signal an incompatible change.

            All error messages and all usages of {{my_vsnprintf}} should be changed to use the new syntax. One way to do it is to disable old syntax conditonally, only in debug builds. All gcc {{printf}} format checks should be enabled.
            serg Sergei Golubchik made changes -
            Description {{my_vsnprintf()}} is used internally in the server as a portable {{printf}} replacement. And it's also exported to plugins as a service.

            It supports a subset of {{printf}} formats and three extensions:
            * {{%`s}} means that a string should be quoted like an {{`identifier`}}
            * {{%b}} means that it's a binary string, not zero-terminated; printing won't stop at {{\0}}, so one should always specify the field width (like {{%.100b}})
            * {{%M}} is used in error messages and prints the integer (errno) and the corresponding {{strerror()}} for it
            * {{%T}} takes string and print it like {{%s}} but if the string should be truncated puts "..." at the end

            gcc knows {{printf}} formats and check whether actual arguments match the format string and issue a warning if they don't. Unfortunately there seems to be no easy way to teach gcc our extensions, so for now we have to disable {{printf}} format checks.

            An better approach would be to use gcc compatible format extensions, like Linux kernel does. We should migrate to a different syntax for our extensions
            * {{%sI}} to mean "print as an identifier"
            * {{%sB}} to mean "print a binary string"
            * {{%uE}} to mean "print an errno"
            * {{%sT}} to put a "..." as truncation indicator

            Perhaps it'll also need {{%sS}} and {{%uU}} as synonyms for {{%s}} and {{%u}}, as a form of escaping. In case someone needs to print a string, followed by {{I}} — using {{%sI}} will not do it anymore, so {{%sSI}} can be used instead.

            old formats can still be supported or they can be removed and in the latter case the major version of the service should be increased to signal an incompatible change.

            All error messages and all usages of {{my_vsnprintf}} should be changed to use the new syntax. One way to do it is to disable old syntax conditonally, only in debug builds. All gcc {{printf}} format checks should be enabled.             		{{my_vsnprintf()}} is used internally in the server as a portable {{printf}} replacement. And it's also exported to plugins as a service.

            It supports a subset of {{printf}} formats and three extensions:
            * {{%`s}} means that a string should be quoted like an {{`identifier`}}
            * {{%b}} means that it's a binary string, not zero-terminated; printing won't stop at {{\0}}, so one should always specify the field width (like {{%.100b}})
            * {{%M}} is used in error messages and prints the integer (errno) and the corresponding {{strerror()}} for it
            * {{%T}} takes string and print it like {{%s}} but if the string should be truncated puts "..." at the end

            gcc knows {{printf}} formats and check whether actual arguments match the format string and issue a warning if they don't. Unfortunately there seems to be no easy way to teach gcc our extensions, so for now we have to disable {{printf}} format checks.

            An better approach would be to use gcc compatible format extensions, like Linux kernel does. We should migrate to a different syntax for our extensions
            * {{%sI}} to mean "print as an identifier"
            * {{%sB}} to mean "print a binary string"
            * {{%uE}} to mean "print an errno"
            * {{%sT}} to put a "..." as truncation indicator

            Perhaps it'll also need {{%sS}} and {{%uU}} as synonyms for {{%s}} and {{%u}}, as a form of escaping. In case someone needs to print a string, followed by {{I}} — using {{%sI}} will not do it anymore, so {{%sSI}} can be used instead.

            Old formats can still be supported or they can be removed. The major version of the service should be increased either way to signal an incompatible change (different semantics for, e.g., {{%sI}}).

            All error messages and all usages of {{my_vsnprintf}} should be changed to use the new syntax. One way to do it is to disable old syntax conditonally, only in debug builds. All gcc {{printf}} format checks should be enabled.
            TheLinuxJedi Andrew Hutchings (Inactive) made changes -
            Assignee Sergei Golubchik [ serg ] Andrew Hutchings [ JIRAUSER52179 ]
            TheLinuxJedi Andrew Hutchings (Inactive) added a comment -

            Assigned to myself due to mentoring someone under GSoC for this project.

            TheLinuxJedi Andrew Hutchings (Inactive) added a comment - Assigned to myself due to mentoring someone under GSoC for this project.
            serg Sergei Golubchik made changes -
            Fix Version/s 11.7 [ 29815 ]
            Fix Version/s 11.0 [ 28320 ]
            serg Sergei Golubchik made changes -
            Assignee Andrew Hutchings [ JIRAUSER52179 ] Sergei Golubchik [ serg ]
            serg Sergei Golubchik made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            serg Sergei Golubchik made changes -
            Assignee Sergei Golubchik [ serg ] Andrew Hutchings [ JIRAUSER52179 ]
            Status In Progress [ 3 ] In Review [ 10002 ]
            serg Sergei Golubchik made changes -
            Priority Major [ 3 ] Critical [ 2 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 11.8 [ 29921 ]
            Fix Version/s 11.7 [ 29815 ]
            ralf.gebhardt Ralf Gebhardt made changes -
            Labels beginner-friendly gsoc21 gsoc22 gsoc24 beginner-friendly gsoc21 gsoc22 gsoc24 tech_debt
            serg Sergei Golubchik made changes -
            Assignee Andrew Hutchings [ JIRAUSER52179 ] Brandon Nesterenko [ JIRAUSER48702 ]
            ParadoxV5 Jimmy Hú made changes -
            Description {{my_vsnprintf()}} is used internally in the server as a portable {{printf}} replacement. And it's also exported to plugins as a service.

            It supports a subset of {{printf}} formats and three extensions:
            * {{%`s}} means that a string should be quoted like an {{`identifier`}}
            * {{%b}} means that it's a binary string, not zero-terminated; printing won't stop at {{\0}}, so one should always specify the field width (like {{%.100b}})
            * {{%M}} is used in error messages and prints the integer (errno) and the corresponding {{strerror()}} for it
            * {{%T}} takes string and print it like {{%s}} but if the string should be truncated puts "..." at the end

            gcc knows {{printf}} formats and check whether actual arguments match the format string and issue a warning if they don't. Unfortunately there seems to be no easy way to teach gcc our extensions, so for now we have to disable {{printf}} format checks.

            An better approach would be to use gcc compatible format extensions, like Linux kernel does. We should migrate to a different syntax for our extensions
            * {{%sI}} to mean "print as an identifier"
            * {{%sB}} to mean "print a binary string"
            * {{%uE}} to mean "print an errno"
            * {{%sT}} to put a "..." as truncation indicator

            Perhaps it'll also need {{%sS}} and {{%uU}} as synonyms for {{%s}} and {{%u}}, as a form of escaping. In case someone needs to print a string, followed by {{I}} — using {{%sI}} will not do it anymore, so {{%sSI}} can be used instead.

            Old formats can still be supported or they can be removed. The major version of the service should be increased either way to signal an incompatible change (different semantics for, e.g., {{%sI}}).

            All error messages and all usages of {{my_vsnprintf}} should be changed to use the new syntax. One way to do it is to disable old syntax conditonally, only in debug builds. All gcc {{printf}} format checks should be enabled.             		{{my_vsnprintf()}} is used internally in the server as a portable {{printf}} replacement. And it's also exported to plugins as a service.

            It supports a subset of {{printf}} formats and three extensions:
            * {{%`s}} means that a string should be quoted like an {{`identifier`}}
            * {{%b}} means that it's a binary string, not zero-terminated; printing won't stop at {{\0}}, so one should always specify the field width (like {{%.100b}})
            * {{%M}} is used in error messages and prints the integer (errno) and the corresponding {{strerror()}} for it
            * {{%T}} takes string and print it like {{%s}} but if the string should be truncated puts "..." at the end

            gcc knows {{printf}} formats and check whether actual arguments match the format string and issue a warning if they don't. Unfortunately there seems to be no easy way to teach gcc our extensions, so for now we have to disable {{printf}} format checks.

            An better approach would be to use gcc compatible format extensions, like Linux kernel does. We should migrate to a different syntax for our extensions
            * {{%sQ}} to mean "print as an identifier"
            * {{%sB}} to mean "print a binary string"
            * {{%iE}} to mean "print an errno"
            * {{%sT}} to put a "..." as truncation indicator

            It'll also need {{%sS}} as a synonym for {{%s}} as a form of escaping. In case someone needs to print a string, followed by {{T}} — using {{%sT}} will not do it anymore, so {{%sST}} can be used instead.

            Old formats can still be supported or they can be removed. The major version of the service should be increased either way to signal an incompatible change (different semantics for, e.g., {{%sT}}).

            All error messages and all usages of {{my_vsnprintf}} should be changed to use the new syntax. One way to do it is to disable old syntax conditonally, only in debug builds. All gcc {{printf}} format checks should be enabled.
            ParadoxV5 Jimmy Hú made changes -
            marko Marko Mäkelä made changes -
            bnestere Brandon Nesterenko added a comment -

            Hi ParadoxV5!

            Your pt.1 PR #3309 looks ok for preview. We can finalize the cleanup PR #3360 in the next month or so to be ready in time for the RC main branch push.

            I'll plan on testing this, as it is internal to developers.

            bnestere Brandon Nesterenko added a comment - Hi ParadoxV5 ! Your pt.1 PR #3309 looks ok for preview. We can finalize the cleanup PR #3360 in the next month or so to be ready in time for the RC main branch push. I'll plan on testing this, as it is internal to developers.
            bnestere Brandon Nesterenko made changes -
            Status In Review [ 10002 ] Stalled [ 10000 ]
            bnestere Brandon Nesterenko made changes -
            Status Stalled [ 10000 ] In Testing [ 10301 ]
            ParadoxV5 Jimmy Hú made changes -
            ParadoxV5 Jimmy Hú made changes -
            ParadoxV5 Jimmy Hú made changes -
            serg Sergei Golubchik added a comment -

            could you please collect all commits that you're going to test and eventually push in one branch? Like, in bb-11.8-MDEV-21978-printf

            I tried to cherry-pick these two PRs for preview, the first one applied cleanly, but the second didn't

            serg Sergei Golubchik added a comment - could you please collect all commits that you're going to test and eventually push in one branch? Like, in bb-11.8- MDEV-21978 -printf I tried to cherry-pick these two PRs for preview, the first one applied cleanly, but the second didn't
            bnestere Brandon Nesterenko added a comment -

            serg #3309 is the feature-only PR, and #3360 contains the clean-up. In the engineering meeting last week, we'd discussed that the feature-part (#3309) is ready, but the cleanup needed additional work after the latest merge; and you'd suggested that we can use the feature-only PR for the preview, get the cleanup commits ready later, and then put them together for RC.

            bnestere Brandon Nesterenko added a comment - serg #3309 is the feature-only PR, and #3360 contains the clean-up. In the engineering meeting last week, we'd discussed that the feature-part (#3309) is ready, but the cleanup needed additional work after the latest merge; and you'd suggested that we can use the feature-only PR for the preview, get the cleanup commits ready later, and then put them together for RC.
            ParadoxV5 Jimmy Hú added a comment -

            ⬆️. I figured it’s more stable to rebase the second after the first’s done Testing. Previously, I always kept PR 2 based on top of PR 1.

            ParadoxV5 Jimmy Hú added a comment - ⬆️. I figured it’s more stable to rebase the second after the first’s done Testing. Previously, I always kept PR 2 based on top of PR 1.
            serg Sergei Golubchik added a comment -

            bnestere, ok, I'll take only #3309 into the preview

            serg Sergei Golubchik added a comment - bnestere , ok, I'll take only #3309 into the preview
            serg Sergei Golubchik made changes -
            bnestere Brandon Nesterenko made changes -
            Attachment MDEV-21978 Test Report.pdf [ 74430 ]
            bnestere Brandon Nesterenko added a comment -

            Testing looks good, report attached.

            MDEV-21978 Test Report.pdf

            bnestere Brandon Nesterenko added a comment - Testing looks good, report attached. MDEV-21978 Test Report.pdf
            bnestere Brandon Nesterenko made changes -
            Assignee Brandon Nesterenko [ JIRAUSER48702 ] Jimmy Hú [ JIRAUSER55761 ]
            Status In Testing [ 10301 ] Stalled [ 10000 ]
            ParadoxV5 Jimmy Hú added a comment -

            Casual comment: Revisiting my own code after GSoC as a member of a member org of my GSoC org, complete with time logging, is quite a refresher.

            ParadoxV5 Jimmy Hú added a comment - Casual comment: Revisiting my own code after GSoC as a member of a member org of my GSoC org, complete with time logging, is quite a refresher.
            ParadoxV5 Jimmy Hú made changes -
            Status Stalled [ 10000 ] In Review [ 10002 ]
            ParadoxV5 Jimmy Hú made changes -
            ParadoxV5 Jimmy Hú made changes -
            Assignee Jimmy Hú [ JIRAUSER55761 ] Brandon Nesterenko [ JIRAUSER48702 ]
            bnestere Brandon Nesterenko added a comment -

            Ok to push, thanks ParadoxV5!

            bnestere Brandon Nesterenko added a comment - Ok to push, thanks ParadoxV5 !
            bnestere Brandon Nesterenko made changes -
            Status In Review [ 10002 ] Stalled [ 10000 ]
            serg Sergei Golubchik made changes -
            Assignee Brandon Nesterenko [ JIRAUSER48702 ] Jimmy Hú [ JIRAUSER55761 ]
            ParadoxV5 Jimmy Hú added a comment -

            Part 2 OK to push indeed; just waiting on dependant fixes to merge up to main to exclude the fixes’ cherry-pick.

            ParadoxV5 Jimmy Hú added a comment - Part 2 OK to push indeed; just waiting on dependant fixes to merge up to main to exclude the fixes’ cherry-pick.
            ralf.gebhardt Ralf Gebhardt made changes -
            Labels beginner-friendly gsoc21 gsoc22 gsoc24 tech_debt Preview_11.8 beginner-friendly gsoc21 gsoc22 gsoc24 tech_debt
            ParadoxV5 Jimmy Hú made changes -
            issue.field.resolutiondate 2025-02-11 19:43:29.0 2025-02-11 19:43:29.214
            ParadoxV5 Jimmy Hú made changes -
            Fix Version/s 11.8.1 [ 29961 ]
            Fix Version/s 11.8 [ 29921 ]
            Resolution Fixed [ 1 ]
            Status Stalled [ 10000 ] Closed [ 6 ]

            People

              ParadoxV5 Jimmy Hú
              serg Sergei Golubchik
              Votes:
              1 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.