@zettabot go
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/47#issuecomment-165751107___
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
LGTM
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/47#issuecomment-165781640___
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
I'm SO sorry for introducing that. Dumb question --> is there an easy-to-use
kernel isprint() yet? :)
Ship it! (Or, if you've enough reviewers, I'll try and make sure to approve
this RTI in illumos-gate.)
---
Reply to this email directly or view it on GitHub:
@ahrens @grwilson @danmcd It's worth noting that there's a corresponding
userland check that would need to be modified as well in order to support
unicode:
https://github.com/illumos/illumos-gate/blob/9a686fbc186e8e2a64e9a5094d44c7d6fa0ea167/usr/src/lib/libzfs/common/libzfs_pool.c#L582-L593
---
There is no checking that I know of, any nul-terminated byte array works
On Friday, December 18, 2015, Dan McDonald wrote:
> If the user properties can withstand fuzzing (imagine a delegated dataset
> non-root user being able to fuzz), then steal it. Is there such
If the user properties can withstand fuzzing (imagine a delegated dataset
non-root user being able to fuzz), then steal it. Is there such checking in the
user properties?
---
Reply to this email directly or view it on GitHub:
Can one of the admins verify this patch?
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/47#issuecomment-165704885___
developer mailing list
developer@open-zfs.org
The 'check' pointer is incremented in both the for-loop's update statement,
as well as, in the body of the loop. This means only every second character
is actually checked for low-ascii, and potentially, bytes beyond the
string's null-terminator can be attempted to be accessed.
You can view,