-
-
Notifications
You must be signed in to change notification settings - Fork 6.1k
[RDY] Coverity fixes (mostly resource leaks) #790
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
Conversation
} | ||
} | ||
|
||
set_expr_line(p); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you figure?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The formatting was a bit off though (because I used add without whitespace changes, because the codebase still isn't trailing-whitespace clean). Fixed in the latest squash commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was mistaken, got cross-eyed.
LGTM |
Your comments have been taken into account, will tag RDY tomorrow, hopefully before the next coverity run ;). |
} | ||
|
||
set_expr_line(p); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here one could save quite some copying, if expr_line
would be used directly instead of get_expr_line
and set_expr_line
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That had not escaped me. The question is if we want to sanction direct manipulation or not? I mean, it's all globals anyway, and the copying seems kind of senseless...
What does the rest think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Within this function it looks fine to mutate expr_line
directly. dis_msg
already does so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, if it's a go, I'll trash some allocations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@justinmk and @oni-link what do you think of the new incarnation: aktau@8ce525e ?
It basically does one realloc
and memcpy
in all cases.
There's one thing that bothered me a little. Vim doesn't seem to apply maxlen
to the total string in the case of must_append
. What I mean is that in the must_append
case, the expr_line
could grow indefinitely even when maxlen
is specified. Since I wasn't sure if this was intentional, I kept this behaviour.
} | ||
set_expr_line(p); | ||
|
||
// modify the global expr_line, extend/shrink it if necessary (realloc). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
expr_line
is not global, thankfully. get_expr_line()
returns a copy to external callers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not an external global, but it is a file local (static) global. I always like to mention it when this happens because I hate reading code that operates on globals, confusing as to where it came from.
Checked coveralls to see if
|
That sucks. Perhaps @ashleyh knows more? I've posted an edited version of A few notes:
What do we think of this version? |
- New command line option prints the binary API metadata object and exits
Uses a perl script to move it (scripts/movedocs.pl)
- The 'stripdecls.py' script replaces declarations in all headers by includes to generated headers. `ag '#\s*if(?!ndef NEOVIM_).*((?!#\s*endif).*\n)*#ifdef INCLUDE_GENERATED'` was used for this. - Add and integrate gendeclarations.lua into the build system to generate the required includes. - Add -Wno-unused-function - Made a bunch of old-style definitions ANSI This adds a requirement: all type and structure definitions must be present before INCLUDE_GENERATED_DECLARATIONS-protected include. Warning: mch_expandpath (path.h.generated.h) was moved manually. So far it is the only exception.
…IBUTES Required for FUNC_ATTR_UNUSED to work in lib/k*
So that they do the last nvim/func_attr.h include
Otherwise FUNC_ATTR_* macros may appear empty
Also constified the arguments. The double casts for the `xstrdup` are ugly but `vim_strsave` doesn't take `const` arguments for now so I couldn't keep that.
Coverity detected a memory leak caused by not free'ing the value returned by get_expr_line_src (basically vim_strsave(expr_line)). Replaced the copying with direct manipulation of expr_line, since that also happens in other parts of the codebase. NOTE: I'm aware that this has different behaviour than vim_strnsave, namely vim_strnsave always allocates `len` bytes, even if the string is shorter. I don't see how that behaviour is helpful here though.
Also cleaned up the function a little bit.
It was a false positive, but it can't hurt to "fix" it. Original warning: CID 13685 (#1 of 1): Buffer not null terminated (BUFFER_SIZE) 6. buffer_size: Calling strncpy with a source string whose length (4 chars) is greater than or equal to the size argument (4) will fail to null-terminate b0p->b0_version.
@oni-link I fixed and immediately squashed the latest things you suggested. I hope it's ok now. Fingers crossed! @justinmk I'm not sure why github is freaking out about this branch, but if you pull from it in your cmdline you'll (probably?) see that only my changes are "new". I just rebased to master. |
Alright guys I've made PR #804 as an alternative because this smells fishy. |
Not really, but I was looking at the coverity log and decided to throw in a few tiny fixes.