Skip to content

Improvement: Use a fixed constant for the length of the description field in t8_vtk_data_field_t - #2499

Open
benegee wants to merge 4 commits into
mainfrom
bg/fixed-vtk-description-string-length
Open

benegee wants to merge 4 commits into
mainfrom
bg/fixed-vtk-description-string-length

Conversation

@benegee

@benegee benegee commented Oct 7, 2026 •

Copy link
Copy Markdown
Contributor

Describe your changes here:

Resolves #2454

All these boxes must be checked by the AUTHOR before requesting review:

  • The PR is small enough to be reviewed easily. If not, consider splitting up the changes in multiple PRs.
  • The title starts with one of the following prefixes: Documentation:, Bugfix:, Feature:, Improvement: or Other:.
  • If the PR is related to an issue, make sure to link it.
  • The author made sure that, as a reviewer, he/she would check all boxes below.

All these boxes must be checked by the REVIEWERS before merging the pull request:

As a reviewer please read through all the code lines and make sure that the code is fully understood, bug free, well-documented and well-structured.

General

  • The reviewer executed the new code features at least once and checked the results manually.
  • The code follows the t8code coding guidelines.
  • New source/header files are properly added to the CMake files.
  • The code is well documented. In particular, all function declarations, structs/classes and their members have a proper doxygen documentation. Make sure to add a file documentation for each file!
  • README.md files are updated if necessary.
  • All new algorithms and data structures are sufficiently optimal in terms of memory and runtime (If this should be merged, but there is still potential for optimization, create a new issue).

Tests

  • The code is covered in an existing or new test case using Google Test.
  • The code coverage of the project (reported in the CI) should not decrease. If coverage is decreased, make sure that this is reasonable and acceptable.
  • Valgrind doesn't find any bugs in the new code. This script can be used to check for errors; see also this wiki article.

If the Pull request introduces code that is not covered by the github action (for example coupling with a new library):

  • Should this use case be added to the github action?
  • If not, does the specific use case compile and all tests pass (check manually).

Scripts and Wiki

  • If a new directory with source files is added, it must be covered by the scripts/internal/find_all_source_files.sh to check the indentation of these files.
  • If this PR introduces a new feature, it must be covered in an example or tutorial and a Wiki article.

License

  • The author added a BSD statement to doc/ (or already has one).

@codecov

codecov Bot commented Oct 7, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.79%. Comparing base (7563ba2) to head (baf2f13).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2499   +/-   ##
=======================================
  Coverage   82.79%   82.79%           
=======================================
  Files         139      139           
  Lines       21581    21581           
=======================================
  Hits        17869    17869           
  Misses       3712     3712           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@holke holke left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thanks :)

Just a minor remark to add an explanation for the 1023.

Comment thread src/t8_vtk/t8_vtk.h

#define T8_VTK_FORMAT_STRING "ascii" /**< Format string for vtk */
#define T8_VTK_FORMAT_STRING "ascii" /**< Format string for vtk */
#define T8_VTK_MAX_STRING_LENGTH 1023 /**< Maximal string length for the description in t8_vtk_data_field_t */

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please add a comment in the code why we choose 1023 - since its a magic number, we should have an explanation for it.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Embarrassing...

It had been 1024. 1K, just because I like the number, and I thought 8K (as seen on Linux) is a bit too much.

I then did a quick check to make sure I could actually retrieve the number from an external application, changed the number, and forgot to revert the change.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While we are at it, naming is hard. Do you have other suggestions for the macro name?

@holke

holke commented Oct 8, 2026

Copy link
Copy Markdown
Collaborator

Also, please adhere to the PR naming conventions:

" The title starts with one of the following prefixes: Documentation:, Bugfix:, Feature:, Improvement: or Other:."

@benegee benegee changed the title Use a fixed constant for the length of the description field in t8_vtk_data_field_t Improvement: Use a fixed constant for the length of the description field in t8_vtk_data_field_t Oct 8, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Safe usage of t8_forest_write_vtk_ext with data for external applications

2 participants