Skip to content
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

cleanup: Convert all variable length arrays to heap allocations #100

Merged
merged 3 commits into from
Nov 1, 2020

Conversation

JFreegman
Copy link
Member

@JFreegman JFreegman commented Oct 28, 2020

VLA's are inherently unsafe so the safest option is to not use them. The trade off here is a lot of extra code for mallocs/frees and more possible memory leaks. But I think that's a small price to pay for greatly reducing the possibility of stack corruption.

I also added the -Wvla compile option to the Makefile, which gives a warning when VLA's are used.


This change is Reviewable

@JFreegman JFreegman added the cleanup Internal code cleanup, possibly affecting semantics, e.g. deleting a deprecated feature. label Oct 28, 2020
@JFreegman JFreegman added this to the 0.8.x milestone Oct 28, 2020
@JFreegman JFreegman changed the title Convert all variable length arrays to heap allocations cleanup: Convert all variable length arrays to heap allocations Oct 28, 2020
@JFreegman JFreegman force-pushed the say_no_to_VLAs branch 3 times, most recently from 961a962 to 9dafa15 Compare October 28, 2020 04:54
@JFreegman JFreegman force-pushed the say_no_to_VLAs branch 6 times, most recently from 198b851 to bd4fc6a Compare October 28, 2020 18:13
src/toxic.c Outdated
@@ -837,6 +888,7 @@ static Tox *load_tox(char *data_path, struct Tox_Options *tox_opts, Tox_Err_New

if (store_data(m, data_path) == -1) {
exit_toxic_err("failed in load_tox", FATALERR_FILEOP);
return NULL;
Copy link
Member

Choose a reason for hiding this comment

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

You added a lot of return NULL; after exit_toxic_err calls. Don't they exit?

Copy link
Member Author

Choose a reason for hiding this comment

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

I added those to see if they would get rid of a strange codefactor warning, which they did. So I can either leave them (harmless) or @iphydf can fix the false positive.

Copy link
Member

Choose a reason for hiding this comment

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

Going to leave them in even though CodeFactor no longer is a required check?

src/qr_code.c Show resolved Hide resolved
src/misc_tools.h Outdated Show resolved Hide resolved
@JFreegman JFreegman force-pushed the say_no_to_VLAs branch 4 times, most recently from 88bff06 to e7ae063 Compare October 29, 2020 04:27
@JFreegman
Copy link
Member Author

JFreegman commented Oct 29, 2020

Two of the CodeFactor warnings are false positives (popen() and system()) and one about complexity is completely useless (doesn't give me a line or function) and can't be resolved.

All of the Codacity warnings about strlen() are false positives. I don't quite understand the warning:

Does not handle strings that are not \0-terminated; if given one it may perform an over-read (it could cause a crash if unprotected) (CWE-126).

A C string is null terminated by definition. The warning amounts to "if this is buggy code it might crash".

src/toxic.c Show resolved Hide resolved
src/toxic.c Show resolved Hide resolved
@JFreegman JFreegman force-pushed the say_no_to_VLAs branch 3 times, most recently from 060f52c to 69f088a Compare October 30, 2020 17:25
@JFreegman
Copy link
Member Author

Three of the four codefactor issues have been fixed. To summarize:

  • system("clear") was replaced with a printf escape sequence with the same functionality
  • Some logic in dir_match() was split into a helper function
  • The misc_tools.c warning was due to the entire source file's complexity being summed, so I just moved a few of the functions that were only used in one place over to their respective source file. Also did a bit of refactoring.

Still don't know what to do about popen()

@JFreegman JFreegman force-pushed the say_no_to_VLAs branch 3 times, most recently from 1d28c6f to 2a4b4e3 Compare November 1, 2020 14:54
@JFreegman JFreegman requested a review from a team as a code owner November 1, 2020 15:04
@JFreegman JFreegman force-pushed the say_no_to_VLAs branch 2 times, most recently from 53c0eaa to d6f0ca2 Compare November 1, 2020 16:11
VLA's are inherently unsafe so the safest option is to not use them
Instead of using various different forms of string arrays and having to handle them
differently for string completion, we now always use char pointer arrays. This allows
us to remove some large stack allocations, remove a bunch of confusing defines that
keep track of global array sizes, and generally unclutters the code so it's easier
to read.
@JFreegman JFreegman requested a review from robinlinden November 1, 2020 16:32
@JFreegman JFreegman requested review from a team and removed request for a team November 1, 2020 16:33
src/toxic.c Outdated
@@ -837,6 +888,7 @@ static Tox *load_tox(char *data_path, struct Tox_Options *tox_opts, Tox_Err_New

if (store_data(m, data_path) == -1) {
exit_toxic_err("failed in load_tox", FATALERR_FILEOP);
return NULL;
Copy link
Member

Choose a reason for hiding this comment

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

Going to leave them in even though CodeFactor no longer is a required check?

Also moved some single use functions from misc_tools to their
respective files
@JFreegman JFreegman merged commit e7a0c32 into TokTok:master Nov 1, 2020
@JFreegman JFreegman deleted the say_no_to_VLAs branch November 1, 2020 21:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cleanup Internal code cleanup, possibly affecting semantics, e.g. deleting a deprecated feature.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants