Re: Bug report: Compile with Microsoft and Intel compiler

[Eli Zaretskii]

> Date: Fri, 29 Apr 2005 00:32:13 -0400
> From: "Paul D. Smith" <address@hidden>
> 
>   jb> function.c(512) : error C4130: '==' : logical operation on address
>   jb> of string constant
> 
>   jb> int is_suffix = streq (funcname, "suffix");
> 
>   jb> expands to:
> 
>   jb> int is_suffix = ((funcname) == ("suffix") || 
>   jb>         (*(funcname) == *("suffix") && (*(funcname) == '\0' || 
>   jb>         !strcmp ((funcname) + 1, ("suffix") + 1))));
> 
> But, there's nothing whatsoever wrong with this code.

That's true, but I still suggest to get rid of the ``optimized''
version of strcmp.  It doesn't really optimize anything, so the net
effect is obfuscated code with no benefits.  (We had similar
``optimizations'' in GDB which were removed some time ago after
discussions revealed that the ``optimized'' version runs slower than
the straightforward code--which is not surprising, since modern
compilers provide builtin inline versions of strcmp and similar
functions.)

>   jb> hash.c(49) : error C4115: 'token' : named type definition in parentheses
>   jb> hash.c(265) : error C4115: 'token' : named type definition in 
> parentheses
> 
>   jb> ht->ht_vec = (void**) CALLOC (struct token *, ht->ht_size);
> 
>   jb> expands to:
> 
>   jb> ht->ht_vec = (void**) ((struct token * *) 
>   jb>         calloc (sizeof (struct token *), (ht->ht_size)));
> 
> Well, this is kind of bogus, but there's nothing wrong with this either
> that warrants an error.

The error is just because the compiler was invoked with the equivalent
of -Werror.  The warning is justified since `struct token' is not
defined anywhere.  Why do we need that struct? can it be removed, or
replaced with a defined data type?

>   jb> main.c(1728) : error C4296: '<' : expression is always false
> 
>   jb> f->last_mtime = f->mtime_before_update = NEW_MTIME;
> 
>   jb> expands to:
> 
>   jb> f->last_mtime = f->mtime_before_update = 
>   jb> (~ (unsigned long) 0 - (! ((unsigned long) -1 < 0) ? 
>   jb>  (unsigned long) 0 : ~ (unsigned long) 0 << 
>   jb>  (sizeof (unsigned long) * 8 - 1)));
> 
> Yeah... this is exactly the way it's intended to be IIRC.

Right.  And, FWIW, this produces a warning even in GCC compiling the
DJGPP port.  I reported it a couple of months ago, and was told that
there's nothing that could be done to avoid this.