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
