stdarg causes compile error

[alethiophile]

I have written a stdarg.h file containing only the simple gcc-builtin implementation noted on the 'Printing to Screen' wiki page. The code:

Code: Select all

/* stdarg. This defines va_start, va_list, etc. */

#ifndef STDARG_H
#define STDARG_H

#define va_start(v,l) __builtin_va_start(v,l)
#define va_arg(v,l) __builtin_va_arg(v,l)
#define va_end(v) __builtin_va_end(v)
#define va_copy(d,s) __builtin_va_copy(d,s)
typedef __builtin_va_list va_list

#endif /* STDARG_H */

When I compile this, it causes an error message in compiling any file that includes my other header, kstdio.h, which contains printf and related utilities.

Code: Select all

/* Provides stdio-like routines for in-kernel use. */

#ifndef KSTDIO_H
#define KSTDIO_H

#include "stdarg.h"
#include "mpos.h"

/* As vsnprintf() in stdio.h. Prints up to n chars to buf, using fmt and args                                                                                
   as printf()-like arguments.                                                                                                                               
*/
u32int vsnprintf(char *buf, u32int n, char *fmt, va_list args); // Error on this line here
/* Uses vsnprintf() above to print to the screen. */
u32int printf(char *fmt, ...);

u32int sprintx(char *, u32int);
u32int sprintd(char *, u32int);

u32int atoi(char *);

#endif /* KSTDIO_H */

The error message is

Code: Select all

In file included from kernel.c:15:
kstdio.h:12: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'u32int'

The typedefs of u32int, etc. are all in mpos.h, which I have included in kstdio.h. When I comment out the #defines and the typedef in stdarg.h it compiles this code fine (it later gives another error relevant to va_arg, etc., not being defined). Does anyone know why this would be?

[pcmattman]

Code: Select all

typedef __builtin_va_list va_list

Missing something?

[jal]

Code: Select all

typedef __builtin_va_list va_list

Missing something? ;)

Hey, the use for semi-colons is wildly overestimated anyway :).

@OP: If you had bothered to check the warning / error messages, you could've easily found out yourself!

JAL

[alethiophile]

Sorry, I missed that. And yes, I did check the warning/error messages. They weren't helpful. The only error message it gave is posted above--is that so helpful to you?
I really wish gcc would warn you about that kind of thing.

[Solar]

I really wish gcc would warn you about that kind of thing.

That is more difficult than it sounds. How should GCC know where a typedef statement should end? The compiler doesn't see the semantics, or even your source formatting (it's been tokenized and parsed already at that point). The compiler has no idea what you wanted it to do, it only knows what you instructed it to do, and has to give the best error message it could given the circumstances.

And a specific error message that is wrong would be more of a nuisance than an unspecific one that isn't, IMHO.

[alethiophile]

I suppose that's true. I know there are source checkers around that catch dumb things like that, but I haven't been able to find one. (The only one whose name I know is lint, and googling that has been unhelpful.)

[jal]

And yes, I did check the warning/error messages. They weren't helpful. The only error message it gave is posted above--is that so helpful to you?

Yes, it is very helpful. gcc tells you that at line 12, there's something unexpected coming before the very first token on that line. So then you backtrace to what could cause that, and that can only be the include file.

I do agree with you though that in this case the error message could have been more specific, by not only saying the token it expects, but the token it actually saw (i.e., va_list). That would have been more helpful. If the error message said "expected '=', ',', ';', 'asm' or '__attribute__' before 'u32int', but found va_list", you'd have directly known the cause.


JAL

[Solar]

I'm not sure it could do that, either - does it see va_list at that phase, or has that already been resolved to whatever __builtin_va_list is actually defined to be, at that point...?

Take it easy on the OP. Unscrambling compiler errors isn't something that comes easy, or through anything but experience. A quick hands up of those of us who have never been stumped by a compiler error in their life.

/me leaves his hands down.

As for lint, try Splint.

[jal]

I'm not sure it could do that, either - does it see va_list at that phase, or has that already been resolved to whatever __builtin_va_list is actually defined to be, at that point...?

I'm pretty sure is hasn't, as it cannot resolve the typedef. I'm pretty sure it is still evaluating tokens at that point, but I may very well be wrong.

/me leaves his hands down.

Me too, I have been programming for too long :).


JAL