On Thu, 30 Mar 2000, Jerome Lauret wrote:
> On 30 Mar 2000 [EMAIL PROTECTED] wrote:
> |$ cc [-.Implementation]HTMIME.c
> |
> | } else if (LYmktime(me->anchor->expires, FALSE) <= 0) {
> |...................^
> |%CC-I-QUESTCOMPARE, In this statement, the unsigned expression
> |"LYmktime(...)" i
> |s being compared with a relational operator to a constant whose value is
> |not gre
> |ater than zero. This might not be what you intended.
> |at line number 355 in file DISK:[JLAURET.APPS_DEV.LYNX2-8-3.WWW.LIBRARY.I
> |MPLEMENTATION]HTMIME.C;1
> | This is just a "I" message (i.e. Informational) and just point on a
> |potential problem in LYmktime compared to 0 with a <= 0. LYmktime is declared
> |as "extern time_t", time_t declared in HTVMSUTILS.H -> HTUTILS.H -> TYPES.H ->
> |DECC$TYPES.H as an "unsigned long int" so it is doubtfull that a negative value
> |would be returned. This fix would be cosmetics-related and does not impact on
> |run. Although, looking at the LYktime() function (in sc/luutils.c) it does not
> |appear that the return value would have any chance to be negative (either 0 or
> |a calculation of clock2 (line 6108) itself of time_t type. Is this like so
> |because some OS have time_t being something else than "unsigned" ? If this is
> |the case, then a modification of the compilation option uder VMS would
> |have to be done ; otherwise, a code change is preferrable.
>
> In short :
>
> - Nothing to do with Multinet header
> - Is in the provided DECC$TYPES.H
> - Related to time_t == unsigned long
> - DECC (at least for version V6.2-003) emmit a warning when an unsigned
> int is compared with a <= 0 or < 0 instruction. Earlier version might not
> issue a "I" message but THIS DOES NOT MEAN that the code is
> syntaxicly correct ; it just means that the compiler was not made aware of
> this potentially dangerous/faulty comparison.
> The message makes sens, how can an "unsigned long" be negative anyway ??
But we're not testing whether it is negative. Only whether it is non-positive.
> Now that it should be clear to all of us that an unsigned long cannot
> be < 0, the real question now is :
>
> - Is this because some OS have time_t <> 'unsigned' ?
IIRC, according to C standards, time_t need not even be an integer type.
> YES => VMS compiler option to suppress this warning
It's a bit too picky, IMO...
> NO => patch the code
> 1) i.e. replace <= 0 by == 0
Maybe makes sense, since (time_t)0 is the only value with special
meaning that LYmktime returns.
But it is exactly equivalent anyway, as long as time_t is an unsigned integer
type. And for any environment where time_t is NOT an unsigned type (if such
a system exists), the '<=' may still make more sense than a '=='.
I think you should just live with the warning...
> 'return (unsigned long) clock2;' in this function (line 6108
> in src/LYutils.c)
That would be worse for portability - no casting to a specific type
should be necessary.
Klaus
