On 01/16/2015 11:58 AM, Stef Walter wrote:
On 16.01.2015 11:56, Pavel Březina wrote:
> On 01/16/2015 11:55 AM, Jakub Hrozek wrote:
>> On Fri, Jan 16, 2015 at 11:41:19AM +0100, Pavel Březina wrote:
>>> On 01/16/2015 11:39 AM, Jakub Hrozek wrote:
>>>> On Fri, Jan 16, 2015 at 11:29:27AM +0100, Pavel Březina wrote:
>>>>> One more question - uid_t is unsigned int. Should we use it in
>>>>> instead of int64_t which was taken from the original design page?
>>>> uid_t is unsigned 32bit on most (all?) platforms. IIRC int64_t was
>>>> chosen so that we cover the 32bit value range and can use the negative
>>>> range for errors.
>>> I don't think I follow. What errors? Errors are reported through
>>> D-Bus error
>>> message, not through an input parameter.
>> OK, for input parameters and properties it makes sense to use unsigned
>> number. I just checked AccountsService and they use UInt64 -- not sure
>> why, can you check with Stef or Matthias Clasen ? I can't think of other
>> reason than representing undefined or extra values, though.
>> In SSSD itself, we use uint32_t to represent UIDs anyway.
> CCing Stef.
No idea. Maybe for cross platform insurance? Matthias wrote that code.
Although it would be awesome to have longer UIDs in the kernel, the
reality is that we're limited to uint32_t.
Let's go with uint32. All the underlying functions uses uid_t or
uint32_t if the code is shared for uid and gids so there is no point to
allow bigger ids here since it would have to be converted to uint32 anyway.