No no, that's a typo of mie when composing the mail.
Imagine it's "int main(void)".
···
El Lunes, 12 de Octubre de 2009, Tim Hunter escribió:
Iñaki Baz Castillo wrote:
> Hi, writting a Ruby C extension (for 1.8 or 1.9) I get an error when
> using
> "enum":
>
> #include "ruby.h"
> int void(void) {
> enum kk {ONE, TWO, THREE}; // line 3
> }
>
> line 3: error: expected identifier before ‘(’ token
>
>
> It doesn't occur if I quit "ruby.h". What is happening?
>
> Thanks.
I think the compiler is complaining about your attempt to use "void" as
a function name. "void" is a reserved word in C.
Iñaki Baz Castillo wrote:
> Hi, writting a Ruby C extension (for 1.8 or 1.9) I get an error when
> using
> "enum":
>
> #include "ruby.h"
> int void(void) {
> enum kk {ONE, TWO, THREE}; // line 3
> }
>
> line 3: error: expected identifier before ‘(’ token
>
>
> It doesn't occur if I quit "ruby.h". What is happening?
What does "quit ruby.h mean"?
I just mean that the above code (note that it should be "int main(void)")
without '#include "ruby.h"' line compiles ok.
What compiler are you using?
gcc 4.3 under Debian Lenny 64 bits.
test.c :
-----
int void(void) {
enum kk {ONE, TWO, THREE}; // line 3
}
--output:--
$ g++ test.c -o test
test.c:1: error: expected unqualified-id before ‘void’
Yes, a typo of my mail. Please use "int main(void)" instead.
···
El Lunes, 12 de Octubre de 2009, 7stud -- escribió:
------
On Monday 12 October 2009 11:17:08 Iñaki Baz Castillo wrote:
El Lunes, 12 de Octubre de 2009, Iñaki Baz Castillo escribió:
> Hi, writting a Ruby C extension (for 1.8 or 1.9) I get an error when
> using "enum":
>
> #include "ruby.h"
> int void(void) {
> enum kk {ONE, TWO, THREE}; // line 3
> }
>
> line 3: error: expected identifier before ‘(’ token
>
>
> It doesn't occur if I quit "ruby.h". What is happening?
opss, the same error occurs if I add "#include <stdio.h>".
Are you sure the typo was only in the mail? If I copy and paste this code in a
file and try to compile it, the compiler complains about the same error,
because void is a reserved keyword in C. But when I change that "void(void)"
into "main(void)" it compiles ok.
--
angico
------
Site: angico.org
Blog: angico.org/blog
Gnu/Linux, FLOSS, Espiritismo, e eu por mim mesmo 8^I
Are you sure the typo was only in the mail? If I copy and paste this code
in a file and try to compile it, the compiler complains about the same
error, because void is a reserved keyword in C. But when I change that
"void(void)" into "main(void)" it compiles ok.
----------------
int main(void) {
enum kk {NULL=0, NS=1, URL=2};
}
----------------
It compiles ok.
Now:
file_b.c
---------------- #include <stdio.h>
int main(void) {
enum kk {NULL=0, NS=1, URL=2};
}
----------------
$ gcc file_b.c
file_b.c: In function ‘main’:
file_b.c:3: error: expected identifier before ‘(’ token
El Lunes, 12 de Octubre de 2009, 7stud -- escribió:
> line 3: error: expected identifier before ‘(’ token
>
>
> It doesn't occur if I quit "ruby.h". What is happening?
What does "quit ruby.h mean"?
I just mean that the above code (note that it should be "int
main(void)")
without '#include "ruby.h"' line compiles ok.
What compiler are you using?
gcc 4.3 under Debian Lenny 64 bits.
test.c :
-----
int void(void) {
enum kk {ONE, TWO, THREE}; // line 3
}
--output:--
$ g++ test.c -o test
test.c:1: error: expected unqualified-id before ‘void’
Yes, a typo of my mail. Please use "int main(void)" instead.
Maybe next time you should consider posting the code that actually
produced the error message. Debugging fake programs never works very
well.
--
Posted via http://www.ruby-forum.com/\.
I think you'll find your problem is due to a macro for NULL.
Change your code from "NULL" to "kNULL":
#include <stdio.h>
int main(void) {
enum kk {kNULL=0, NS=1, URL=2};
}
and your problem goes away.
-Rob
···
On Oct 12, 2009, at 10:52 AM, Iñaki Baz Castillo wrote:
El Lunes, 12 de Octubre de 2009, angico escribió:
Are you sure the typo was only in the mail? If I copy and paste this code
in a file and try to compile it, the compiler complains about the same
error, because void is a reserved keyword in C. But when I change that
"void(void)" into "main(void)" it compiles ok.
ok, let's try it:
file_a.c
----------------
int main(void) {
enum kk {NULL=0, NS=1, URL=2};
}
----------------
It compiles ok.
Now:
file_b.c
---------------- #include <stdio.h>
int main(void) {
enum kk {NULL=0, NS=1, URL=2};
}
----------------
$ gcc file_b.c
file_b.c: In function ‘main’:
file_b.c:3: error: expected identifier before ‘(’ token
---------------- #include <stdio.h>
int main(void) {
enum kk {NULL=0, NS=1, URL=2};
}
NULL is a symbol defined by the implementation, and defined by several of
the standard headers (including <stdio.h>).
Usually, it is either "0" or "(void *) 0" or something equivalent.
$ gcc file_b.c
file_b.c: In function ?main?:
file_b.c:3: error: expected identifier before ?(? token
I'd bet you've got one where it's "(void *) 0".
-s
···
On 2009-10-12, Iñaki Baz Castillo <ibc@aliax.net> wrote:
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net | Seebs.Net <-- lawsuits, religion, and funny pictures Fair game (Scientology) - Wikipedia <-- get educated!
If you suspected what it was, you wouldn't need to ask for help. So it
is usually best to try to include a tested reproducer rather than guessing
at which parts are relevant.
This is something that takes people a few tries to get, usually.
-s
···
On 2009-10-12, Iñaki Baz Castillo <ibc@aliax.net> wrote:
Right, I'm sorry. I never spected that the usage of "NULL" was creating the
issue.
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net | Seebs.Net <-- lawsuits, religion, and funny pictures Fair game (Scientology) - Wikipedia <-- get educated!
At least, mocking up an example is fine, but check that the mocked up
example demonstrates the same failure. In this case, your mocked up
example did not, and having seen that, you would likely have solved
the problem yourself
···
On Mon, Oct 12, 2009 at 7:25 PM, Seebs <usenet-nospam@seebs.net> wrote:
On 2009-10-12, Iñaki Baz Castillo <ibc@aliax.net> wrote:
Right, I'm sorry. I never spected that the usage of "NULL" was creating the
issue.
The secret to effective debugging:
If you suspected what it was, you wouldn't need to ask for help. So it
is usually best to try to include a tested reproducer rather than guessing
at which parts are relevant.
Yes. And be sure the mockup is actually representing the problem as such...
My favorite example of recent memory: Someone reported a bug, which
was that the compiler was generating an instruction not supported by a
particular CPU. The submitted reproducer, to simplify things, simply
included the unwanted instruction in inline assembly... It took some
prodding to discover that there was an actual, underlying, problem.
-s
···
On 2009-10-12, Paul Smith <paul@pollyandpaul.co.uk> wrote:
At least, mocking up an example is fine, but check that the mocked up
example demonstrates the same failure. In this case, your mocked up
example did not, and having seen that, you would likely have solved
the problem yourself
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net | Seebs.Net <-- lawsuits, religion, and funny pictures Fair game (Scientology) - Wikipedia <-- get educated!
El Lunes, 12 de Octubre de 2009, Paul Smith escribió:
On Mon, Oct 12, 2009 at 7:25 PM, Seebs <usenet-nospam@seebs.net> wrote:
> On 2009-10-12, Iñaki Baz Castillo <ibc@aliax.net> wrote:
>> Right, I'm sorry. I never spected that the usage of "NULL" was creating
>> the issue.
>
> The secret to effective debugging:
>
> If you suspected what it was, you wouldn't need to ask for help. So it
> is usually best to try to include a tested reproducer rather than
> guessing at which parts are relevant.
At least, mocking up an example is fine, but check that the mocked up
example demonstrates the same failure. In this case, your mocked up
example did not, and having seen that, you would likely have solved
the problem yourself
I don't participate in Usenet because I want the answers I give to the
specific questions people asked to be the most efficient possible use of
anyone's time; I participate in Usenet because I want to learn things and
help other people learn things.
If you learned something about debugging, and something about asking
questions, that's great. It doesn't have to always be exactly the thing
you thought you were going to learn...
-s
···
On 2009-10-12, Iñaki Baz Castillo <ibc@aliax.net> wrote:
100% agree. I'm really sorry the waste of time.
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net | Seebs.Net <-- lawsuits, religion, and funny pictures Fair game (Scientology) - Wikipedia <-- get educated!