- User Since
- Feb 16 2017, 5:12 PM (153 w, 9 h)
May 30 2017
Now if someone could commit it..
May 9 2017
The location of the external project is https://github.com/trixirt/libc11ext
May 6 2017
I am moving this work to an external project.
It is currently being reviewed internally.
I will let you know when it happens, my guess is in a week or two.
Apr 24 2017
The arguements in n1967 come down to 'It's safer but... '
For applications that want safer and are will to accept the cost, app. K is a good option.
If it is a seperate lib in the base, that is fine with me.
Apr 23 2017
Mar 30 2017
Mar 28 2017
My comment is in D10161
Simplify logic for STDC_WANT_LIB_EXT1 in cdefs.h, remove it's CFLAGS in makefiles.
Mar 24 2017
I do not have commit permissions.
Move STDC_WANT_LIB_EXT1 to its own if block
Mar 22 2017
Mar 21 2017
Mar 20 2017
More surrounding context
Add __EXT1_VISIBLE construct to cdefs.h
Fix some style issues
Mar 15 2017
Thanks for the commit!
remove 'end' label and 'ret' variable
This conflicts with earlier comment to have goto.
This is the pattern I use to have a single return, if you want 2 returns,
I could remove the Œret¹ and Œend:¹ and return(-1) at the bottom of the
Collect the error handling in allowaddr to the 'err' label
Mar 14 2017
I¹ll take care of this tomorrow.
I am pedantically scrubbing all of the memory leaks and this is a leak.
Problems must fixed so they don¹t turn up in future scans.
Move setting of STDC_WANT_LIB_EXT1 to makefiles
Fix some style issues
Mar 13 2017
change 'lav' to 'oav'
Mar 12 2017
No commit bit.
Yes, l as in local, there have been similar problems where the pointer
variable is a passed in parameter.
Let me do the o change first, I¹ll take take of that tomorrow.
Yes, please commit. I do not have commit perms.
Mar 11 2017
This is the before, the line number is a bit screwed up because i commented out my change.
The after has memory leak removed.
Mar 10 2017
I will have to reproduce these, I will send it out asap.
Mar 7 2017
If we don’t give them the function to register the handler there shouldn’t
be any expectation ;)
The handler interface is a part of the full K support and I believe
overkill if we only have a single K function.
I am in favor of full support.
Is that what everyone wants ?
A new idea..
What do people think about making the pointer access safer ?
It should be possible to look into the processes memory space and tell if
the memory accessed by the function is mostly valid.
Mar 6 2017
The handlers certainly would be useful if a full implementation of K was
For a single function I don¹t think it would be very useful.
How much more useful would a handler have over a user just checking the
I am working on the style problems.
The reason for adding this function is to improve security.
Memset is used to overwrite sensitive memory.
But the compiler can legally optimize away a memset.
The compiler can not optimize away memset_s.
Mar 5 2017
Mar 3 2017
Mar 2 2017
Feb 27 2017
Feb 26 2017
Sure, let me give it a try.
Feb 25 2017
Ok, i will get this upstreamed.
Feb 24 2017
Credit goes to clang¹s static analyzer scan-build.
I only read the reports it generated.
Yes I am aware of the bsd-ism.
Generally it isn¹t a good idea to use ism¹s.
In this case the problem is in grep which is gnu, and not bsd.
Feb 23 2017
I agree these should also be freed.
I took a second look at the scan-view output and it did not complain which is troubling.
Yes, that would be helpful.
At this time, I do not have any more static analysis fixes for dtrace.
Feb 21 2017
Feb 20 2017
moved free(copy) to last use of copy and poisoned copy after the free