bugmake - Bugs: bug #13479, Compile errors and warnings -...

 
 

bug #13479: Compile errors and warnings - Microsoft compiler 13.10 (.NET 7.1)

Submitter:  Jerker Bäck <jerker_back>
Submitted:  Mon 20 Jun 2005 06:48:42 AM UTC
   
 
Severity:  3 - Normal Item Group:  Build/Install
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  4.0 Operating System:  MS Windows
Fixed Release:  3.81 Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 09 May 2006 01:30:06 AM UTC, comment #5: 

I'll close this one.  I'm right now in the middle of "ANSI-ifying" the code, and adding lots of const's etc.  Once that's done there will be some amount of work to do to fix up the ports (Windows/Amiga/VMS/etc.)  As a part of that work, or separately, you can send in fixes for these types of warnings or else file new bugs about them.

Paul D. Smith <psmith>
Group administrator
Mon 01 May 2006 02:25:51 AM UTC, comment #4: 

Paul, can we close this one also?
The strerror bug is fixed and there's no point to have an old compile report active. My intent was merely to give you a chance to clean up the code from all this warnings. The majority is of type casting warnings and could easy be explicit cast to the right type.

Example:
rule.c(393) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
expands to:
r->terminal = terminal;

Solution:
r->terminal = (char)terminal;

Currently, in 3.81 release, about 25 C4244 warnings is issued.

Even if you think it's a minor thing, besides annoying it just look so ugly with several hundred warnings and it is so completly unnecessary. I sense that the amount of warnings have decreased lately though.

If you want, I can send you a new compile report from the 3.81 release - otherwise just close it.


Jerker Bäck <jerker_back>
Sun 26 Jun 2005 04:05:18 PM UTC, comment #3: 

whoops, I didn't see the undef ANSI_STRING.  Strange.  This should be moved to after the strerror().  Is that what the discussion in April decided?  I'll go look.

Anyway, the undef strerror is just for some compilers that #define strerror.  It obviously has no effect on systems where strerror is a normal function/prototype, and not a macro.

That's why it has no impact on MSC.

Paul D. Smith <psmith>
Group administrator
Sun 26 Jun 2005 02:06:17 PM UTC, comment #2: 

noop, I've used the config.h.W32 until recently when I actually succeded in running configure.(!) The ANSI_STRING issue is actually a bug (discussed in april). Look at this:

make.h(280):
-----------------------------------------
#undef  ANSI_STRING

/* SCO Xenix has a buggy macro definition in <string.h>.  */
#undef  strerror

#if !defined(ANSI_STRING) && !defined(__DECC)
extern char *strerror PARAMS ((int errnum));
#endif
-----------------------------------------
=> strerror will always be redeclared unless __DECC

Comment:
MSCRT have in <string.h>
_CRTIMP char *  __cdecl strerror(int);

Somehow the compiler just ignore the #undef (can't #undef preprocessed code?) and since I need to compile with __stdcall calling convention (DDK standard) the above declaration will be:
extern char * __stdcall strerror(int);
=> error C2373: 'strerror' : redefinition

Now, don't react on the calling conventions. They can't be the cause of any errors, rather they can expose some overlooked passages in the code. See the last sentence in the bug report.

A compile with __cdecl and explicit switch /TC will not issue this error(not visible or less strict). Recent Microsoft compilers seems to have /TP switch regardless of source-file extension and since security is the main US agenda they tend to be focused on more stricter conditions. Furthermore, I really do want to have maximum diagnostics with a compiler complaining about pretty much everything it feels uncomfortable with.

Anyway under all circumstances, the declaration should not be enabled for Microsoft/Intel/Borland compilers.

regards JB


Jerker Bäck <jerker_back>
Sat 25 Jun 2005 10:06:39 PM UTC, comment #1: 

I'm looking at these messages and I'm confused by the first one:
error C2373: 'strerror' : redefinition; different type modifiers
In make.h, strerror() is only prototyped if ANSI_STRING is not defined.  ANSI_STRING is defined if STDC_HEADERS is defined.  And, the config.h.W32 files all define STDC_HEADERS.

Can you work out why this message is happening?  I'm concerned that the config.h file you are using is not correct for some reason: if that's true then you will get all kinds of spurious errors and warnings.

Paul D. Smith <psmith>
Group administrator
Mon 20 Jun 2005 06:48:42 AM UTC, original submission:  

In the end of april 2005 there was some discussions on the windows mailing list about compiling GNU make with Microsoft and Intel compilers. Unfortunately, nothing substantial came out of this. I'm working on a summary of the discussion and will post it to the mailing list. Meanwhile, I submit a build log from a compile of CVS source files (as of june 20).

Most of this warnings could be fixed once and for all by explicit casts (ie from int to char) if they are considered harmless.

regards Jerker

Jerker Bäck <jerker_back>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #3109:  buildfre_wnet_x86.log added by jerker_back (16KiB - application/octet-stream - Build log from compile of CVS source 3.81beta3)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follow 5 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2006-05-09 psmith Assigned toNone psmith
    Open/ClosedOpen Closed
    Fixed ReleaseNone 3.81
2006-05-09 psmith StatusNone Fixed
2005-06-20 jerker_back Attached File- Added buildfre_wnet_x86.log, #2617

Back to the top

Powered by Savane 3.13-02a9.
Corresponding source code