fixed MISRA rule violation.

[parsley]

This fixed a rule violation for my MISRA checker.

[fdesbiens]

Thanks for this, @parsley — you found a real defect, and you found all of it. The four macros you touched are every semicolon-terminated gx_* macro definition in common/inc/, and the eight whitespace fixes clear all remaining trailing whitespace in the file, so this won't come back as diff noise later.

I can't approve it as it stands, though, because of one out-of-diff casualty. Two things to sort out:

1. It breaks the GUIX Studio build.guix_studio/properties_win.cpp:2705 calls gx_system_dirty_mark(mpInfo->widget) with no semicolon of its own, leaning on the one the macro used to supply:

gx_system_dirty_mark(mpInfo->widget) // <-- no semicolon
mpProject->SetModified();

After your change that expands to _gx_system_dirty_mark((GX_WIDGET *)mpInfo->widget) mpProject->SetModified();, which is a hard syntax error in both the error-checking and non-error-checking configurations. Please add the missing ; there in this same PR.

That is the only such site — I swept the tree, and all 2315 gx_system_dirty_mark, 10 gx_progress_bar_info_set, and 36 gx_single_line_text_input_style_add references are otherwise either properly terminated or documentation comments.

Fair warning that our CI will not tell you this. All five workflows are gated on branches: [ master ] or workflow_dispatch, and this PR targets dev, so eclipsefdn/eca is the only check that runs. The breakage would have surfaced at the eventual dev → master merge and been blamed on the wrong change. That gap is ours to fix, not yours.

2. Please expand the description. "This fixed a rule violation for my MISRA checker" undersells the change considerably, and it doesn't name the rule — our convention is to cite it explicitly (this pattern is usually flagged under MISRA C:2004 Rule 19.4). More importantly, the correctness argument stands on its own without any checker; see my note on the first macro below.

One expectation to set for anyone reading this later: it does not make gx_api.h MISRA-clean. The macros still expand to function-call expressions rather than a parenthesised expression or a do { } while(0) construct, and the header's whole API-mapping design conflicts with MISRA C:2012 Dir 4.9. That is a deliberate, long-standing choice — this PR silences one diagnostic rather than resolving the category, which is fine and still worth doing.

Nothing else raises a flag: preprocessor-only, so identical generated code and no size or speed impact; no API/ABI change and so no rtos-docs-asciidoc update needed; the file already carries Copyright (c) 2026 Eclipse ThreadX contributors; and the branch targets dev correctly.

Requesting changes — happy to approve once properties_win.cpp:2705 has its semicolon.

[fdesbiens]

Worth stating in the PR description that this is a correctness fix, not just a checker complaint. Because these are UINT-returning services, the trailing semicolon made the documented API unusable in valid C:

if (gx_single_line_text_input_style_add(input, style) !=GX_SUCCESS) /* syntax error before this PR */if (cond) gx_single_line_text_input_style_add(input, style); else ... /* "else without a previous if" */

The first is exactly what a safety-conscious application does with a status-returning call. Note the _gxe_ counterpart at line 4794 was already correct, so this restores symmetry between the two blocks rather than changing a deliberate convention.

[fdesbiens]

This is the one that breaks the build.guix_studio/properties_win.cpp:2705 calls gx_system_dirty_mark(mpInfo->widget) without a trailing semicolon of its own and relies on the macro to supply it. Once this line changes, that expands into _gx_system_dirty_mark(...) mpProject->SetModified(); and fails to compile.

Please fix the call site in this PR — adding ; at properties_win.cpp:2705 is the whole change. It is the only site in the tree that depends on the embedded semicolon.

[fdesbiens]

Good catch on the asymmetry here: the _gx_ counterpart at line 3209 was already correct, so the defect existed only in the error-checking block — the mirror image of the gx_single_line_text_input_style_add case above, where only the non-error-checking block was affected. Easy pair to half-fix; you got both.

[fdesbiens]

This one was wrong in both blocks, so with line 3364 the macro is now consistent across configurations.

Since nothing in the regression suite would have caught the original defect — test/guix_test/regression_test/tests/validation_guix_system_no_output.c:147 exercises _gx_system_dirty_mark directly and bypasses the macro entirely — could you add a compile-only check that uses each of the four macros in expression context? Something as small as:

if (gx_system_dirty_mark(widget) !=GX_SUCCESS)
{
/* ... */
}

It never has to run; failing to compile is the assertion. That is a one-time, near-zero-cost guard for this whole class of regression across the ~1000 API macros, and it satisfies the project's coverage requirement for the change.

[fdesbiens]

No objection to bundling these with the semicolon fix — they're confined to the same file and leave it clean. For the record, I checked whether any of the eight sat after a line-continuation backslash, where trailing whitespace would be an actual defect rather than cosmetic: none did, including this one at the end of GX_GLYPH_MEMBERS_DECLARE. So these are purely cosmetic and carry no risk.

[parsley]

Thank you for the review of my PR.
Actually in my case I got a MISRA rule 14.3 violation due to the second semicolon I added in my own file where I used the marco.
I added the semicolon in properties_win.cpp and committed it.

Anything I missed?

[parsley]

This fixed a rule violation for my MISRA checker.

[fdesbiens]

Thanks for this, @parsley — you found a real defect, and you found all of it. The four macros you touched are every semicolon-terminated gx_* macro definition in common/inc/, and the eight whitespace fixes clear all remaining trailing whitespace in the file, so this won't come back as diff noise later.

I can't approve it as it stands, though, because of one out-of-diff casualty. Two things to sort out:

1. It breaks the GUIX Studio build.guix_studio/properties_win.cpp:2705 calls gx_system_dirty_mark(mpInfo->widget) with no semicolon of its own, leaning on the one the macro used to supply:

gx_system_dirty_mark(mpInfo->widget) // <-- no semicolon
mpProject->SetModified();

After your change that expands to _gx_system_dirty_mark((GX_WIDGET *)mpInfo->widget) mpProject->SetModified();, which is a hard syntax error in both the error-checking and non-error-checking configurations. Please add the missing ; there in this same PR.

That is the only such site — I swept the tree, and all 2315 gx_system_dirty_mark, 10 gx_progress_bar_info_set, and 36 gx_single_line_text_input_style_add references are otherwise either properly terminated or documentation comments.

Fair warning that our CI will not tell you this. All five workflows are gated on branches: [ master ] or workflow_dispatch, and this PR targets dev, so eclipsefdn/eca is the only check that runs. The breakage would have surfaced at the eventual dev → master merge and been blamed on the wrong change. That gap is ours to fix, not yours.

2. Please expand the description. "This fixed a rule violation for my MISRA checker" undersells the change considerably, and it doesn't name the rule — our convention is to cite it explicitly (this pattern is usually flagged under MISRA C:2004 Rule 19.4). More importantly, the correctness argument stands on its own without any checker; see my note on the first macro below.

One expectation to set for anyone reading this later: it does not make gx_api.h MISRA-clean. The macros still expand to function-call expressions rather than a parenthesised expression or a do { } while(0) construct, and the header's whole API-mapping design conflicts with MISRA C:2012 Dir 4.9. That is a deliberate, long-standing choice — this PR silences one diagnostic rather than resolving the category, which is fine and still worth doing.

Nothing else raises a flag: preprocessor-only, so identical generated code and no size or speed impact; no API/ABI change and so no rtos-docs-asciidoc update needed; the file already carries Copyright (c) 2026 Eclipse ThreadX contributors; and the branch targets dev correctly.

Requesting changes — happy to approve once properties_win.cpp:2705 has its semicolon.

[fdesbiens]

Worth stating in the PR description that this is a correctness fix, not just a checker complaint. Because these are UINT-returning services, the trailing semicolon made the documented API unusable in valid C:

if (gx_single_line_text_input_style_add(input, style) !=GX_SUCCESS) /* syntax error before this PR */if (cond) gx_single_line_text_input_style_add(input, style); else ... /* "else without a previous if" */

The first is exactly what a safety-conscious application does with a status-returning call. Note the _gxe_ counterpart at line 4794 was already correct, so this restores symmetry between the two blocks rather than changing a deliberate convention.

[fdesbiens]

This is the one that breaks the build.guix_studio/properties_win.cpp:2705 calls gx_system_dirty_mark(mpInfo->widget) without a trailing semicolon of its own and relies on the macro to supply it. Once this line changes, that expands into _gx_system_dirty_mark(...) mpProject->SetModified(); and fails to compile.

Please fix the call site in this PR — adding ; at properties_win.cpp:2705 is the whole change. It is the only site in the tree that depends on the embedded semicolon.

[fdesbiens]

Good catch on the asymmetry here: the _gx_ counterpart at line 3209 was already correct, so the defect existed only in the error-checking block — the mirror image of the gx_single_line_text_input_style_add case above, where only the non-error-checking block was affected. Easy pair to half-fix; you got both.

[fdesbiens]

This one was wrong in both blocks, so with line 3364 the macro is now consistent across configurations.

Since nothing in the regression suite would have caught the original defect — test/guix_test/regression_test/tests/validation_guix_system_no_output.c:147 exercises _gx_system_dirty_mark directly and bypasses the macro entirely — could you add a compile-only check that uses each of the four macros in expression context? Something as small as:

if (gx_system_dirty_mark(widget) !=GX_SUCCESS)
{
/* ... */
}

It never has to run; failing to compile is the assertion. That is a one-time, near-zero-cost guard for this whole class of regression across the ~1000 API macros, and it satisfies the project's coverage requirement for the change.

[fdesbiens]

No objection to bundling these with the semicolon fix — they're confined to the same file and leave it clean. For the record, I checked whether any of the eight sat after a line-continuation backslash, where trailing whitespace would be an actual defect rather than cosmetic: none did, including this one at the end of GX_GLYPH_MEMBERS_DECLARE. So these are purely cosmetic and carry no risk.

[parsley]

Thank you for the review of my PR.
Actually in my case I got a MISRA rule 14.3 violation due to the second semicolon I added in my own file where I used the marco.
I added the semicolon in properties_win.cpp and committed it.

Anything I missed?

[parsley]

This fixed a rule violation for my MISRA checker.

[fdesbiens]

Thanks for this, @parsley — you found a real defect, and you found all of it. The four macros you touched are every semicolon-terminated gx_* macro definition in common/inc/, and the eight whitespace fixes clear all remaining trailing whitespace in the file, so this won't come back as diff noise later.

I can't approve it as it stands, though, because of one out-of-diff casualty. Two things to sort out:

1. It breaks the GUIX Studio build.guix_studio/properties_win.cpp:2705 calls gx_system_dirty_mark(mpInfo->widget) with no semicolon of its own, leaning on the one the macro used to supply:

gx_system_dirty_mark(mpInfo->widget) // <-- no semicolon
mpProject->SetModified();

After your change that expands to _gx_system_dirty_mark((GX_WIDGET *)mpInfo->widget) mpProject->SetModified();, which is a hard syntax error in both the error-checking and non-error-checking configurations. Please add the missing ; there in this same PR.

That is the only such site — I swept the tree, and all 2315 gx_system_dirty_mark, 10 gx_progress_bar_info_set, and 36 gx_single_line_text_input_style_add references are otherwise either properly terminated or documentation comments.

Fair warning that our CI will not tell you this. All five workflows are gated on branches: [ master ] or workflow_dispatch, and this PR targets dev, so eclipsefdn/eca is the only check that runs. The breakage would have surfaced at the eventual dev → master merge and been blamed on the wrong change. That gap is ours to fix, not yours.

2. Please expand the description. "This fixed a rule violation for my MISRA checker" undersells the change considerably, and it doesn't name the rule — our convention is to cite it explicitly (this pattern is usually flagged under MISRA C:2004 Rule 19.4). More importantly, the correctness argument stands on its own without any checker; see my note on the first macro below.

One expectation to set for anyone reading this later: it does not make gx_api.h MISRA-clean. The macros still expand to function-call expressions rather than a parenthesised expression or a do { } while(0) construct, and the header's whole API-mapping design conflicts with MISRA C:2012 Dir 4.9. That is a deliberate, long-standing choice — this PR silences one diagnostic rather than resolving the category, which is fine and still worth doing.

Nothing else raises a flag: preprocessor-only, so identical generated code and no size or speed impact; no API/ABI change and so no rtos-docs-asciidoc update needed; the file already carries Copyright (c) 2026 Eclipse ThreadX contributors; and the branch targets dev correctly.

Requesting changes — happy to approve once properties_win.cpp:2705 has its semicolon.

[fdesbiens]

Worth stating in the PR description that this is a correctness fix, not just a checker complaint. Because these are UINT-returning services, the trailing semicolon made the documented API unusable in valid C:

if (gx_single_line_text_input_style_add(input, style) !=GX_SUCCESS) /* syntax error before this PR */if (cond) gx_single_line_text_input_style_add(input, style); else ... /* "else without a previous if" */

The first is exactly what a safety-conscious application does with a status-returning call. Note the _gxe_ counterpart at line 4794 was already correct, so this restores symmetry between the two blocks rather than changing a deliberate convention.

[fdesbiens]

This is the one that breaks the build.guix_studio/properties_win.cpp:2705 calls gx_system_dirty_mark(mpInfo->widget) without a trailing semicolon of its own and relies on the macro to supply it. Once this line changes, that expands into _gx_system_dirty_mark(...) mpProject->SetModified(); and fails to compile.

Please fix the call site in this PR — adding ; at properties_win.cpp:2705 is the whole change. It is the only site in the tree that depends on the embedded semicolon.

[fdesbiens]

Good catch on the asymmetry here: the _gx_ counterpart at line 3209 was already correct, so the defect existed only in the error-checking block — the mirror image of the gx_single_line_text_input_style_add case above, where only the non-error-checking block was affected. Easy pair to half-fix; you got both.

[fdesbiens]

This one was wrong in both blocks, so with line 3364 the macro is now consistent across configurations.

Since nothing in the regression suite would have caught the original defect — test/guix_test/regression_test/tests/validation_guix_system_no_output.c:147 exercises _gx_system_dirty_mark directly and bypasses the macro entirely — could you add a compile-only check that uses each of the four macros in expression context? Something as small as:

if (gx_system_dirty_mark(widget) !=GX_SUCCESS)
{
/* ... */
}

It never has to run; failing to compile is the assertion. That is a one-time, near-zero-cost guard for this whole class of regression across the ~1000 API macros, and it satisfies the project's coverage requirement for the change.

[fdesbiens]

No objection to bundling these with the semicolon fix — they're confined to the same file and leave it clean. For the record, I checked whether any of the eight sat after a line-continuation backslash, where trailing whitespace would be an actual defect rather than cosmetic: none did, including this one at the end of GX_GLYPH_MEMBERS_DECLARE. So these are purely cosmetic and carry no risk.

[parsley]

Thank you for the review of my PR.
Actually in my case I got a MISRA rule 14.3 violation due to the second semicolon I added in my own file where I used the marco.
I added the semicolon in properties_win.cpp and committed it.

Anything I missed?

[parsley]

This fixed a rule violation for my MISRA checker.

[fdesbiens]

Thanks for this, @parsley — you found a real defect, and you found all of it. The four macros you touched are every semicolon-terminated gx_* macro definition in common/inc/, and the eight whitespace fixes clear all remaining trailing whitespace in the file, so this won't come back as diff noise later.

I can't approve it as it stands, though, because of one out-of-diff casualty. Two things to sort out:

1. It breaks the GUIX Studio build.guix_studio/properties_win.cpp:2705 calls gx_system_dirty_mark(mpInfo->widget) with no semicolon of its own, leaning on the one the macro used to supply:

gx_system_dirty_mark(mpInfo->widget) // <-- no semicolon
mpProject->SetModified();

After your change that expands to _gx_system_dirty_mark((GX_WIDGET *)mpInfo->widget) mpProject->SetModified();, which is a hard syntax error in both the error-checking and non-error-checking configurations. Please add the missing ; there in this same PR.

That is the only such site — I swept the tree, and all 2315 gx_system_dirty_mark, 10 gx_progress_bar_info_set, and 36 gx_single_line_text_input_style_add references are otherwise either properly terminated or documentation comments.

Fair warning that our CI will not tell you this. All five workflows are gated on branches: [ master ] or workflow_dispatch, and this PR targets dev, so eclipsefdn/eca is the only check that runs. The breakage would have surfaced at the eventual dev → master merge and been blamed on the wrong change. That gap is ours to fix, not yours.

2. Please expand the description. "This fixed a rule violation for my MISRA checker" undersells the change considerably, and it doesn't name the rule — our convention is to cite it explicitly (this pattern is usually flagged under MISRA C:2004 Rule 19.4). More importantly, the correctness argument stands on its own without any checker; see my note on the first macro below.

One expectation to set for anyone reading this later: it does not make gx_api.h MISRA-clean. The macros still expand to function-call expressions rather than a parenthesised expression or a do { } while(0) construct, and the header's whole API-mapping design conflicts with MISRA C:2012 Dir 4.9. That is a deliberate, long-standing choice — this PR silences one diagnostic rather than resolving the category, which is fine and still worth doing.

Nothing else raises a flag: preprocessor-only, so identical generated code and no size or speed impact; no API/ABI change and so no rtos-docs-asciidoc update needed; the file already carries Copyright (c) 2026 Eclipse ThreadX contributors; and the branch targets dev correctly.

Requesting changes — happy to approve once properties_win.cpp:2705 has its semicolon.

[fdesbiens]

Worth stating in the PR description that this is a correctness fix, not just a checker complaint. Because these are UINT-returning services, the trailing semicolon made the documented API unusable in valid C:

if (gx_single_line_text_input_style_add(input, style) !=GX_SUCCESS) /* syntax error before this PR */if (cond) gx_single_line_text_input_style_add(input, style); else ... /* "else without a previous if" */

The first is exactly what a safety-conscious application does with a status-returning call. Note the _gxe_ counterpart at line 4794 was already correct, so this restores symmetry between the two blocks rather than changing a deliberate convention.

[fdesbiens]

This is the one that breaks the build.guix_studio/properties_win.cpp:2705 calls gx_system_dirty_mark(mpInfo->widget) without a trailing semicolon of its own and relies on the macro to supply it. Once this line changes, that expands into _gx_system_dirty_mark(...) mpProject->SetModified(); and fails to compile.

Please fix the call site in this PR — adding ; at properties_win.cpp:2705 is the whole change. It is the only site in the tree that depends on the embedded semicolon.

[fdesbiens]

Good catch on the asymmetry here: the _gx_ counterpart at line 3209 was already correct, so the defect existed only in the error-checking block — the mirror image of the gx_single_line_text_input_style_add case above, where only the non-error-checking block was affected. Easy pair to half-fix; you got both.

[fdesbiens]

This one was wrong in both blocks, so with line 3364 the macro is now consistent across configurations.

Since nothing in the regression suite would have caught the original defect — test/guix_test/regression_test/tests/validation_guix_system_no_output.c:147 exercises _gx_system_dirty_mark directly and bypasses the macro entirely — could you add a compile-only check that uses each of the four macros in expression context? Something as small as:

if (gx_system_dirty_mark(widget) !=GX_SUCCESS)
{
/* ... */
}

It never has to run; failing to compile is the assertion. That is a one-time, near-zero-cost guard for this whole class of regression across the ~1000 API macros, and it satisfies the project's coverage requirement for the change.

[fdesbiens]

No objection to bundling these with the semicolon fix — they're confined to the same file and leave it clean. For the record, I checked whether any of the eight sat after a line-continuation backslash, where trailing whitespace would be an actual defect rather than cosmetic: none did, including this one at the end of GX_GLYPH_MEMBERS_DECLARE. So these are purely cosmetic and carry no risk.

[parsley]

Thank you for the review of my PR.
Actually in my case I got a MISRA rule 14.3 violation due to the second semicolon I added in my own file where I used the marco.
I added the semicolon in properties_win.cpp and committed it.

Anything I missed?

[parsley]

This fixed a rule violation for my MISRA checker.

[fdesbiens]

Thanks for this, @parsley — you found a real defect, and you found all of it. The four macros you touched are every semicolon-terminated gx_* macro definition in common/inc/, and the eight whitespace fixes clear all remaining trailing whitespace in the file, so this won't come back as diff noise later.

I can't approve it as it stands, though, because of one out-of-diff casualty. Two things to sort out:

1. It breaks the GUIX Studio build.guix_studio/properties_win.cpp:2705 calls gx_system_dirty_mark(mpInfo->widget) with no semicolon of its own, leaning on the one the macro used to supply:

gx_system_dirty_mark(mpInfo->widget) // <-- no semicolon
mpProject->SetModified();

After your change that expands to _gx_system_dirty_mark((GX_WIDGET *)mpInfo->widget) mpProject->SetModified();, which is a hard syntax error in both the error-checking and non-error-checking configurations. Please add the missing ; there in this same PR.

That is the only such site — I swept the tree, and all 2315 gx_system_dirty_mark, 10 gx_progress_bar_info_set, and 36 gx_single_line_text_input_style_add references are otherwise either properly terminated or documentation comments.

Fair warning that our CI will not tell you this. All five workflows are gated on branches: [ master ] or workflow_dispatch, and this PR targets dev, so eclipsefdn/eca is the only check that runs. The breakage would have surfaced at the eventual dev → master merge and been blamed on the wrong change. That gap is ours to fix, not yours.

2. Please expand the description. "This fixed a rule violation for my MISRA checker" undersells the change considerably, and it doesn't name the rule — our convention is to cite it explicitly (this pattern is usually flagged under MISRA C:2004 Rule 19.4). More importantly, the correctness argument stands on its own without any checker; see my note on the first macro below.

One expectation to set for anyone reading this later: it does not make gx_api.h MISRA-clean. The macros still expand to function-call expressions rather than a parenthesised expression or a do { } while(0) construct, and the header's whole API-mapping design conflicts with MISRA C:2012 Dir 4.9. That is a deliberate, long-standing choice — this PR silences one diagnostic rather than resolving the category, which is fine and still worth doing.

Nothing else raises a flag: preprocessor-only, so identical generated code and no size or speed impact; no API/ABI change and so no rtos-docs-asciidoc update needed; the file already carries Copyright (c) 2026 Eclipse ThreadX contributors; and the branch targets dev correctly.

Requesting changes — happy to approve once properties_win.cpp:2705 has its semicolon.

[fdesbiens]

Worth stating in the PR description that this is a correctness fix, not just a checker complaint. Because these are UINT-returning services, the trailing semicolon made the documented API unusable in valid C:

if (gx_single_line_text_input_style_add(input, style) !=GX_SUCCESS) /* syntax error before this PR */if (cond) gx_single_line_text_input_style_add(input, style); else ... /* "else without a previous if" */

The first is exactly what a safety-conscious application does with a status-returning call. Note the _gxe_ counterpart at line 4794 was already correct, so this restores symmetry between the two blocks rather than changing a deliberate convention.

[fdesbiens]

This is the one that breaks the build.guix_studio/properties_win.cpp:2705 calls gx_system_dirty_mark(mpInfo->widget) without a trailing semicolon of its own and relies on the macro to supply it. Once this line changes, that expands into _gx_system_dirty_mark(...) mpProject->SetModified(); and fails to compile.

Please fix the call site in this PR — adding ; at properties_win.cpp:2705 is the whole change. It is the only site in the tree that depends on the embedded semicolon.

[fdesbiens]

Good catch on the asymmetry here: the _gx_ counterpart at line 3209 was already correct, so the defect existed only in the error-checking block — the mirror image of the gx_single_line_text_input_style_add case above, where only the non-error-checking block was affected. Easy pair to half-fix; you got both.

[fdesbiens]

This one was wrong in both blocks, so with line 3364 the macro is now consistent across configurations.

Since nothing in the regression suite would have caught the original defect — test/guix_test/regression_test/tests/validation_guix_system_no_output.c:147 exercises _gx_system_dirty_mark directly and bypasses the macro entirely — could you add a compile-only check that uses each of the four macros in expression context? Something as small as:

if (gx_system_dirty_mark(widget) !=GX_SUCCESS)
{
/* ... */
}

It never has to run; failing to compile is the assertion. That is a one-time, near-zero-cost guard for this whole class of regression across the ~1000 API macros, and it satisfies the project's coverage requirement for the change.

[fdesbiens]

No objection to bundling these with the semicolon fix — they're confined to the same file and leave it clean. For the record, I checked whether any of the eight sat after a line-continuation backslash, where trailing whitespace would be an actual defect rather than cosmetic: none did, including this one at the end of GX_GLYPH_MEMBERS_DECLARE. So these are purely cosmetic and carry no risk.

[parsley]

Thank you for the review of my PR.
Actually in my case I got a MISRA rule 14.3 violation due to the second semicolon I added in my own file where I used the marco.
I added the semicolon in properties_win.cpp and committed it.

Anything I missed?

[parsley]

This fixed a rule violation for my MISRA checker.

[fdesbiens]

Thanks for this, @parsley — you found a real defect, and you found all of it. The four macros you touched are every semicolon-terminated gx_* macro definition in common/inc/, and the eight whitespace fixes clear all remaining trailing whitespace in the file, so this won't come back as diff noise later.

I can't approve it as it stands, though, because of one out-of-diff casualty. Two things to sort out:

1. It breaks the GUIX Studio build.guix_studio/properties_win.cpp:2705 calls gx_system_dirty_mark(mpInfo->widget) with no semicolon of its own, leaning on the one the macro used to supply:

gx_system_dirty_mark(mpInfo->widget) // <-- no semicolon
mpProject->SetModified();

After your change that expands to _gx_system_dirty_mark((GX_WIDGET *)mpInfo->widget) mpProject->SetModified();, which is a hard syntax error in both the error-checking and non-error-checking configurations. Please add the missing ; there in this same PR.

That is the only such site — I swept the tree, and all 2315 gx_system_dirty_mark, 10 gx_progress_bar_info_set, and 36 gx_single_line_text_input_style_add references are otherwise either properly terminated or documentation comments.

Fair warning that our CI will not tell you this. All five workflows are gated on branches: [ master ] or workflow_dispatch, and this PR targets dev, so eclipsefdn/eca is the only check that runs. The breakage would have surfaced at the eventual dev → master merge and been blamed on the wrong change. That gap is ours to fix, not yours.

2. Please expand the description. "This fixed a rule violation for my MISRA checker" undersells the change considerably, and it doesn't name the rule — our convention is to cite it explicitly (this pattern is usually flagged under MISRA C:2004 Rule 19.4). More importantly, the correctness argument stands on its own without any checker; see my note on the first macro below.

One expectation to set for anyone reading this later: it does not make gx_api.h MISRA-clean. The macros still expand to function-call expressions rather than a parenthesised expression or a do { } while(0) construct, and the header's whole API-mapping design conflicts with MISRA C:2012 Dir 4.9. That is a deliberate, long-standing choice — this PR silences one diagnostic rather than resolving the category, which is fine and still worth doing.

Nothing else raises a flag: preprocessor-only, so identical generated code and no size or speed impact; no API/ABI change and so no rtos-docs-asciidoc update needed; the file already carries Copyright (c) 2026 Eclipse ThreadX contributors; and the branch targets dev correctly.

Requesting changes — happy to approve once properties_win.cpp:2705 has its semicolon.

[fdesbiens]

Worth stating in the PR description that this is a correctness fix, not just a checker complaint. Because these are UINT-returning services, the trailing semicolon made the documented API unusable in valid C:

if (gx_single_line_text_input_style_add(input, style) !=GX_SUCCESS) /* syntax error before this PR */if (cond) gx_single_line_text_input_style_add(input, style); else ... /* "else without a previous if" */

The first is exactly what a safety-conscious application does with a status-returning call. Note the _gxe_ counterpart at line 4794 was already correct, so this restores symmetry between the two blocks rather than changing a deliberate convention.

[fdesbiens]

This is the one that breaks the build.guix_studio/properties_win.cpp:2705 calls gx_system_dirty_mark(mpInfo->widget) without a trailing semicolon of its own and relies on the macro to supply it. Once this line changes, that expands into _gx_system_dirty_mark(...) mpProject->SetModified(); and fails to compile.

Please fix the call site in this PR — adding ; at properties_win.cpp:2705 is the whole change. It is the only site in the tree that depends on the embedded semicolon.

[fdesbiens]

Good catch on the asymmetry here: the _gx_ counterpart at line 3209 was already correct, so the defect existed only in the error-checking block — the mirror image of the gx_single_line_text_input_style_add case above, where only the non-error-checking block was affected. Easy pair to half-fix; you got both.

[fdesbiens]

This one was wrong in both blocks, so with line 3364 the macro is now consistent across configurations.

Since nothing in the regression suite would have caught the original defect — test/guix_test/regression_test/tests/validation_guix_system_no_output.c:147 exercises _gx_system_dirty_mark directly and bypasses the macro entirely — could you add a compile-only check that uses each of the four macros in expression context? Something as small as:

if (gx_system_dirty_mark(widget) !=GX_SUCCESS)
{
/* ... */
}

It never has to run; failing to compile is the assertion. That is a one-time, near-zero-cost guard for this whole class of regression across the ~1000 API macros, and it satisfies the project's coverage requirement for the change.

[fdesbiens]

No objection to bundling these with the semicolon fix — they're confined to the same file and leave it clean. For the record, I checked whether any of the eight sat after a line-continuation backslash, where trailing whitespace would be an actual defect rather than cosmetic: none did, including this one at the end of GX_GLYPH_MEMBERS_DECLARE. So these are purely cosmetic and carry no risk.

[parsley]

Thank you for the review of my PR.
Actually in my case I got a MISRA rule 14.3 violation due to the second semicolon I added in my own file where I used the marco.
I added the semicolon in properties_win.cpp and committed it.

Anything I missed?

[parsley]

This fixed a rule violation for my MISRA checker.

[fdesbiens]

Thanks for this, @parsley — you found a real defect, and you found all of it. The four macros you touched are every semicolon-terminated gx_* macro definition in common/inc/, and the eight whitespace fixes clear all remaining trailing whitespace in the file, so this won't come back as diff noise later.

I can't approve it as it stands, though, because of one out-of-diff casualty. Two things to sort out:

1. It breaks the GUIX Studio build.guix_studio/properties_win.cpp:2705 calls gx_system_dirty_mark(mpInfo->widget) with no semicolon of its own, leaning on the one the macro used to supply:

gx_system_dirty_mark(mpInfo->widget) // <-- no semicolon
mpProject->SetModified();

After your change that expands to _gx_system_dirty_mark((GX_WIDGET *)mpInfo->widget) mpProject->SetModified();, which is a hard syntax error in both the error-checking and non-error-checking configurations. Please add the missing ; there in this same PR.

That is the only such site — I swept the tree, and all 2315 gx_system_dirty_mark, 10 gx_progress_bar_info_set, and 36 gx_single_line_text_input_style_add references are otherwise either properly terminated or documentation comments.

Fair warning that our CI will not tell you this. All five workflows are gated on branches: [ master ] or workflow_dispatch, and this PR targets dev, so eclipsefdn/eca is the only check that runs. The breakage would have surfaced at the eventual dev → master merge and been blamed on the wrong change. That gap is ours to fix, not yours.

2. Please expand the description. "This fixed a rule violation for my MISRA checker" undersells the change considerably, and it doesn't name the rule — our convention is to cite it explicitly (this pattern is usually flagged under MISRA C:2004 Rule 19.4). More importantly, the correctness argument stands on its own without any checker; see my note on the first macro below.

One expectation to set for anyone reading this later: it does not make gx_api.h MISRA-clean. The macros still expand to function-call expressions rather than a parenthesised expression or a do { } while(0) construct, and the header's whole API-mapping design conflicts with MISRA C:2012 Dir 4.9. That is a deliberate, long-standing choice — this PR silences one diagnostic rather than resolving the category, which is fine and still worth doing.

Nothing else raises a flag: preprocessor-only, so identical generated code and no size or speed impact; no API/ABI change and so no rtos-docs-asciidoc update needed; the file already carries Copyright (c) 2026 Eclipse ThreadX contributors; and the branch targets dev correctly.

Requesting changes — happy to approve once properties_win.cpp:2705 has its semicolon.

[fdesbiens]

Worth stating in the PR description that this is a correctness fix, not just a checker complaint. Because these are UINT-returning services, the trailing semicolon made the documented API unusable in valid C:

if (gx_single_line_text_input_style_add(input, style) !=GX_SUCCESS) /* syntax error before this PR */if (cond) gx_single_line_text_input_style_add(input, style); else ... /* "else without a previous if" */

The first is exactly what a safety-conscious application does with a status-returning call. Note the _gxe_ counterpart at line 4794 was already correct, so this restores symmetry between the two blocks rather than changing a deliberate convention.

[fdesbiens]

This is the one that breaks the build.guix_studio/properties_win.cpp:2705 calls gx_system_dirty_mark(mpInfo->widget) without a trailing semicolon of its own and relies on the macro to supply it. Once this line changes, that expands into _gx_system_dirty_mark(...) mpProject->SetModified(); and fails to compile.

Please fix the call site in this PR — adding ; at properties_win.cpp:2705 is the whole change. It is the only site in the tree that depends on the embedded semicolon.

[fdesbiens]

Good catch on the asymmetry here: the _gx_ counterpart at line 3209 was already correct, so the defect existed only in the error-checking block — the mirror image of the gx_single_line_text_input_style_add case above, where only the non-error-checking block was affected. Easy pair to half-fix; you got both.

[fdesbiens]

This one was wrong in both blocks, so with line 3364 the macro is now consistent across configurations.

Since nothing in the regression suite would have caught the original defect — test/guix_test/regression_test/tests/validation_guix_system_no_output.c:147 exercises _gx_system_dirty_mark directly and bypasses the macro entirely — could you add a compile-only check that uses each of the four macros in expression context? Something as small as:

if (gx_system_dirty_mark(widget) !=GX_SUCCESS)
{
/* ... */
}

It never has to run; failing to compile is the assertion. That is a one-time, near-zero-cost guard for this whole class of regression across the ~1000 API macros, and it satisfies the project's coverage requirement for the change.

[fdesbiens]

No objection to bundling these with the semicolon fix — they're confined to the same file and leave it clean. For the record, I checked whether any of the eight sat after a line-continuation backslash, where trailing whitespace would be an actual defect rather than cosmetic: none did, including this one at the end of GX_GLYPH_MEMBERS_DECLARE. So these are purely cosmetic and carry no risk.

[parsley]

Thank you for the review of my PR.
Actually in my case I got a MISRA rule 14.3 violation due to the second semicolon I added in my own file where I used the marco.
I added the semicolon in properties_win.cpp and committed it.

Anything I missed?

[parsley]

This fixed a rule violation for my MISRA checker.

[fdesbiens]

Thanks for this, @parsley — you found a real defect, and you found all of it. The four macros you touched are every semicolon-terminated gx_* macro definition in common/inc/, and the eight whitespace fixes clear all remaining trailing whitespace in the file, so this won't come back as diff noise later.

I can't approve it as it stands, though, because of one out-of-diff casualty. Two things to sort out:

1. It breaks the GUIX Studio build.guix_studio/properties_win.cpp:2705 calls gx_system_dirty_mark(mpInfo->widget) with no semicolon of its own, leaning on the one the macro used to supply:

gx_system_dirty_mark(mpInfo->widget) // <-- no semicolon
mpProject->SetModified();

After your change that expands to _gx_system_dirty_mark((GX_WIDGET *)mpInfo->widget) mpProject->SetModified();, which is a hard syntax error in both the error-checking and non-error-checking configurations. Please add the missing ; there in this same PR.

That is the only such site — I swept the tree, and all 2315 gx_system_dirty_mark, 10 gx_progress_bar_info_set, and 36 gx_single_line_text_input_style_add references are otherwise either properly terminated or documentation comments.

Fair warning that our CI will not tell you this. All five workflows are gated on branches: [ master ] or workflow_dispatch, and this PR targets dev, so eclipsefdn/eca is the only check that runs. The breakage would have surfaced at the eventual dev → master merge and been blamed on the wrong change. That gap is ours to fix, not yours.

2. Please expand the description. "This fixed a rule violation for my MISRA checker" undersells the change considerably, and it doesn't name the rule — our convention is to cite it explicitly (this pattern is usually flagged under MISRA C:2004 Rule 19.4). More importantly, the correctness argument stands on its own without any checker; see my note on the first macro below.

One expectation to set for anyone reading this later: it does not make gx_api.h MISRA-clean. The macros still expand to function-call expressions rather than a parenthesised expression or a do { } while(0) construct, and the header's whole API-mapping design conflicts with MISRA C:2012 Dir 4.9. That is a deliberate, long-standing choice — this PR silences one diagnostic rather than resolving the category, which is fine and still worth doing.

Nothing else raises a flag: preprocessor-only, so identical generated code and no size or speed impact; no API/ABI change and so no rtos-docs-asciidoc update needed; the file already carries Copyright (c) 2026 Eclipse ThreadX contributors; and the branch targets dev correctly.

Requesting changes — happy to approve once properties_win.cpp:2705 has its semicolon.

[fdesbiens]

Worth stating in the PR description that this is a correctness fix, not just a checker complaint. Because these are UINT-returning services, the trailing semicolon made the documented API unusable in valid C:

if (gx_single_line_text_input_style_add(input, style) !=GX_SUCCESS) /* syntax error before this PR */if (cond) gx_single_line_text_input_style_add(input, style); else ... /* "else without a previous if" */

The first is exactly what a safety-conscious application does with a status-returning call. Note the _gxe_ counterpart at line 4794 was already correct, so this restores symmetry between the two blocks rather than changing a deliberate convention.

[fdesbiens]

This is the one that breaks the build.guix_studio/properties_win.cpp:2705 calls gx_system_dirty_mark(mpInfo->widget) without a trailing semicolon of its own and relies on the macro to supply it. Once this line changes, that expands into _gx_system_dirty_mark(...) mpProject->SetModified(); and fails to compile.

Please fix the call site in this PR — adding ; at properties_win.cpp:2705 is the whole change. It is the only site in the tree that depends on the embedded semicolon.

[fdesbiens]

Good catch on the asymmetry here: the _gx_ counterpart at line 3209 was already correct, so the defect existed only in the error-checking block — the mirror image of the gx_single_line_text_input_style_add case above, where only the non-error-checking block was affected. Easy pair to half-fix; you got both.

[fdesbiens]

This one was wrong in both blocks, so with line 3364 the macro is now consistent across configurations.

Since nothing in the regression suite would have caught the original defect — test/guix_test/regression_test/tests/validation_guix_system_no_output.c:147 exercises _gx_system_dirty_mark directly and bypasses the macro entirely — could you add a compile-only check that uses each of the four macros in expression context? Something as small as:

if (gx_system_dirty_mark(widget) !=GX_SUCCESS)
{
/* ... */
}

It never has to run; failing to compile is the assertion. That is a one-time, near-zero-cost guard for this whole class of regression across the ~1000 API macros, and it satisfies the project's coverage requirement for the change.

[fdesbiens]

No objection to bundling these with the semicolon fix — they're confined to the same file and leave it clean. For the record, I checked whether any of the eight sat after a line-continuation backslash, where trailing whitespace would be an actual defect rather than cosmetic: none did, including this one at the end of GX_GLYPH_MEMBERS_DECLARE. So these are purely cosmetic and carry no risk.

[parsley]

Thank you for the review of my PR.
Actually in my case I got a MISRA rule 14.3 violation due to the second semicolon I added in my own file where I used the marco.
I added the semicolon in properties_win.cpp and committed it.

Anything I missed?