Skip to content

Conversation

@ChrisJefferson
Copy link
Contributor

More memory changes found with --enable-memory-checking. In some cases we could look at removing functions which give C pointers to strings, but I didn't check what functions are in use by what packages.

@codecov
Copy link

codecov bot commented Mar 30, 2018

Codecov Report

Merging #2337 into master will increase coverage by <.01%.
The diff coverage is 85.71%.

@@            Coverage Diff             @@
##           master    #2337      +/-   ##
==========================================
+ Coverage   72.74%   72.74%   +<.01%     
==========================================
  Files         480      480              
  Lines      246765   246771       +6     
==========================================
+ Hits       179512   179520       +8     
+ Misses      67253    67251       -2
Impacted Files Coverage Δ
src/vars.h 100% <ø> (ø) ⬆️
src/calls.h 95.74% <ø> (ø) ⬆️
src/gvars.c 81.31% <0%> (ø) ⬆️
src/hpc/aobjects.c 68.37% <0%> (+0.09%) ⬆️
src/calls.c 75.42% <100%> (+0.06%) ⬆️
src/vars.c 86.35% <100%> (+0.05%) ⬆️
src/intrprtr.c 94.05% <100%> (ø) ⬆️
src/hpc/traverse.c 95.75% <0%> (-0.59%) ⬇️
src/hpc/threadapi.c 37.2% <0%> (-0.21%) ⬇️
hpcgap/lib/hpc/queue.g 69.59% <0%> (+3.19%) ⬆️

{
return ELM_LIST(NAMS_FUNC(func),i);
}

Copy link
Member

Choose a reason for hiding this comment

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

I'd prefer to not do this, let's instead change NAMI_FUNC, NAME_LVAR, etc to return a GAP string, to fix a ton of additional identical problems not yet covered by this PR.

I just sat down (during vacation, yes...) and had a quick look, it shouldn't be a problem, and no package calls these, either. Might even be able to do this for NAME_RNAM and NameGVar, too

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