torture: Use manually written .pc file.

[ira/wip.git] / prog_guide.txt

diff --git a/prog_guide.txt b/prog_guide.txt
index d4a170b278e07c53d57c2c270db565470eaa64c0..3814a11a4ef531d58acd1bdf25b8399a5fca82b1 100644 (file)
--- a/prog_guide.txt
+++ b/prog_guide.txt
@@ -146,6 +146,7 @@ Static data is evil as it has the following consequences:
  - 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
@@ -207,7 +208,7 @@ an idea of what I am talking about.
 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.
 
@@ -395,7 +396,7 @@ function, so smbd has a _send() function and the parse function for
 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