Thanks!
Now if someone could commit it..
Tom

The location of the external project is https://github.com/trixirt/libc11ext

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.

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.

My comment is in D10161

Cleanups
Simplify logic for STDC_WANT_LIB_EXT1 in cdefs.h, remove it's CFLAGS in makefiles.

I do not have commit permissions.

Move STDC_WANT_LIB_EXT1 to its own if block
Cleanups

More surrounding context

Add __EXT1_VISIBLE construct to cdefs.h
Fix some style issues

No worries.
Thanks for the commit!
Tom

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
err: block.

Collect the error handling in allowaddr to the 'err' label

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.

Add set_contraint_handler_s
Move setting of STDC_WANT_LIB_EXT1 to makefiles
Fix some style issues

change 'lav' to 'oav'

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.
Tom

Yes, please commit. I do not have commit perms.
Thank you,
Tom

This is the before, the line number is a bit screwed up because i commented out my change.
The after has memory leak removed.

I will have to reproduce these, I will send it out asap.

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.

Tom

The handlers certainly would be useful if a full implementation of K was
done.
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
return ?

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.

I have submitted bug reports to openssh here
https://bugzilla.mindrot.org/show_bug.cgi?id=2683
https://bugzilla.mindrot.org/show_bug.cgi?id=2684

Sure, let me give it a try.

Ok, i will get this upstreamed.

Credit goes to clang¹s static analyzer scan-build.
I only read the reports it generated.
Tom

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.
Tom

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.
Thanks
Tom

moved free(copy) to last use of copy and poisoned copy after the free