ObjFW  View Ticket

00:01 Ticket [134d90a996] String \0 safety status still Open with 3 other changes artifact: 89b5ac18b3 user: js
15:46 Ticket [134d90a996]: 3 changes artifact: 5aecadaf53 user: js
16:58 Ticket [134d90a996]: 4 changes artifact: 3ac85cf6d9 user: js
09:02 Ticket [134d90a996]: 4 changes artifact: ef42aecc12 user: js
07:17 New ticket [134d90a996]. artifact: 3fa39fc600 user: js

Ticket UUID: 134d90a99615cc7590173d97a37949db8c9574d5
Title: String \0 safety
Status: Open Type: Enhancement
Severity: Severe Priority: High
Subsystem: Resolution: Open
Last Modified: 2024-05-22 00:01:53
Version Found In: Milestone: 1.2
User Comments:
js added on 2023-07-22 07:17:50:

Currently, OFString does not reject a \0 within the string. However, OFStrings often get passed as C strings. Therefore, either one of the following should be done:

  • Audit all occurrences where an OFString is passed as a C string.
  • Truncate the length to the first occurrence of \0.
  • Extend the current string checking code to reject \0 in there if a length has been specified.
    • If no length has been specified, it cannot be longer until the \0 anyway.
    • A good place for this would be in the code that checks whether the passed string is valid UTF-8, to avoid going through the same string twice.
      • This means strings of another encoding need to check for \0 during their conversion to UTF-8, as UTF-8 is not validated there since it was just converted and hence assumed correct.

The first option probably doesn't scale, as there are many places where an OFString is passed as a C string and doesn't cover where this is being done outside of ObjFW. So this would be a potential foot gun for users.

The second option might be unexpected and lead to bugs, because the user has just specified a length for the string to create, but the just created string has a different length.

Therefore, the third option probably makes most sense.