svn commit: r367701 - head/lib/libutil

[Jessica Clarke]

On 15 Nov 2020, at 19:10, Brandon Bergren <bdragon at FreeBSD.org> wrote:
> 
> On powerpc64 and powerpc64le, there is some really weird behavior happening around the sysctl itself:
> 
> root at crow:~ # pkg
> The package management tool is not yet installed on your system.
> Do you want to fetch and install it now? [y/N]: N
> root at crow:~ # sysctl user.localbase
> user.localbase: /usr/local
> root at crow:~ # pkg
> The package management tool is not yet installed on your system.
> Do you want to fetch and install it now? [y/N]: N
> root at crow:~ # sysctl user.localbase=/usr/local
> user.localbase: /usr/local -> /usr/local
> root at crow:~ # pkg
> pkg: not enough arguments
> Usage: pkg [-v] [-d] [-l] [-N] [-j <jail name or id>|-c <chroot path>|-r <rootdir>] [-C <configuration file>] [-R <repo config dir>] [-o var=value] [-4|-6] <command> [<args>]
> 
> For more information on available commands and options see 'pkg help'.
> root at crow:~ # 
> 
> 
> I would double check very closely that the sysctl is being called correctly, the sysctl tool manages to read it out, but libutil does not.

That's odd. What does truss say?

Jess

> On Sun, Nov 15, 2020, at 1:06 PM, Scott Long wrote:
>> 
>>> On Nov 15, 2020, at 12:01 PM, Jessica Clarke <jrtc27 at freebsd.org> wrote:
>>>> 
>>>> I felt similar concerns, but my misunderstanding of strlcpy() drove the
>>>> result.  Since the use case for getlocalbase() lends itself to also use
>>>> strlcat()/strlcpy(), I was trying to replicate the API semantics of those,
>>>> at least to the limit of my understanding.  Thanks for the feedback, I’ll
>>>> look at it some more.
>>> 
>>> Thanks. ENOMEM also feels inappropriate as no allocation is taking
>>> place. Perhaps ENAMETOOLONG, which is used in similar cases for things
>>> like gethostbyname? Though sysctlbyname uses ENOMEM instead... sigh.
>>> 
>> 
>> Yep, I wasn’t happy with ENOMEM either but I couldn’t find anything better.
>> 
>>> Also, if pathlen has already been checked against SSIZE_MAX (giving
>>> EINVAL) and tmplen against pathlen there's no need to then check tmplen
>>> against SSIZE_MAX.
>>> 
>> 
>> Done.
>> 
>>> I'd be happy to give a review on Phabricator if/when you have a new
>>> patch.
>>> 
>> 
>> https://reviews.freebsd.org/D27227
>> 
>> Thanks,
>> Scott
>> 
>> 
> 
> -- 
>  Brandon Bergren
>  bdragon at FreeBSD.org