static scope not honored by gcc

Bug Demo program

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

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.

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.

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

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

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.

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

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.

Don't give up that fast. Give it a go with the GCC maintainers, there are some that develop for Windows GCC that aren't following this forum.