- it makes code much less likely to be recursion-safe
- it leads to subtle side effects when the same code is called from
multiple places
+ - doesn't play well with shared libraries or plugins
Static data is particularly evil in library code (such as our internal
smb and rpc libraries). If you can get rid of all static data in
In Samba3 many of the core wire structures in the SMB protocol were
never explicitly defined in Samba. Instead, our parse and generation
functions just worked directly with wire buffers. The biggest problem
-with this is that is tied our parse code with out "business logic"
+with this is that is tied our parse code with our "business logic"
much too closely, which meant the code got extremely confusing to
read.
are extremely important differences in the approach that are worth
pointing out.
-In the Samba3 msrpc code we used explicit parse strucrures for all
+In the Samba3 msrpc code we used explicit parse structures for all
msrpc functions. The problem is that we didn't just put all of the
real variables in these structures, we also put in all the artifacts
as well. A good example is the security descriptor strucrure that
*NOT* be in the interface structure.
In Samba3 there were unwritten rules about which variables in a
-strucrure a high level caller has to fill in and which ones are filled
+structure a high level caller has to fill in and which ones are filled
in by the marshalling code. In Samba4 those rules are gone, because
the redundent artifact variables are gone. The high level caller just
sets up the real variables and the marshalling code worries about
each SMB.
As an example go and have a look at reply_getatr_send() and
-reply_getatr() in smbd/reply.c. Read them? Good.
+reply_getatr() in smb_server/reply.c. Read them? Good.
Notice that reply_getatr() sets up the req->async structure to contain
the send function. Thats how the backend gets to do an async reply, it