Re: [Xen-devel] [Qemu-devel] [PATCH 7/8] os-posix: Provide new -runasid option

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Markus Armbruster writes ("Re: [Qemu-devel] [PATCH 7/8] os-posix: Provide new 
-runasid option"):
> Ian Jackson <ian.jackson@xxxxxxxxxxxxx> writes:
> > qemu_strtoul fails (returns an error) if the delimiter (that is, the
> > first character which is not processed as digit by strtoul) is not
> > '\0'.
> 
> It does that *only* when its @endptr argument is null.  Since you pass
> &ep, it should work fine here.

I have just read it again and you are right.  Sorry.  I will fix this
then.

> > Does that all make sense ?
> 
> Your code makes sense to me.  It's just the comment that confuses me.
> Does ID mean "implementation-defined behavior"?  That would be wrong:

Yes, that's what I meant by ID.

>        6.3.1.3  Signed and unsigned integers
> 
>        [#1] When a value with integer type is converted to  another
>        integer   type  other  than  _Bool,  if  the  value  can  be
>        represented by the new type, it is unchanged.
> 
>        [#2] Otherwise, if the new type is unsigned,  the  value  is
>        converted  by repeatedly adding or subtracting one more than
>        the maximum value that can be represented in  the  new  type
>        until the value is in the range of the new type.

That applies if the new type (uid_t, here) is unsigned.  But I think
uid_t's signedness is not specified, so it might be signed.  (SuS
says, in the section on types.h, only

  Additionally:
     * nlink_t, uid_t, gid_t, and id_t shall be integer types.

C99 6.3.1.3 continues:

         Otherwise, the new type is signed and the value cannot be
         represented in it; either the result is
         implementation-defined or an implementation-defined signal is
         raised.

So the type of uid_t is ID too.

> One more thing: please report errors with error_report().  Here:

>             error_report("Could not obtain uid");
> 
> No need to quote optarg back at the user, because error_report() already
> does.

Ah, I will do that.  Thanks.

Regards,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel