Building openal
In openAL, the following code produces an error. This compiles with gcc and produces a warning with icc. Should this error be a warning, etc. as changing open source code is just not that easy
typedef void ALCcontext ;
typedef void ALCvoid ;
ALCcontext * alcGetCurrentContext ( ALCvoid ) ;
int main ( int argc , char * argv [ ] )
{
}
I should also mention I get the following error with OpenGL
"/.../include/GL/glext.h", line 3602: Error: A value of type void is not allowed.
This is with delivered code that Sun worked with the vendors on and it problems get's worse when I try to work around the nvidia include files.
Message was edited by:
Brett_Tiplitz
# 1
C++ Standard section 8.3.5 "Functions", paragraph 2 allows the keyword"void" in place of an empty parameter list, meaning the function does not take any arguments. It does not allow a typedef for void. Using a typedef would mean the function takes a single parameter of type void, which is not allowed.
int f1(); // f1 takes no arguments
int f2(void); // f2 takes no arguments
typedef void V;
int f3(V); // invalid declaration
# 4
> I still would ask why this is not a warning as gcc
> builds the code and icc builds it.
It's an error because the Standard says the code is not valid. Our view is that we do the programmer no favors by accepting invalid code, because such code is not portable among standard-conforming compilers.
Once you abandon the Standard as the reference for valid code, how do you decide what to accept, and what invalid code means if you accept it? And what if some other compiler accepts the same invalid code, but treats it differently?
But in this case, accepting the typedef for void seems harmless. In the interest of gcc compatibility, we can turn this error into a warning in an update to the compiler.
# 5
Do you have any idea on when the change will be completed (or that I could get an early release of the change). This does prevent me from producing a binary and thus actually testing a very large program with the new compiler.
I can get access to internal drops if possible via my support contract. I would just need to know where to pull the test code. (and then I have to get support to get it for me)
# 8
I filed bug 6546397 for this issue. It will be visible at bugs.sun.com in a day or so.
Since you have a support contract, you can ask your Sun Services representative to escalate the bug so that it will be included in the first patch to Studio 12 C++. (Escalating a bug ensures it gets prompt attention.)
We do not have an estimated date for the first patch, mainly because Studio 12 has not yet been released, but via your service contract you can get a pre-patch-release version to try out as soon as it is available.
