[PATCH] Merging the privilege code

[Michael Adam]

Andrew,

I'd like to second Volker's question/request here,
hopefully emphasizing it:

What is the benefit of removing the struct and going
back to a flat integer type or as a compromise (as
it seems to me) to an enum type.

I also do very much like having these se_... accessor
functions instead of directly doing bit-operations on
the integer type. It is enhances readability and portability
against changes of the type. If the implementation is bad
(relying on certain global variables or so), this should be
changed IMHO instead of removing the accessor functions
altogether.

I would very much like to keep a struct type and the
accessor functions for the privileges.


Also, why not simply port the 128 bit access mask with room
to grow to source4 instead of backporting the source3 code?

Cheers - Michael


Volker Lendecke wrote:
> On Mon, Aug 30, 2010 at 05:26:55PM +1000, Andrew Bartlett wrote:
> > > Another argument in favor of a struct: Type safety. We even
> > > have NTSTATUS (which really is just a uint32 even) as a
> > > struct, Tridge went through great pains to make it one, and
> > > this revealed quite a few bugs.
> > 
> > I've extended the patch series to address the expandability constraints
> > here - all the callers outside libcli/security/privileges.c and
> > source3/lib/privileges.c now only use an enum sec_privilage to query or
> > set the privileges of a user.  While C does not provide strict type
> > checking on enums, it is stronger protection than a typedef, fits with
> > your requirement for clarity of purpose and allows the values to be
> > resolved inside a debugger. 
> 
> Probably it's just that I'm too stupid to understand why a
> structure is technically not possible anymore. Well, yet
> another thing that we can then work on over the next years.
> 
> Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100830/107572aa/attachment.pgp>