2.2.2 Compilation Warnings On Tru64 / Digital Unix

[Esh, Andrew]

According to the C language operator precedence rules, the application of
the '&' operator should come after the application of all the other
operators used in "&pass[i].lm_pwd". The array reference comes first, then
the member or union reference "dot". Then the address of that location is
what is passed to memset. The memset is supposed to zero the lm_pwd part of
the structure which is the i-th element in the "pass" array. If the "&"
(which reads as 'address of') is ignored, then memset will get the -value-
of lm_pwd, which is then interpreted as an address, and *that* is zeroed.
Since the value of lm_pwd is not a pointer (lm_pwd is an array of uint8),
the memset will probably corrupt memory, or cause a segfault.

I think the main thing to focus on is the fact that you were able to compile
the same code with the gnu compiler, and you did not have the same problems.
I am unfamiliar with the DU compiler, so I shouldn't try to guess why it's
acting this way. Perhaps the warning level is set so high that it's trying
to do extremely strict type checking. The warnings seem to focus on the
difference between an array, and a pointer. In most C circles, the two are
interchangeable, so long as the pointer is defined as one that points at the
same type of thing as an element in the array. This comes from a string
pointer (char *) reference being the same as the address of the first
element in an array of chars (&str[0]). Maybe the DU compiler is trying to
warn you that an open ended pointer is not the same as a closed end array,
unless more strict definitions are used.

Try this: Declare a pointer "p" of type "uint8 *", and assign it the value
of "&pass[i].lm_pwd" at that point in the code. Then pass "p" to memset.

	uint8 *p = &pass[i].lm_pwd;
	memset(p, '\0', 16 * sizeof(uint8));

Of course this code is wrong from a maintainability standpoint, since we are
hard coding the size of the uint8 array, but it's just a test.

See if the compiler complains about that. If not, then the problem is
probably type check warnings set too high.

This is not a problem of Kernighan & Ritchie vs ANSI C. They both use the
'&' operator. We'd be lost without it.

-----Original Message-----
From: Boyce, Nick [mailto:nick.boyce at eds.com]
Sent: Monday, October 29, 2001 10:31 AM
To: 'samba-technical at lists.samba.org'
Cc: 'Esh, Andrew'
Subject: RE: 2.2.2 Compilation Warnings On Tru64 / Digital Unix


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 
-------------- next part --------------
HTML attachment scrubbed and removed