2.2.2 Compilation Warnings On Tru64 / Digital Unix

[Boyce, Nick]

Andrew Esh wrote :

> Nick Boyce wrote :
> 
>> [My apologies for bothering this list if this is not appropriate] 
>> I have just tried building Samba 2.2.2 *--with-winbind* on both Digital
Unix 
>> 4.0D (= Tru64) and NetBSD 1.4.1, and got a *lot* of compilation warnings
> 
> No apology necessary. This message is certainly appropriate for this list,
above all other lists. 

Phew :-)  

> I couldn't pay me to take that Digital compiler off your hands. It ignores

> the ampersand in front of "pass[i].lm_pwd"? That's not just being 
> incompatible with the differences between certain flavors of C, it's being

> incompatible with the C *language*. Something is seriously wrong with 
> that compiler. 

Well you've worried me more now than I probably horrified *you* !

I'm not much of a C programmer, so the immediate implications of the
compiler diagnostics were lost on me, but your message persuaded me to think
further.

My understanding is that the '&' is there to indicate address indirection -
("pointers" in C-speak ?).  In which case, as an example, I deduce that the
compiler diagnostic :
    cc: Warning: rpc_server/srv_samr_nt.c, line 683: In this statement, &
before array "pass[i].lm_pwd" is ignored. 
                    memset(&pass[i].lm_pwd, '\0', sizeof(pass[i].lm_pwd)); 
means that instead of zeroising the memory location whose address is in
'pass[i].lmpwd', my C compiler is generating code to zeroise 'pass[i].lmpwd'
itself.  If that's right, then it's horrific ... so horrific that I can't
quite believe Compaq/DEC's "new" C compiler for DU 4.0D (a widely used
Y2K-fixed OS release), with Digital Unix Patch Kits 1 thru 5 installed,
could possibly have such an appalling compiler bug ...

Is it possible that the compiler is saying it can ignore the '&' because
it's obvious from the context that '&' is intended/required ?

Or is it possible that this is a K&R C versus ANSI C thing ?

Or an "array of pointers" versus "pointer to array" ambiguity ?

I had a look at the DU "cc" manpage - it contains this :-

========================================================
  -std[n]
      Directs the compiler to produce warnings for language constructs that
      are not standard in the language. The default is -std0.

      The following values are accepted:

      -std
          Enforces the ANSI C standard, but allows some common programming
          practices disallowed by the standard. The -std flag causes the
          macro __STDC__=0 to be passed to the preprocessor.

      -std0
          Enforces the K&R programming style, with certain ANSI extensions
in
          areas where the K & R behavior is undefined or ambiguous.  In gen-
          eral, -std0 compiles most pre-ANSI C programs and produces
expected
          results. The -std0 flag causes the __STDC__ macro to be undefined.

      -std1
          Strictly enforces the ANSI C standard and all its prohibitions
          (such as those that apply to the handling of void types, the
defin-
          ition of lvalues in expressions, the mixing of integrals and
          pointers, and the modification of rvalues).  This flag does not,
          however, restrict the name space defined by the DIGITAL UNIX
imple-
          mentation to only reserved names as specified by ANSI C.

          The -std1 flag causes the macro __STDC__=1 to be passed to the
          preprocessor.  Note that the -std1 flag also affects linker
defined
          symbols.  See ld(1) for more information.
========================================================

Do you think any of these flags might help ?

> This is really curious, considering your statement about being able 
> to compile Samba 2.0.7 with the same compiler. The combination 
> of all these statements yields an absurdity. You need to double check. 

Well I just reran a build for Samba 2.0.7 on our DU box, and 
(a) there are definitely no warnings
(b) the build log is only 6966 bytes long, compared with the 17313 byte
build log for 2.2.2 - i.e. there is clearly a lot more stuff in 2.2.2 - and
some of that doesn't build nicely on DU 4.0D.

What about some of the other warnings I got :-

  cc: Warning: rpc_server/srv_spoolss_nt.c, line 3658: In this statement, 
the referenced type of the pointer value "&nullstr" is "signed char", which 
is not compatible with "array [256] of signed char". 
          init_unistr_array(&info->previousdrivernames, &nullstr, 
servername); 
  --------^ 

  cc: Warning: lib/util.c, line 559: In this statement, the referenced type 
of the pointer value "read" is "function () returning int", which is not 
compatible with "function (int, pointer to void, unsigned long) returning 
long". 
          return (SMB_OFF_T)transfer_file_internal(infd, outfd, (size_t)n, 
read, write); 
  --------------------------^ 

  cc: Warning: tdb/tdb.c, line 106: In this statement, "(-1)" of type 
"long", is being converted to "pointer to void". 
                  if (tdb->map_ptr == MAP_FAILED) { 
  --------------------^ 

Do you think they're as spurious as the ignoring '&' thing ?


> Maybe you can get gcc working on Digital, and use that instead of cc

I'll have a look at that - last time I tried installing gcc (2.7.1.? on
Ultrix) it was a very laborious, time-consuming and nervewracking procedure,
so I'm reluctant ... but I know I should ...

It's not as if Compaq are sheepish or embarassed about their C compilers -
they're proud - see http://www.tru64unix.compaq.com/dtk/

> Are you sure someone didn't symlink /usr/bin/cc to /usr/games/fortune?

The b*stards - I'll lock their accounts out just as soon as I find out who
...

:-)

Nick Boyce
EDS Southwest Solution Centre, Bristol, UK