Skip to content

Fix warnings in output.c #51

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 14, 2023
Merged

Fix warnings in output.c #51

merged 1 commit into from
Aug 14, 2023

Conversation

vitcpp
Copy link
Contributor

@vitcpp vitcpp commented Aug 13, 2023

The variable sphere_output_precision type is changed to int because sprintf requires this argument to be of type int when used as the precision specificator (argument for '*' symbol in the sprintf template).

Copy link
Contributor

@esabol esabol left a comment

Choose a reason for hiding this comment

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

This looks fine. The 100 in buf[100] should be more meticulously determined, but, if you’re happy with this, then let’s just merge and move on to incorporating PG16 support.

/*
* Define the precision of output floating point values.
*/
static int sphere_output_precision = DBL_DIG;
Copy link
Contributor

Choose a reason for hiding this comment

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

I still don’t understand how changing this from short int to int fixes the compiler error:

src/output.c:424:18: error: ‘%.*g’ directive writing between 1 and 310 bytes into a region of size between 76 and 92 [-Werror=format-overflow=]
  424 |       "%2ud %2um %.*gs",
      |                  ^~~~
src/output.c:424:7: note: assuming directive output of 309 bytes
  424 |       "%2ud %2um %.*gs",
      |       ^~~~~~~~~~~~~~~~~

but I do 100% agree that the argument to sprintf should be int. I’m going to just chalk this up to this gcc version not being quite right.

Copy link
Contributor Author

@vitcpp vitcpp Aug 14, 2023

Choose a reason for hiding this comment

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

@esabol sprintf takes variadic arguments that is implemented using va_list in C language. sprintf decides how to format the memory chunk with arguments based on the template. I guess, it is like to read raw bytes from a stream and try to interpret them. There is an undefined behaviour if sprintf expects int type (4 bytes), but short int (2 bytes) is passed instead. It seems 2 extra bytes belong to the next argument, depending on the implementation of va_list. It is a real bug that can lead to some unexpected program behaviour and it should be fixed.

The problem with some magic numbers in temporary buffers is not so important. The case with buffer overflow is unlikely in this case. If we want to redesign this behaviour it should be rewritten completely. Some checks for buffer overflows should be implemented.

P.S.
Man sprintf tells:

A field width, or precision, or both, may be indicated by an asterisk ( '*' ). In this case an argument of type int supplies the field width or precision. Applications shall ensure that arguments specifying field width, or precision, or both appear in that order before the argument, if any, to be converted.

@vitcpp
Copy link
Contributor Author

vitcpp commented Aug 14, 2023

@esabol It is interesting, that I tried this:

sprintf(&buf[0], "%.*gd, (int)sphere_output_precision, ...

And I found that it doesn't fix the warning on my side. I use gcc 11.3.0. The warning is enabled by -Wformat-overflow. Some heuristic in gcc is used in this case. It seems it somehow defines that sphere_output_precision may be much greater than DBL_DIG. I can't explain why such change doesn't fix the warning but change the type to int fixes it.

@vitcpp
Copy link
Contributor Author

vitcpp commented Aug 14, 2023

The warnings are fixed for Focal dist. The rest will be fixed in PR #39. Lets incorporate this patch first, #39 will be the next.

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.

2 participants