Extension to Samba IDL.

[Elrond]

On Mon, Jun 19, 2000 at 12:35:15PM -0500, Christopher R. Hertel wrote:
> On Jun 20,  2:25am, Elrond wrote:
> > Subject: Re: Extension to Samba IDL.
> >
> > Hehe... When I talked with Matty and Luke about extensions,
> > everyone told me, that those are a bad idea, and everyone
> > told me, it's always better to keep with msidl on that...
> > After a while, I saw, that most stuff could be done with it
> > (and other could be done with some tricky attributes, I
> > learned later about)
> 
> That's why I asked before making this extension.  The other thing I'm working
> on is finding a way to add yodl to comment blocks so that we can generate
> documentation from the same source files.  That shouldn't break anything in
> MIDL unless MS get the same idea but require the use of MS-WORD or somesuch.


Hmm... You can add some documentation to the generated
header with cpp_quote, but that doesn't realy help you...

Hmm... templates realy will help you here... Yeah.
But don't ask me for lots of help here, my
documentation-interests aren't that great ("it's documented
in the source, RTFS")

Hmm... cpp_quote could help you, I just thought up:

In the idl-file, you do:

#ifdef IDL_DOC
cpp_quote("yodl-commands...")
#endif

then call sidlc with "-DIDL_DOC --templates-dir
yodl-templates" and the yodl-templates simply output the
cpp_quote. ;)


(No, sidlc doesn't support any options currently, I just
didn't start to ask, wether I should drop in GNU getopt)


[...]
> > > All I need is the go-ahead on what I proposed.
> >
> > I've no probs with extensions, I wanted some too. And got
> > told, it's a bad idea... after some long discussion, I got
> > a little pissed and just stopped the discussion and went
> > doing other stuff. ;)
> 
> Can you write them up for us again?  I'd be interested to know what you had in
> mind.


I don't know, if you've already seen "offset"-pointers.

*bing* You have. You just mentioned them in your
bit-examples. Just in DCE/RPC, they're relative to the
start of the struct, not relative to whatever they're with
Netbios-names.

They're mostly like normal pointers in DCE/RPC. That is: if
they're 0x0, the item doesn't exist and the C-equivalent is
set to NULL.

They're mostly used in security-descriptors, but also in
svcctl.

What I wanted:
typedef struct _SD {
	...
	[offset] SID *owner;
	[offset] SID *group;
	[offset] ACL *sacl;
	...
} SECURITY_DESCRIPTOR;


Well, Luke wanted that stuff to be a runtime-option
(hehe... side-story, I just have the stuff in my mind, that
will allow the runtime-option to be simple to implement..)
and let the the _application-layer_ (or some
helper-functions, that the application-layer calls, or some
wrappers, whatever) set up a prs_struct, do some
prs_set_self_relative(ps, True) and call sec_io_desc()
itself.

Well, I wanted that all to happen in the normal
marshalling/unmarshaling-process.

That's all about it.


[...]
> > If you realy need a byte, that is not aligned properly, you
> > should do uint8:8 or somesuch.
> 
> Yes, something like that.  I'm thinking:
> 
> - Byte alignment is the current default anyway, since there are no
>   bitfields implemented.  Also, byte alignment is *not* the same as
>   alignment specified by 'option autoalign'.
> 
> - Any non-bit fields (ints, uints, etc.) would be byte aligned by
>   default.  That is, nothing changes for these.  Bit fields (int:x,
>   uint:x) would *not* be byte-aligned by default.  In many cases, the
>   bitfield is going to follow a byte-aligned value anyway, meaning that
>   it will start on a byte boundary.  The only time that non-aligned
>   bitfields will make a difference is a bitfield following a bitfield
>   (as in NetBIOS Name example).
> 
>   So, if you have:
> 
>   [x|x][-|-|-|-|-|-][y|y|y|y|y|y][+|+][uint8]
> 
>   where xx is a two-bit field, dashes are cruft, and yyyyyy is a 6-bit
>   field ++ are more cruft, and [uint8] is an actuall byte...
> 
>   ...then you'd either have to declare padding for the dashed space
>   or we need an 'option bitfield align' (or some directive in the IDL
>   code).  The ++ space doesn't need padding since the uint8 will be
>   aligned.
> 
>   My preference is to leave out any directives or options and use
>   padding bits in the very rare cases it's necessary.  It certainly
>   seems the simplest solution and doesn't clutter the language.

Yeah, sounds all reasonable !

>   BTW, when specifying a bitfield using the [u]int:x syntax, the parsed
>   data can be read into byte, short, or long depending on the value of
>   x.   If x <= 8 then use a byte, x <=16 use a short, etc.

Hmm... Yeah... Which makes up a _detail_-question: If/when
sidlc generates the header, how should the generated header
for bitfields look like?
a) C-style bitfields.
b) Just the next size of a normal storage type

I don't know, what I would vote for... possibly a.

> > > 2) It's not good enough to simply mask a byte or word.  In the example I
> > >    gave, you either have:
> > >
> > >    [x|x|y|y|y|y|y|y] or
> > >    [x|x|z|z|z|z|z|z|z|z|z|z|z|z|z|z] depending on the value of xx.
> > >
> > >    So, if you parse it as a uint8 it might turn out that you needed a
> > >    uint16, and vice versa.
> >
> > Hmm... that's a run-time issue... not easy, but it should
> > be doable.
> 
> Easier to do in the IDL code (if it's supported).

You mean in the generated parser?

This isn't too easy at a first glance.
Remember byte-ordering... (I think, I don't want to know
about byte-ordering and bitfields...)

Okay, let's assume, you want to read 14 bits:

I see the following options:
a) handle the byte-order directly in the parsing-code.
   This will tend to look extremely ugly.
b) do something like:
	uint16 dummy;
	prs_uint16("dummy", ps, ...);
	bitfield = dummy & 0x7ffe) >> 1;
   urgs... what if the 14 bits are aligned somehow
   different... you would need to read off a uint32... But
   possibly there isn't enough data for a uint32, so we
   would need a uint24. ;)
   More thought needed here.
c) Simply
	prs_uint_bitfield("flags", &bitfield, ps, 14, ...);
   this can handle all the alignment, byte-order, and
   everything else.
   Hmm... Is it allowed to do &bitfield in C?
   (if we want option a from above)

Oh, and remember: if you have two bitfields following in
the packet, they could be in different structs/unions, so
prs_struct needs to carry over the current "bit-offset"
anyway...




Okay... So much for today...


    Elrond