Compiling SAMBA with better options

[John E. Malmberg]

From: "B. Z. Lederman" wrote:

>     I've been looking more at the source code and the way it's
>  compiled. 
> 
> /STANDARD=VAXC is really not a good choice.  It covers up too
>  many real and potential problems in the code.

Use /STANDARD=PORTABLE.  Do not use /STANDARD=VAXC

Use /WARN=ENABLE=(LEVEL4, QUESTCODE) for the diagnostic level.

You can use more strict /STANDARD or /warn and other checking if you 
wish, but the two settings above are the minimum needed to both find 
common bugs, and to be compatable with common programming practices.

If the /warn=enable=(LEVEL4, QUESTCODE) and /STANDARD=PORTABLE does not 
compile a UNIX samba module, try it again by adding /ACCEPT=NOVAXC

If that does not fix it, then update the source and send a explanation 
of the bug fix allong with a submit a gdiff -u output of the change to 
the SAMBA-TECHNICAL list so it can be fixed in the source for all platforms.

If you have not submitted patches to the SAMBA-TECHNICAL list before, I 
recommend posting just the lines that you think needing fixing both old 
and new to this list for review.  Please be brief.

>     There is also a question of what to do with names that are
>  longer than 31 characters.

I put #define statements in the config.h or equivalent.

Having the names truncated will cause duplicate symbol errors in SAMBA.

The only thing that I can find in the standard is that only 8 characters 
  for external names are guaranteed to be available on all platforms, 
and obviously most code needs more than that.

The other option is to allow the compiler to mangle names.  I prefer not 
to do that as then I can not always predict what name will show up in 
the debugger.  Particularly if the demangle database is cleared.

> [SAMBA-2_2_7A-SRC.SOURCE.SMBD] CLOSE.C
> 
>     because it calls sys$open, sys$close, etc. without the
>  functions being defined.  Modules that call these functions are
>  better off if they #include <starlet.h> to define the function
>  prototypes. There are a couple of other modules where this should
>  be done. 

I personally find that the #include files for the system service modules 
to not be accurate because they do not use the "const" modifier where 
they should and they tend to use "void *", which will accept anything 
with out a complaint.

So I usually prototype the system services manually, like I did in 
Frontport.  That way the compiler is more likely to find bugs.

The use of the "const" modifier on variables passed by address also 
allows the compiler to optimize more effienciently, which means faster 
and smaller code.  It's use should be greatly encouraged.

An unknown person wrote: (post is not in the digest)

> | I quite agree with your remarks, but I fear that you seem to forget a very
> | important point : Samba/VMS is a port from a quite complicated software that
> | comes from Unix, and is quite often updated. If you multiply the "#ifdef"
> | for VMS specifics, you begin to have a lot of work each time a new release
> | comes in, if you want to follow the Unix updates. So I tend to limit the VMS
> | specific changes to truly functional ones, not for the intellectual benefit
> | of removing warning or informational messages.

That is why I did the SAMBA 2.0.6 port the way I did.  Amost no #ifdef 
__VMS is in the code.  Carl Perkins has supplied me with a fix to 
Frontport that probably eliminates all but one of the #ifdef __VMS.

Use of the compiler options that I listed earlier should allows SAMBA to 
compile unless there is a real bug in the source code.

I add a /DEFINE=(MOD_modulename) to the MMS C compiler rule so that I 
can put things that are specific to a module in the config.h or 
equivalent.  That way I can override a local routine with out having to 
edit any source code.

The MMS definition is below, and it is easy to do this with DCL command 
procedures.

MODN =MOD_'f$element(0,"-",f$parse("$*",,,"NAME"))'

So in the config.h or equivalent, (Since I am now generating the 
config.h from a command procedure that knows how to read the config.h.in 
and configure.in files, and search the DECC images and libraries, I now 
put all the manual edits in config_vms.h)

#ifdef MOD_LOADPARM
    /* Change the name for a VMS specific wrapper */
   /*--------------------------------------------*/
#define lp_load samba_lp_load
#endif

This allows me to scan the VMS specific SAMBA logical names every time 
that SAMBA scans the smb.conf file for changes.

And if a module informational diagnostics that I do not want to
submit a fix for, I can supress those on a per module basis.

#ifdef MOD_IPC
  /* suppress messages about using -1 as third arg to SSVALS() macro */
#pragma message disable intconstsign
#endif

This is a case where they are using a -1 instead of 0xFFFFFFF.  The 
problem with fixing this is that the size of an unsigned int is platform 
specific, so it really should be ~0 instead.  However if I remember 
correclty that also generates a diagnostic.

So I just supress the diagnostic for now.

An unknown person wrote: (post is not in the digest)

> | them on the Internet. I was not too much enthusiast, but I eventually
> | agreed, and since then I try to do my best to help other users who encounter
> | problems. May I say that since the beginning of this Samba/VMS version (more
> | or less 1 year ago), not a single problem was due to the /STAND=VAXC option

The /STANDARD=VAXC option is not required for the UNIX SAMBA code, and 
should not be required for any code that is currently being actively 
maintained.  Consider /STANDARD=VAXC as equivalent to "Ignore common 
bugs and hope that the compiler does the right thing"

VAX C was written before the C language was fully standardized, and it 
allows a lot of what is now considered very bad practices to be compiled.

There are many things in the C standard where the behavior is either 
compiler specific, or undefined.  A C compiler is not required to 
diagnose those conditions.  The /WARN=ENABLE=(LEVEL4, QUESTCODE) will 
detect those issues.

The QUESTCODE setting will even detect common programming errors like 
using "==" where you meant "=", and tries to detect the reverse.

-John
wb8tyw at qsl.network
Personal Opinion Only