[MinGW-notify] [ mingw-Bugs-3290563 ] static scope not honored by gcc

[SF/projects/mingw n. l. <min...@li...>]

Bugs item #3290563, was opened at 2011-04-20 13:49
Message generated for change (Comment added) made by markpizz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3290563&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gcc
Group: Behaves as Documented
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Mark Pizzolato (markpizz)
Assigned to: Nobody/Anonymous (nobody)
Summary: static scope not honored by gcc

Initial Comment:
Compiling:
#include <stdio.h>
#include <windows.h>

static void Beep (void)
{
printf("Hello World\n");
}

int main(int argc, char **argv)
{
Beep();
}
produces:
GCCBug.c:4:13: error: conflicting types for 'Beep'
h:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/winbase.h:1299:24: note: previous declaration of 'Beep' was here

H:\MinGW\Bugs>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=h:/mingw/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --
enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-we
rror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.2 (GCC)
#define __MINGW32_VERSION           3.18
#define __W32API_VERSION 3.17
OS: Windows 7 Pro x64
Running from cmd.exe


----------------------------------------------------------------------

Comment By: Mark Pizzolato (markpizz)
Date: 2011-04-22 05:37

Message:
The '-fms-extensions' cases would seem to be most relevant to MinGW's use
of gcc rather than any other situation.  These features more than likely
originally came from the MinGW universe of users/developers.

I'm merely pointing out that some detail which should comprise
'ms-extensions' is missing.

I can't imagine the upstream GCC folks caring one bit about these things
if the MinGW folks don't.

The code which brought this to my attention was not code I wrote or
control.  It was code I encountered which compiles cleanly with the
Microsoft compilers..

Sadly, MinGW played an important role when Microsoft didn't have free
compilers available.Situations like this case will merely cause more folks
to stop looking at MinGW.


----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2011-04-22 05:26

Message:
I contend that including windows.h is already stating that you want to use
those extensions.  Good luck with convincing GCC upstream maintainers.

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2011-04-21 23:39

Message:
You are welcome to take your contention upstream, to the GCC Project
itself.  Successive versions of GCC have become stricter in their rejection
of bad source constructs; personally, I think this is a good thing.  At
best, your use case is ambiguous; it is bad code.  You should fix it.  We
will take no further action in this matter, unless you can convince the
upstream GCC maintainers to change the current behaviour.

----------------------------------------------------------------------

Comment By: Mark Pizzolato (markpizz)
Date: 2011-04-21 17:46

Message:
Microsoft does document this behavior as a potential extension on the page:
 http://msdn.microsoft.com/en-us/library/34h23df8(v=vs.80).aspx

I contend that it should be allowed if the compiler is invoked with
'-fms-extensions'.  

It now behaves the same with or without -fms-extensions

----------------------------------------------------------------------

Comment By: Mark Pizzolato (markpizz)
Date: 2011-04-21 17:18

Message:
This isn't how the C language I've known since the late '70s has worked.

Specifically, the point of the "static" declarataion is that the
statically routine is explciitly only useful/visible within the scope of
the current compilation module regardless of the existence of external
functions in other modules and/or libraries (which is exactly what an
'extern' declaration refers to).  

If you look atthe code which gcc generates in the case of a static
procedure vs the external one, the name is managed differently than the
external one, so the resulting assembler/binary will do the right thing if
the compiler merely honored the static declaration properly.

The code:
#include <stdio.h>
#include <windows.h>

static void MBeep (void)
{
printf("Hello World\n");
}

int main(int argc, char **argv)
{
MBeep();
Beep(1, 2);
}
compiles to:
	.file	"GCCBug.c"
	.section .rdata,"dr"
LC0:
	.ascii "Hello World\0"
	.text
	.def	_MBeep;	.scl	3;	.type	32;	.endef
_MBeep:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$24, %esp
	movl	$LC0, (%esp)
	call	_puts
	leave
	ret
	.def	___main;	.scl	2;	.type	32;	.endef
.globl _main
	.def	_main;	.scl	2;	.type	32;	.endef
_main:
	leal	4(%esp), %ecx
	andl	$-16, %esp
	pushl	-4(%ecx)
	pushl	%ebp
	movl	%esp, %ebp
	pushl	%ecx
	subl	$20, %esp
	call	___main
	call	_MBeep
	movl	$2, 4(%esp)
	movl	$1, (%esp)
	call	_Beep@8
	subl	$8, %esp
	movl	-4(%ebp), %ecx
	leave
	leal	-4(%ecx), %esp
	ret
	.def	_puts;	.scl	2;	.type	32;	.endef
	.def	_Beep@8;	.scl	2;	.type	32;	.endef


----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2011-04-21 15:02

Message:
Mark,

Maybe "reserved word" isn't quite the correct description, but on this one
I fully support Earnie's decision; according to

http://msdn.microsoft.com/en-us/library/ms679277%28VS.85%29.aspx

Beep() is a function with extern scope, prototyped when you #include
windows.h, (as your example code does).  Thus, your later attempt to
redefine it with static scope is invalid.  That MSVC (apparently) accepts
your invalid code is yet another example of all too common broken behaviour
of MSVC -- GCC is a MUCH better compiler, if you value good checking for
valid, standards conforming source.

----------------------------------------------------------------------

Comment By: Mark Pizzolato (markpizz)
Date: 2011-04-21 05:49

Message:
Where does it say that "Beep" is a "Windoes reserved word"?

Both the original real program AND the 12 line demo compile cleanly using
any of the Microsoft compilers.

I wasn't looking for a workaround when using MinGW, I was looking for
MinGW to work as a replacement for the Microsoft compiler.

If you are declaring that the behavior I'm seeing is "as Documented",
please provide a reference to the relevant documentation.  There is no
documentation on the Microsoft compilers which might declare this issue as
reserved since it works just fine in there.

Please reopen this issue and actually address what is happening.

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2011-04-21 04:39

Message:
The bug is your use of a Windows reserved word.  You will need to change
your static void Beep() to static void MyBeep().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3290563&group_id=2435