[sane-devel] Tru64 build results

[Henning Meier-Geinitz]

Hi,

On Tue, Apr 23, 2002 at 11:25:44PM +0100, Major A wrote:
> SANE seems to compile OK on Tru64 5.0, I've just done a quick build
> and attached the output. There are plenty of warnings, though, it
> might be useful to backend authors as an indication of some weirdness
> in their code which gcc doesn't recognize. This build was done with
> DEC's CC, which is sometimes more verbose.

Thanks, very interesting. Please test again when sane-1.0.8 is released
so we can update the supported platforms page.

cc: Info: getopt.c, line 347: In this statement, the identifier "getpid" is implicitly declared as a function. (implicitfunc)
      sprintf (var, "_%d_GNU_nonoption_argv_flags_", getpid ());
-----------------------------------------------------^

(Lots of more warnings for getopt.c). Ugly but there are too many
ifdefs in this code so I won't even try to avoid these warnings (and
maybe break it completely on a different platform).

cc: Info: sanei_init_debug.c, line 103: In this statement, the identifier "isfdtype" is implicitly declared as a function. (implicitfunc)
      if ( 1 == isfdtype(fileno(stderr), S_IFSOCK) )
----------------^

Description: A expression contained a reference to a function that has not been declared. 
User Action: Declare the function before it is referenced. 
cc: Info: sanei_init_debug.c, line 109: In this statement, the identifier "vsyslog" is implicitly declared as a function. (implicitfunc)
	      vsyslog (LOG_DEBUG, fmt, ap);
--------------^

[...]

If we wanted to fix those, we would need to declare all the functions
used in lib when they are compiled in. I'm not sure if we can do this
easily.

cc: Info: abaton.c, line 232: Code at or just after this location can never be executed. (unreachcode)
  return SANE_STATUS_INVAL;
--^
Description: The compiler has detected code that can never be executed. Often unreachable code represents a real coding error such as a label that is incorrectly spelled, or a statement that was inserted on the wrong line.  But sometimes it occurs in good code as a result of logical expressions that depend only on the values of constants (typically through macro expansion). 
User Action: Usually any code correction is obvious.  And often it is straightforward to rewrite compile-time logical expressions in terms of preprocessing constructs to avoid this diagnostic.  But in some programs it may be necessary to suppress this informational message explicitly in order to obtain a diagnostic-free compilation of production code, since rewriting the expression not to be evaluated at compile time would impact performance. 

That's cute. The compiler detects that all case statements have
returns or we are in an endless loop and don't break out of it. Maybe
a bit too intelligent :-)

cc: Info: coolscan.c, line 2336: Extraneous semicolon. (extrasemi)
};
-^
Description: An extra semicolon was found at the end of a declaration.  It will be ignored. 
User Action: Remove the extra semicolon. 

Already mentioned by Petter. Lots of more coolscan warnings deleted.
Is Andreas Rick still maintaining coolscan?

cc -c -O2 -g3 -w0 -verbose -DHAVE_CONFIG_H -I. -I. -I../include -I../include -D_GNU_SOURCE -DPATH_SANE_CONFIG_DIR=/nobackup/andras/sane/etc/sane.d -DPATH_SANE_DATA_DIR=/nobackup/andras/sane/share -DV_MAJOR=1 -DV_MINOR=0 -DBACKEND_NAME=mustek -DLIBDIR=/nobackup/andras/sane/lib/sane mustek.c  -DPIC -o mustek.lo
cc: Warning: mustek.h, line 127: The redefinition of the macro "MIN" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect. (macroredef)
#define MIN(a,b)	((a) < (b) ? (a) : (b))
--------------------------^
Description: A macro has been redefined with either different formal parameters and/or a different body than a previous definition of the macro. 
User Action: Either make all definitions of the same macro identical, or undefine the macro using the #undef preprocessing directive before it is redefined. 

Will be fixed in the next release.

cc -c -O2 -g3 -w0 -verbose -DHAVE_CONFIG_H -I. -I. -I../include -I../include -D_GNU_SOURCE -DPATH_SANE_CONFIG_DIR=/nobackup/andras/sane/etc/sane.d -DPATH_SANE_DATA_DIR=/nobackup/andras/sane/share -DV_MAJOR=1 -DV_MINOR=0 -DBACKEND_NAME=mustek_pp -DLIBDIR=/nobackup/andras/sane/lib/sane mustek_pp.c  -DPIC -o mustek_pp.lo
cc: Info: mustek_pp.c, line 1129: In this statement, an array is being accessed outside the bounds specified for the array type. (subscrbounds)
      dev->voltages[3] = 0x32;
--------------------^
Description: The compiler has detected an array access that is outside the bounds of the array.  The array access might cause unpredictable behavior. Note that in C, an array is declared using the number of elements, but the first element has subscript 0.  It is a common coding error to attempt to access the last element of an array of "n" elements using a subscript of "n" instead of "n - 1". However, there are two common practices that intentionally employ out-of-bounds subscripts to useful/correct effects that are not reported by this message, but have separate optional messages. First, taking the address of an array element that is exactly one  beyond the last element of an array is completely valid in standard C as long as the address is not used to access memory. The optional subscrbounds2 message can be enabled to report taking the address of the array element exactly one beyond the last element. Second, it is a somewhat common practice to declare the last member of a struct as an array with one element, and then allocate such structs at runtime with different sizes, recording the actual size in an earlier member of the struct.  The optional subscrbounds1 message can be enabled to report subscripts greater than zero applied to arrays declared with only one element. 
User Action: Specify an array subscript that is within the bounds of the array type. 

This one may be critical (->possible segfault or overwriting other
data).

cc -c -O2 -g3 -w0 -verbose -DHAVE_CONFIG_H -I. -I. -I../include -I../include -D_GNU_SOURCE -DPATH_SANE_CONFIG_DIR=/nobackup/andras/sane/etc/sane.d -DPATH_SANE_DATA_DIR=/nobackup/andras/sane/share -DV_MAJOR=1 -DV_MINOR=0 -DBACKEND_NAME=mustek_usb -DLIBDIR=/nobackup/andras/sane/lib/sane mustek_usb.c  -DPIC -o mustek_usb.lo
cc: Warning: mustek_usb_low.h, line 59: The redefinition of the macro "MIN" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect. (macroredef)
#define MIN(a, b) (((a) < (b)) ? (a) : (b))
------------------------^

Will also be fixed.

Bye,
  Henning