Added compile-time warning for GUIX deprecated string API by fdesbiens · Pull Request #167 · eclipse-threadx/guix

fdesbiens · 2026-06-24T13:08:29Z

Summary

When GX_DISABLE_DEPRECATED_STRING_API is not defined, gx_api.h now emits a #pragma message compile-time warning directing developers to define GX_DISABLE_DEPRECATED_STRING_API and migrate to the GX_STRING-based (_ext) replacement functions.

The pre-5.6 GX_CHAR * API omits string lengths and cannot safely handle non-NUL-terminated strings or prevent buffer overruns. All new applications should use the replacement variants.

Changes

common/inc/gx_api.h: added #pragma message inside the #ifndef GX_DISABLE_DEPRECATED_STRING_API block.

Companion

Docs: eclipse-threadx/rtos-docs-asciidoc#33 (pending)

When GX_DISABLE_DEPRECATED_STRING_API is not defined (i.e., the pre-5.6 GX_CHAR* API is still enabled), gx_api.h now emits a #pragma message directing developers to define GX_DISABLE_DEPRECATED_STRING_API and migrate to the GX_STRING-based replacement functions. The deprecated functions omit a string length and cannot safely handle non-NUL-terminated strings or prevent buffer overruns. All new applications should use the _ext() replacement variants. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

) _gx_multi_line_text_view_display_info_get() decided whether a line terminator was "\r" or "\r\n" by examining ch.gx_string_ptr[1], the byte after the current character, without checking that a byte remained. When the carriage return is the last byte of the range, that access is outside the caller's buffer. A GX_STRING carries its own length and need not be NUL terminated -- that is why the _ext string API exists, and it is what the deprecation warning added in #167 says about the older char * API. _gx_multi_line_text_view_text_set_ext() stores the caller's GX_STRING verbatim unless GX_STYLE_TEXT_COPY is set, and callers of this function pass end_index = gx_string_length, so in the default configuration the read lands one byte past what the application supplied. The consequence is not only the read. If that byte happens to be 0x0A, the function reports a two-byte terminator for a one-byte remainder, so every caller advances its index by one more than the string holds. In _gx_multi_line_text_view_string_total_rows_compute() the loop then exits with index == gx_string_length + 1 and evaluates string.gx_string_ptr[index - 1], one byte past the end as well, and can add a row that is not in the text. The same over-advance reaches the line index cache in gx_multi_line_text_view_line_cache_update.c and the cursor arithmetic in gx_multi_line_text_input_cursor_pos_update.c. Both reads now go through string rather than ch. string has already been advanced past the current character and its length is exactly the number of bytes still readable there, so guarding on it bounds the access to what the caller supplied. The same idiom in _gx_multi_line_text_input_new_line_character_get() is corrected as well. That one is not currently reachable as a read past the end: its only caller, _gx_multi_line_text_input_text_set_ext(), writes a NUL immediately after the copied text. It is fixed anyway because it depends on an invariant established in a different function and documented nowhere, and because the byte it reads decides whether the widget inserts a one- or two-byte terminator on every subsequent Enter. The rest of the codebase was audited for the same shape. Five other sites handle a carriage return followed by a possible line feed; all five are already correct. gx_rich_text_view_line_info_get.c, gx_multi_line_text_input_char_insert.c and gx_utility_bidi_paragraph_reorder.c guard on the remaining length, the preprocessed-line-break branch at the top of the changed function guards on it too, and gx_multi_line_text_button_line_pointers_set.c walks a NUL-terminated char * buffer where the byte after a carriage return is at worst the terminator. guix_ml_text_line_terminator_bounds_no_output covers this. It places a line feed immediately after the string under test but outside the length the widget is given, so the over-read is observable without a sanitizer: the unfixed code counts the out-of-bounds byte and reports a 4-byte row for a 3-byte string, which the test catches as "Expected: 3, Got: 4". Two controls pin the cases that must not change -- a "\r\n" pair genuinely inside the string still counts as two bytes, and a carriage return followed by ordinary text still counts as one. The test also asserts the terminator a multi-line text input adopts from its text, for a lone carriage return and for a "\r\n" pair. Those two cases pass both before and after the change, for the reason given above; they are there to pin the behaviour, not to reproduce a fault. Verified on Linux across all eighteen build configurations, no failures. No documentation change is required: no public API or behaviour contract changes, and the corrected behaviour is what the documented terminator handling already describes. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-24T13:08:29Z

Summary

When GX_DISABLE_DEPRECATED_STRING_API is not defined, gx_api.h now emits a #pragma message compile-time warning directing developers to define GX_DISABLE_DEPRECATED_STRING_API and migrate to the GX_STRING-based (_ext) replacement functions.

The pre-5.6 GX_CHAR * API omits string lengths and cannot safely handle non-NUL-terminated strings or prevent buffer overruns. All new applications should use the replacement variants.

Changes

common/inc/gx_api.h: added #pragma message inside the #ifndef GX_DISABLE_DEPRECATED_STRING_API block.

Companion

Docs: eclipse-threadx/rtos-docs-asciidoc#33 (pending)

When GX_DISABLE_DEPRECATED_STRING_API is not defined (i.e., the pre-5.6 GX_CHAR* API is still enabled), gx_api.h now emits a #pragma message directing developers to define GX_DISABLE_DEPRECATED_STRING_API and migrate to the GX_STRING-based replacement functions. The deprecated functions omit a string length and cannot safely handle non-NUL-terminated strings or prevent buffer overruns. All new applications should use the _ext() replacement variants. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

) _gx_multi_line_text_view_display_info_get() decided whether a line terminator was "\r" or "\r\n" by examining ch.gx_string_ptr[1], the byte after the current character, without checking that a byte remained. When the carriage return is the last byte of the range, that access is outside the caller's buffer. A GX_STRING carries its own length and need not be NUL terminated -- that is why the _ext string API exists, and it is what the deprecation warning added in #167 says about the older char * API. _gx_multi_line_text_view_text_set_ext() stores the caller's GX_STRING verbatim unless GX_STYLE_TEXT_COPY is set, and callers of this function pass end_index = gx_string_length, so in the default configuration the read lands one byte past what the application supplied. The consequence is not only the read. If that byte happens to be 0x0A, the function reports a two-byte terminator for a one-byte remainder, so every caller advances its index by one more than the string holds. In _gx_multi_line_text_view_string_total_rows_compute() the loop then exits with index == gx_string_length + 1 and evaluates string.gx_string_ptr[index - 1], one byte past the end as well, and can add a row that is not in the text. The same over-advance reaches the line index cache in gx_multi_line_text_view_line_cache_update.c and the cursor arithmetic in gx_multi_line_text_input_cursor_pos_update.c. Both reads now go through string rather than ch. string has already been advanced past the current character and its length is exactly the number of bytes still readable there, so guarding on it bounds the access to what the caller supplied. The same idiom in _gx_multi_line_text_input_new_line_character_get() is corrected as well. That one is not currently reachable as a read past the end: its only caller, _gx_multi_line_text_input_text_set_ext(), writes a NUL immediately after the copied text. It is fixed anyway because it depends on an invariant established in a different function and documented nowhere, and because the byte it reads decides whether the widget inserts a one- or two-byte terminator on every subsequent Enter. The rest of the codebase was audited for the same shape. Five other sites handle a carriage return followed by a possible line feed; all five are already correct. gx_rich_text_view_line_info_get.c, gx_multi_line_text_input_char_insert.c and gx_utility_bidi_paragraph_reorder.c guard on the remaining length, the preprocessed-line-break branch at the top of the changed function guards on it too, and gx_multi_line_text_button_line_pointers_set.c walks a NUL-terminated char * buffer where the byte after a carriage return is at worst the terminator. guix_ml_text_line_terminator_bounds_no_output covers this. It places a line feed immediately after the string under test but outside the length the widget is given, so the over-read is observable without a sanitizer: the unfixed code counts the out-of-bounds byte and reports a 4-byte row for a 3-byte string, which the test catches as "Expected: 3, Got: 4". Two controls pin the cases that must not change -- a "\r\n" pair genuinely inside the string still counts as two bytes, and a carriage return followed by ordinary text still counts as one. The test also asserts the terminator a multi-line text input adopts from its text, for a lone carriage return and for a "\r\n" pair. Those two cases pass both before and after the change, for the reason given above; they are there to pin the behaviour, not to reproduce a fault. Verified on Linux across all eighteen build configurations, no failures. No documentation change is required: no public API or behaviour contract changes, and the corrected behaviour is what the documented terminator handling already describes. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-24T13:08:29Z

Summary

When GX_DISABLE_DEPRECATED_STRING_API is not defined, gx_api.h now emits a #pragma message compile-time warning directing developers to define GX_DISABLE_DEPRECATED_STRING_API and migrate to the GX_STRING-based (_ext) replacement functions.

The pre-5.6 GX_CHAR * API omits string lengths and cannot safely handle non-NUL-terminated strings or prevent buffer overruns. All new applications should use the replacement variants.

Changes

common/inc/gx_api.h: added #pragma message inside the #ifndef GX_DISABLE_DEPRECATED_STRING_API block.

Companion

Docs: eclipse-threadx/rtos-docs-asciidoc#33 (pending)

When GX_DISABLE_DEPRECATED_STRING_API is not defined (i.e., the pre-5.6 GX_CHAR* API is still enabled), gx_api.h now emits a #pragma message directing developers to define GX_DISABLE_DEPRECATED_STRING_API and migrate to the GX_STRING-based replacement functions. The deprecated functions omit a string length and cannot safely handle non-NUL-terminated strings or prevent buffer overruns. All new applications should use the _ext() replacement variants. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

) _gx_multi_line_text_view_display_info_get() decided whether a line terminator was "\r" or "\r\n" by examining ch.gx_string_ptr[1], the byte after the current character, without checking that a byte remained. When the carriage return is the last byte of the range, that access is outside the caller's buffer. A GX_STRING carries its own length and need not be NUL terminated -- that is why the _ext string API exists, and it is what the deprecation warning added in #167 says about the older char * API. _gx_multi_line_text_view_text_set_ext() stores the caller's GX_STRING verbatim unless GX_STYLE_TEXT_COPY is set, and callers of this function pass end_index = gx_string_length, so in the default configuration the read lands one byte past what the application supplied. The consequence is not only the read. If that byte happens to be 0x0A, the function reports a two-byte terminator for a one-byte remainder, so every caller advances its index by one more than the string holds. In _gx_multi_line_text_view_string_total_rows_compute() the loop then exits with index == gx_string_length + 1 and evaluates string.gx_string_ptr[index - 1], one byte past the end as well, and can add a row that is not in the text. The same over-advance reaches the line index cache in gx_multi_line_text_view_line_cache_update.c and the cursor arithmetic in gx_multi_line_text_input_cursor_pos_update.c. Both reads now go through string rather than ch. string has already been advanced past the current character and its length is exactly the number of bytes still readable there, so guarding on it bounds the access to what the caller supplied. The same idiom in _gx_multi_line_text_input_new_line_character_get() is corrected as well. That one is not currently reachable as a read past the end: its only caller, _gx_multi_line_text_input_text_set_ext(), writes a NUL immediately after the copied text. It is fixed anyway because it depends on an invariant established in a different function and documented nowhere, and because the byte it reads decides whether the widget inserts a one- or two-byte terminator on every subsequent Enter. The rest of the codebase was audited for the same shape. Five other sites handle a carriage return followed by a possible line feed; all five are already correct. gx_rich_text_view_line_info_get.c, gx_multi_line_text_input_char_insert.c and gx_utility_bidi_paragraph_reorder.c guard on the remaining length, the preprocessed-line-break branch at the top of the changed function guards on it too, and gx_multi_line_text_button_line_pointers_set.c walks a NUL-terminated char * buffer where the byte after a carriage return is at worst the terminator. guix_ml_text_line_terminator_bounds_no_output covers this. It places a line feed immediately after the string under test but outside the length the widget is given, so the over-read is observable without a sanitizer: the unfixed code counts the out-of-bounds byte and reports a 4-byte row for a 3-byte string, which the test catches as "Expected: 3, Got: 4". Two controls pin the cases that must not change -- a "\r\n" pair genuinely inside the string still counts as two bytes, and a carriage return followed by ordinary text still counts as one. The test also asserts the terminator a multi-line text input adopts from its text, for a lone carriage return and for a "\r\n" pair. Those two cases pass both before and after the change, for the reason given above; they are there to pin the behaviour, not to reproduce a fault. Verified on Linux across all eighteen build configurations, no failures. No documentation change is required: no public API or behaviour contract changes, and the corrected behaviour is what the documented terminator handling already describes. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-24T13:08:29Z

Summary

When GX_DISABLE_DEPRECATED_STRING_API is not defined, gx_api.h now emits a #pragma message compile-time warning directing developers to define GX_DISABLE_DEPRECATED_STRING_API and migrate to the GX_STRING-based (_ext) replacement functions.

The pre-5.6 GX_CHAR * API omits string lengths and cannot safely handle non-NUL-terminated strings or prevent buffer overruns. All new applications should use the replacement variants.

Changes

common/inc/gx_api.h: added #pragma message inside the #ifndef GX_DISABLE_DEPRECATED_STRING_API block.

Companion

Docs: eclipse-threadx/rtos-docs-asciidoc#33 (pending)

When GX_DISABLE_DEPRECATED_STRING_API is not defined (i.e., the pre-5.6 GX_CHAR* API is still enabled), gx_api.h now emits a #pragma message directing developers to define GX_DISABLE_DEPRECATED_STRING_API and migrate to the GX_STRING-based replacement functions. The deprecated functions omit a string length and cannot safely handle non-NUL-terminated strings or prevent buffer overruns. All new applications should use the _ext() replacement variants. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

) _gx_multi_line_text_view_display_info_get() decided whether a line terminator was "\r" or "\r\n" by examining ch.gx_string_ptr[1], the byte after the current character, without checking that a byte remained. When the carriage return is the last byte of the range, that access is outside the caller's buffer. A GX_STRING carries its own length and need not be NUL terminated -- that is why the _ext string API exists, and it is what the deprecation warning added in #167 says about the older char * API. _gx_multi_line_text_view_text_set_ext() stores the caller's GX_STRING verbatim unless GX_STYLE_TEXT_COPY is set, and callers of this function pass end_index = gx_string_length, so in the default configuration the read lands one byte past what the application supplied. The consequence is not only the read. If that byte happens to be 0x0A, the function reports a two-byte terminator for a one-byte remainder, so every caller advances its index by one more than the string holds. In _gx_multi_line_text_view_string_total_rows_compute() the loop then exits with index == gx_string_length + 1 and evaluates string.gx_string_ptr[index - 1], one byte past the end as well, and can add a row that is not in the text. The same over-advance reaches the line index cache in gx_multi_line_text_view_line_cache_update.c and the cursor arithmetic in gx_multi_line_text_input_cursor_pos_update.c. Both reads now go through string rather than ch. string has already been advanced past the current character and its length is exactly the number of bytes still readable there, so guarding on it bounds the access to what the caller supplied. The same idiom in _gx_multi_line_text_input_new_line_character_get() is corrected as well. That one is not currently reachable as a read past the end: its only caller, _gx_multi_line_text_input_text_set_ext(), writes a NUL immediately after the copied text. It is fixed anyway because it depends on an invariant established in a different function and documented nowhere, and because the byte it reads decides whether the widget inserts a one- or two-byte terminator on every subsequent Enter. The rest of the codebase was audited for the same shape. Five other sites handle a carriage return followed by a possible line feed; all five are already correct. gx_rich_text_view_line_info_get.c, gx_multi_line_text_input_char_insert.c and gx_utility_bidi_paragraph_reorder.c guard on the remaining length, the preprocessed-line-break branch at the top of the changed function guards on it too, and gx_multi_line_text_button_line_pointers_set.c walks a NUL-terminated char * buffer where the byte after a carriage return is at worst the terminator. guix_ml_text_line_terminator_bounds_no_output covers this. It places a line feed immediately after the string under test but outside the length the widget is given, so the over-read is observable without a sanitizer: the unfixed code counts the out-of-bounds byte and reports a 4-byte row for a 3-byte string, which the test catches as "Expected: 3, Got: 4". Two controls pin the cases that must not change -- a "\r\n" pair genuinely inside the string still counts as two bytes, and a carriage return followed by ordinary text still counts as one. The test also asserts the terminator a multi-line text input adopts from its text, for a lone carriage return and for a "\r\n" pair. Those two cases pass both before and after the change, for the reason given above; they are there to pin the behaviour, not to reproduce a fault. Verified on Linux across all eighteen build configurations, no failures. No documentation change is required: no public API or behaviour contract changes, and the corrected behaviour is what the documented terminator handling already describes. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-24T13:08:29Z

Summary

When GX_DISABLE_DEPRECATED_STRING_API is not defined, gx_api.h now emits a #pragma message compile-time warning directing developers to define GX_DISABLE_DEPRECATED_STRING_API and migrate to the GX_STRING-based (_ext) replacement functions.

The pre-5.6 GX_CHAR * API omits string lengths and cannot safely handle non-NUL-terminated strings or prevent buffer overruns. All new applications should use the replacement variants.

Changes

common/inc/gx_api.h: added #pragma message inside the #ifndef GX_DISABLE_DEPRECATED_STRING_API block.

Companion

Docs: eclipse-threadx/rtos-docs-asciidoc#33 (pending)

When GX_DISABLE_DEPRECATED_STRING_API is not defined (i.e., the pre-5.6 GX_CHAR* API is still enabled), gx_api.h now emits a #pragma message directing developers to define GX_DISABLE_DEPRECATED_STRING_API and migrate to the GX_STRING-based replacement functions. The deprecated functions omit a string length and cannot safely handle non-NUL-terminated strings or prevent buffer overruns. All new applications should use the _ext() replacement variants. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

) _gx_multi_line_text_view_display_info_get() decided whether a line terminator was "\r" or "\r\n" by examining ch.gx_string_ptr[1], the byte after the current character, without checking that a byte remained. When the carriage return is the last byte of the range, that access is outside the caller's buffer. A GX_STRING carries its own length and need not be NUL terminated -- that is why the _ext string API exists, and it is what the deprecation warning added in #167 says about the older char * API. _gx_multi_line_text_view_text_set_ext() stores the caller's GX_STRING verbatim unless GX_STYLE_TEXT_COPY is set, and callers of this function pass end_index = gx_string_length, so in the default configuration the read lands one byte past what the application supplied. The consequence is not only the read. If that byte happens to be 0x0A, the function reports a two-byte terminator for a one-byte remainder, so every caller advances its index by one more than the string holds. In _gx_multi_line_text_view_string_total_rows_compute() the loop then exits with index == gx_string_length + 1 and evaluates string.gx_string_ptr[index - 1], one byte past the end as well, and can add a row that is not in the text. The same over-advance reaches the line index cache in gx_multi_line_text_view_line_cache_update.c and the cursor arithmetic in gx_multi_line_text_input_cursor_pos_update.c. Both reads now go through string rather than ch. string has already been advanced past the current character and its length is exactly the number of bytes still readable there, so guarding on it bounds the access to what the caller supplied. The same idiom in _gx_multi_line_text_input_new_line_character_get() is corrected as well. That one is not currently reachable as a read past the end: its only caller, _gx_multi_line_text_input_text_set_ext(), writes a NUL immediately after the copied text. It is fixed anyway because it depends on an invariant established in a different function and documented nowhere, and because the byte it reads decides whether the widget inserts a one- or two-byte terminator on every subsequent Enter. The rest of the codebase was audited for the same shape. Five other sites handle a carriage return followed by a possible line feed; all five are already correct. gx_rich_text_view_line_info_get.c, gx_multi_line_text_input_char_insert.c and gx_utility_bidi_paragraph_reorder.c guard on the remaining length, the preprocessed-line-break branch at the top of the changed function guards on it too, and gx_multi_line_text_button_line_pointers_set.c walks a NUL-terminated char * buffer where the byte after a carriage return is at worst the terminator. guix_ml_text_line_terminator_bounds_no_output covers this. It places a line feed immediately after the string under test but outside the length the widget is given, so the over-read is observable without a sanitizer: the unfixed code counts the out-of-bounds byte and reports a 4-byte row for a 3-byte string, which the test catches as "Expected: 3, Got: 4". Two controls pin the cases that must not change -- a "\r\n" pair genuinely inside the string still counts as two bytes, and a carriage return followed by ordinary text still counts as one. The test also asserts the terminator a multi-line text input adopts from its text, for a lone carriage return and for a "\r\n" pair. Those two cases pass both before and after the change, for the reason given above; they are there to pin the behaviour, not to reproduce a fault. Verified on Linux across all eighteen build configurations, no failures. No documentation change is required: no public API or behaviour contract changes, and the corrected behaviour is what the documented terminator handling already describes. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-24T13:08:29Z

Summary

When GX_DISABLE_DEPRECATED_STRING_API is not defined, gx_api.h now emits a #pragma message compile-time warning directing developers to define GX_DISABLE_DEPRECATED_STRING_API and migrate to the GX_STRING-based (_ext) replacement functions.

The pre-5.6 GX_CHAR * API omits string lengths and cannot safely handle non-NUL-terminated strings or prevent buffer overruns. All new applications should use the replacement variants.

Changes

common/inc/gx_api.h: added #pragma message inside the #ifndef GX_DISABLE_DEPRECATED_STRING_API block.

Companion

Docs: eclipse-threadx/rtos-docs-asciidoc#33 (pending)

When GX_DISABLE_DEPRECATED_STRING_API is not defined (i.e., the pre-5.6 GX_CHAR* API is still enabled), gx_api.h now emits a #pragma message directing developers to define GX_DISABLE_DEPRECATED_STRING_API and migrate to the GX_STRING-based replacement functions. The deprecated functions omit a string length and cannot safely handle non-NUL-terminated strings or prevent buffer overruns. All new applications should use the _ext() replacement variants. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

) _gx_multi_line_text_view_display_info_get() decided whether a line terminator was "\r" or "\r\n" by examining ch.gx_string_ptr[1], the byte after the current character, without checking that a byte remained. When the carriage return is the last byte of the range, that access is outside the caller's buffer. A GX_STRING carries its own length and need not be NUL terminated -- that is why the _ext string API exists, and it is what the deprecation warning added in #167 says about the older char * API. _gx_multi_line_text_view_text_set_ext() stores the caller's GX_STRING verbatim unless GX_STYLE_TEXT_COPY is set, and callers of this function pass end_index = gx_string_length, so in the default configuration the read lands one byte past what the application supplied. The consequence is not only the read. If that byte happens to be 0x0A, the function reports a two-byte terminator for a one-byte remainder, so every caller advances its index by one more than the string holds. In _gx_multi_line_text_view_string_total_rows_compute() the loop then exits with index == gx_string_length + 1 and evaluates string.gx_string_ptr[index - 1], one byte past the end as well, and can add a row that is not in the text. The same over-advance reaches the line index cache in gx_multi_line_text_view_line_cache_update.c and the cursor arithmetic in gx_multi_line_text_input_cursor_pos_update.c. Both reads now go through string rather than ch. string has already been advanced past the current character and its length is exactly the number of bytes still readable there, so guarding on it bounds the access to what the caller supplied. The same idiom in _gx_multi_line_text_input_new_line_character_get() is corrected as well. That one is not currently reachable as a read past the end: its only caller, _gx_multi_line_text_input_text_set_ext(), writes a NUL immediately after the copied text. It is fixed anyway because it depends on an invariant established in a different function and documented nowhere, and because the byte it reads decides whether the widget inserts a one- or two-byte terminator on every subsequent Enter. The rest of the codebase was audited for the same shape. Five other sites handle a carriage return followed by a possible line feed; all five are already correct. gx_rich_text_view_line_info_get.c, gx_multi_line_text_input_char_insert.c and gx_utility_bidi_paragraph_reorder.c guard on the remaining length, the preprocessed-line-break branch at the top of the changed function guards on it too, and gx_multi_line_text_button_line_pointers_set.c walks a NUL-terminated char * buffer where the byte after a carriage return is at worst the terminator. guix_ml_text_line_terminator_bounds_no_output covers this. It places a line feed immediately after the string under test but outside the length the widget is given, so the over-read is observable without a sanitizer: the unfixed code counts the out-of-bounds byte and reports a 4-byte row for a 3-byte string, which the test catches as "Expected: 3, Got: 4". Two controls pin the cases that must not change -- a "\r\n" pair genuinely inside the string still counts as two bytes, and a carriage return followed by ordinary text still counts as one. The test also asserts the terminator a multi-line text input adopts from its text, for a lone carriage return and for a "\r\n" pair. Those two cases pass both before and after the change, for the reason given above; they are there to pin the behaviour, not to reproduce a fault. Verified on Linux across all eighteen build configurations, no failures. No documentation change is required: no public API or behaviour contract changes, and the corrected behaviour is what the documented terminator handling already describes. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-24T13:08:29Z

Summary

When GX_DISABLE_DEPRECATED_STRING_API is not defined, gx_api.h now emits a #pragma message compile-time warning directing developers to define GX_DISABLE_DEPRECATED_STRING_API and migrate to the GX_STRING-based (_ext) replacement functions.

The pre-5.6 GX_CHAR * API omits string lengths and cannot safely handle non-NUL-terminated strings or prevent buffer overruns. All new applications should use the replacement variants.

Changes

common/inc/gx_api.h: added #pragma message inside the #ifndef GX_DISABLE_DEPRECATED_STRING_API block.

Companion

Docs: eclipse-threadx/rtos-docs-asciidoc#33 (pending)

When GX_DISABLE_DEPRECATED_STRING_API is not defined (i.e., the pre-5.6 GX_CHAR* API is still enabled), gx_api.h now emits a #pragma message directing developers to define GX_DISABLE_DEPRECATED_STRING_API and migrate to the GX_STRING-based replacement functions. The deprecated functions omit a string length and cannot safely handle non-NUL-terminated strings or prevent buffer overruns. All new applications should use the _ext() replacement variants. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

) _gx_multi_line_text_view_display_info_get() decided whether a line terminator was "\r" or "\r\n" by examining ch.gx_string_ptr[1], the byte after the current character, without checking that a byte remained. When the carriage return is the last byte of the range, that access is outside the caller's buffer. A GX_STRING carries its own length and need not be NUL terminated -- that is why the _ext string API exists, and it is what the deprecation warning added in #167 says about the older char * API. _gx_multi_line_text_view_text_set_ext() stores the caller's GX_STRING verbatim unless GX_STYLE_TEXT_COPY is set, and callers of this function pass end_index = gx_string_length, so in the default configuration the read lands one byte past what the application supplied. The consequence is not only the read. If that byte happens to be 0x0A, the function reports a two-byte terminator for a one-byte remainder, so every caller advances its index by one more than the string holds. In _gx_multi_line_text_view_string_total_rows_compute() the loop then exits with index == gx_string_length + 1 and evaluates string.gx_string_ptr[index - 1], one byte past the end as well, and can add a row that is not in the text. The same over-advance reaches the line index cache in gx_multi_line_text_view_line_cache_update.c and the cursor arithmetic in gx_multi_line_text_input_cursor_pos_update.c. Both reads now go through string rather than ch. string has already been advanced past the current character and its length is exactly the number of bytes still readable there, so guarding on it bounds the access to what the caller supplied. The same idiom in _gx_multi_line_text_input_new_line_character_get() is corrected as well. That one is not currently reachable as a read past the end: its only caller, _gx_multi_line_text_input_text_set_ext(), writes a NUL immediately after the copied text. It is fixed anyway because it depends on an invariant established in a different function and documented nowhere, and because the byte it reads decides whether the widget inserts a one- or two-byte terminator on every subsequent Enter. The rest of the codebase was audited for the same shape. Five other sites handle a carriage return followed by a possible line feed; all five are already correct. gx_rich_text_view_line_info_get.c, gx_multi_line_text_input_char_insert.c and gx_utility_bidi_paragraph_reorder.c guard on the remaining length, the preprocessed-line-break branch at the top of the changed function guards on it too, and gx_multi_line_text_button_line_pointers_set.c walks a NUL-terminated char * buffer where the byte after a carriage return is at worst the terminator. guix_ml_text_line_terminator_bounds_no_output covers this. It places a line feed immediately after the string under test but outside the length the widget is given, so the over-read is observable without a sanitizer: the unfixed code counts the out-of-bounds byte and reports a 4-byte row for a 3-byte string, which the test catches as "Expected: 3, Got: 4". Two controls pin the cases that must not change -- a "\r\n" pair genuinely inside the string still counts as two bytes, and a carriage return followed by ordinary text still counts as one. The test also asserts the terminator a multi-line text input adopts from its text, for a lone carriage return and for a "\r\n" pair. Those two cases pass both before and after the change, for the reason given above; they are there to pin the behaviour, not to reproduce a fault. Verified on Linux across all eighteen build configurations, no failures. No documentation change is required: no public API or behaviour contract changes, and the corrected behaviour is what the documented terminator handling already describes. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-24T13:08:29Z

Summary

When GX_DISABLE_DEPRECATED_STRING_API is not defined, gx_api.h now emits a #pragma message compile-time warning directing developers to define GX_DISABLE_DEPRECATED_STRING_API and migrate to the GX_STRING-based (_ext) replacement functions.

The pre-5.6 GX_CHAR * API omits string lengths and cannot safely handle non-NUL-terminated strings or prevent buffer overruns. All new applications should use the replacement variants.

Changes

common/inc/gx_api.h: added #pragma message inside the #ifndef GX_DISABLE_DEPRECATED_STRING_API block.

Companion

Docs: eclipse-threadx/rtos-docs-asciidoc#33 (pending)

When GX_DISABLE_DEPRECATED_STRING_API is not defined (i.e., the pre-5.6 GX_CHAR* API is still enabled), gx_api.h now emits a #pragma message directing developers to define GX_DISABLE_DEPRECATED_STRING_API and migrate to the GX_STRING-based replacement functions. The deprecated functions omit a string length and cannot safely handle non-NUL-terminated strings or prevent buffer overruns. All new applications should use the _ext() replacement variants. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

) _gx_multi_line_text_view_display_info_get() decided whether a line terminator was "\r" or "\r\n" by examining ch.gx_string_ptr[1], the byte after the current character, without checking that a byte remained. When the carriage return is the last byte of the range, that access is outside the caller's buffer. A GX_STRING carries its own length and need not be NUL terminated -- that is why the _ext string API exists, and it is what the deprecation warning added in #167 says about the older char * API. _gx_multi_line_text_view_text_set_ext() stores the caller's GX_STRING verbatim unless GX_STYLE_TEXT_COPY is set, and callers of this function pass end_index = gx_string_length, so in the default configuration the read lands one byte past what the application supplied. The consequence is not only the read. If that byte happens to be 0x0A, the function reports a two-byte terminator for a one-byte remainder, so every caller advances its index by one more than the string holds. In _gx_multi_line_text_view_string_total_rows_compute() the loop then exits with index == gx_string_length + 1 and evaluates string.gx_string_ptr[index - 1], one byte past the end as well, and can add a row that is not in the text. The same over-advance reaches the line index cache in gx_multi_line_text_view_line_cache_update.c and the cursor arithmetic in gx_multi_line_text_input_cursor_pos_update.c. Both reads now go through string rather than ch. string has already been advanced past the current character and its length is exactly the number of bytes still readable there, so guarding on it bounds the access to what the caller supplied. The same idiom in _gx_multi_line_text_input_new_line_character_get() is corrected as well. That one is not currently reachable as a read past the end: its only caller, _gx_multi_line_text_input_text_set_ext(), writes a NUL immediately after the copied text. It is fixed anyway because it depends on an invariant established in a different function and documented nowhere, and because the byte it reads decides whether the widget inserts a one- or two-byte terminator on every subsequent Enter. The rest of the codebase was audited for the same shape. Five other sites handle a carriage return followed by a possible line feed; all five are already correct. gx_rich_text_view_line_info_get.c, gx_multi_line_text_input_char_insert.c and gx_utility_bidi_paragraph_reorder.c guard on the remaining length, the preprocessed-line-break branch at the top of the changed function guards on it too, and gx_multi_line_text_button_line_pointers_set.c walks a NUL-terminated char * buffer where the byte after a carriage return is at worst the terminator. guix_ml_text_line_terminator_bounds_no_output covers this. It places a line feed immediately after the string under test but outside the length the widget is given, so the over-read is observable without a sanitizer: the unfixed code counts the out-of-bounds byte and reports a 4-byte row for a 3-byte string, which the test catches as "Expected: 3, Got: 4". Two controls pin the cases that must not change -- a "\r\n" pair genuinely inside the string still counts as two bytes, and a carriage return followed by ordinary text still counts as one. The test also asserts the terminator a multi-line text input adopts from its text, for a lone carriage return and for a "\r\n" pair. Those two cases pass both before and after the change, for the reason given above; they are there to pin the behaviour, not to reproduce a fault. Verified on Linux across all eighteen build configurations, no failures. No documentation change is required: no public API or behaviour contract changes, and the corrected behaviour is what the documented terminator handling already describes. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>