I'm trying to complete a project for school involving the use of semaphores. I have included the proper header files ( plus one for pthreads). I have pointed the compiler to the proper libraries as well. This is written in C. Yes, this is an assignment, but please be aware I am not looking for help with implementation, rather I can't seem to figure out this damnable compile error.
Here are lines 47 through 50 of my code, which are "simple" declarations of the semaphores and initializing them:
sem_t empty;
sem_init(&empty, 0, 5);
sem_t full;
sem_init(&full, 0, 0);
Here are the messages I'm getting when I try and compile for line 48. I get the same set for line 50 but didn't post it for the sake of brevity:
|48|error: expected declaration specifiers or ‘...’ before ‘&’ token|
|48|error: expected declaration specifiers or ‘...’ before numeric constant|
|48|error: expected declaration specifiers or ‘...’ before numeric constant|
|48|warning: data definition has no type or storage class|
|48|warning: type defaults to ‘int’ in declaration of ‘sem_init’|
I have declared all these outside the main() function. How can I resolve these errors? I'm baffled because it seems to indicate no data type for sem_t, but it is defined in semaphore.h, which I have included. I am compiling this using Code::Blocks under Ubuntu, which is using gcc. This error occurs even when compiling from the command line.
Thanks in advance for the help.
I think your problem may be related to scoping.
"I have declared all these outside the
main() function"
sounds suspicious, because I can see you calling a function right after the declaration.
Try moving the calls to sem_init inside main
You can declare things at file scope (i.e. outside of main, effectively creating a global variable) but you can't call functions (like sem_init) at file scope. They must be called at function scope (e.g. inside of main())
Related
I keep getting an error that says my code has tentative definition that is not defined. I do not understand what that means or why I get that error.
Below is the line of code that is causing the error
struct drand48_data drand_buf;
Then I also have the image of my terminal.
The types and functions that the error messages are complaining about are declared in stdlib.h which you apparently forgot to include. You need to add this to the top of your source file:
#include <stdlib.h>
I am getting this error within C.
error: expected ')' before '*' token
But cannot trace it.
void print_struct(struct_alias *s) //error within this line
{
...
} //end of print method
My question is when receiving this error where can the error stem back to? Is it a problem with the function, can it be an error with what is being passed in? What is the scope of the error?
The compiler doesn't recognize the name struct_alias as a type name.
For that code to compile, struct_alias would have to be declared as a typedef, and that declaration would have to be visible to the compiler when it sees the definition of print_struct.
(Typedef names are tricky. In effect, they become temporarily user-defined keywords, which is why errors involving them can produce such confusing error messages.)
This is not specific to C89; it applies equally to C90 (which is exactly the same language as C89), to C99, and to C11.
The error means that here's no such type as struct_alias declared in this translation unit.
Do I really need header files for using libraries?My code works without header files and the libraries are linked perfectly except that I get a "warning: implicit declaration of function"
message.Still its just a warning my program runs.
Header file:- is a file that allows programmers to separate certain elements of a program's source code into reusable files.
A library file is the executable code that works according to what is specified in the header file.
I get a "warning: implicit declaration of function" message.
There may be many reasons for this warning like maybe your header guard is not working right. Another possibility is that you have declared the function Func but called it with func.
Check this out:-
Including a header file is equal to copying the content of the header
file but we do not do it because it will be very much error-prone and
it is not a good idea to copy the content of header file in the source
files, specially if we have multiple source file comprising our
program.
For most of the starters this warning is seen when they start using
malloc
So I am using this example. For the warning in this case You need to add:
#include <stdlib.h>
This file includes the declaration for the built-in function malloc. If you don't do that, the compiler thinks you want to define your own function named malloc and it warns you because:
You don't explicitly declare it and
There already is a built-in function by that name which has a different signature than the one that was implicitly declared (when a function is declared implicitly, its return and argument types are assumed to be int, which isn't compatible with the built-in malloc, which takes a size_t and returns a void*).
My code works without header files and the libraries are linked
perfectly except that I get a "warning: implicit declaration of
function" message.Still its just a warning my program runs.
It is a bad practice to ignore a warning from the compiler. Programs that are not compiled properly could have bugs that might cause you bigger problems and errors in the future.
So for example, if you get a warning:
prog.c:12:5: warning: implicit declaration of /*some function used in the program*/
It is expected that you must include the header file wherein that function is defined.
Do I really need header files for using libraries?
Yes.
My code works without header files
No, it doesn't. It only appears to be working.
and the libraries are linked perfectly except that I get a "warning: implicit declaration of function" message
In this case, I wouldn't call it "perfect".
Still its just a warning my program runs.
And you can never know what it does since it now invokes undefined behavior. "Just a warning"? Sure. There's a reason the compiler warns you. Respect warnings and fix them.
Here's the quote from C99 (6.5.2.2.6) which explains why the program has UB without headers (more precisely, without proper function prototypes which you don't seem to have either):
If the expression that denotes the called function has a type that does not include a prototype, the integer promotions are performed on each argument, and arguments that have type float are promoted to double. These are called the default argument promotions. If the number of arguments does not equal the number of parameters, the behavior is undefined.
If the function is defined with a type that includes a prototype, and either the prototype ends with an ellipsis (, ...) or the types of the arguments after promotion are not compatible with the types of the parameters, the behavior is undefined.
If the function is defined with a type that does not include a prototype, and the types of the arguments after promotion are not compatible with those of the parameters after promotion, the behavior is undefined, except for the following cases:
— one promoted type is a signed integer type, the other promoted type is the
corresponding unsigned integer type, and the value is representable in both types;
— both types are pointers to qualified or unqualified versions of a character type or
void.
There's a very good reason header files are used. People who invented and designed the language knew what they were doing, and they made this decision because it's a necessary thing and a good solution to the problem that types need to be visible across compilation units.
Anybody knows why is this compiling successfully in C?
int main(){
display();
return 0;
}
void display(){
printf("Why am I compiling successfully?");
}
I thought when declaration is not provided C assume extern int Function_name(arg1,arg2,...){}. Thus this should give an error but however it's working! I know that Ideone is supressing the warnings but my question is why is it just not giving a straight error? (however in C++ it's straight error)
Turn up the warning level in your compiler and you should get 2 warnings,
display not declared, int assumed
and
display redeclared
Edit:
Older versions of C (pre C99) aren't really that bothered about return types or argument types. You could say it's part of the K&R legacy. For instance, if you don't explicitly specify the argument types, the compiler won't check them at all.
C++ is stricter, which IMO is a good thing. I always provide declarations and always specify the argument lists when I code in C.
It's compiling because C uses a lot of defaults to be backwards compatible. In K&R C, you couldn't specify function prototypes, so the compiler would just assume that you know what you're doing when you call a function.
Later (at least ANSI C, but maybe even in C99), C didn't really have a way to distinguish
void display(void);
void display();
so the empty declaration must be accepted as well.
That's why you can call display() without defining it first.
printf() is similar. You will get a linker error if you forget -lc but from the compiler's point of view, the code is "good enough".
That will change as soon as you enable all warnings that your compiler has to offer and it will fail with an error when you disable K&C compatibility or enable strict ANSI checks.
Which is why "C" is often listed as "you shoot yourself into the foot" in "How to Shoot Yourself In the Foot Using Any Programming Language" kind of lists.
it depends of your Cx (C89, C90, C99,...)
for function return values, prior to C99 it was explicitly specified that if no function declaration was visible the translator provided one. These implicit declarations defaulted to a return type of int
Justification from C Standard (6.2.5 page 506)
Prior to C90 there were no function prototypes. Developers expected to
be able to interchange argu-ments that had signed and unsigned
versions of the same integer type. Having to cast an argument, if the
parameter type in the function definition had a different signedness,
was seen as counter to C’s easy-going type-checking system and a
little intrusive. The introduction of prototypes did not completely do
away with the issue of interchangeability of arguments. The ellipsis
notation specifies that nothing is known about the 1590 ellipsis
supplies no information expected type of arguments. Similarly, for
function return values, prior to C99 it was explicitly specified that
if no function declaration was visible the translator provided one.
These implicit declarations defaulted to a return type of int . If the
actual function happened to return the type unsigned int , such a
default declaration might have returned an unexpected result. A lot of
developers had a casual attitude toward function declarations. The
rest of us have to live with the consequences of the Committee not
wanting to break all the source code they wrote. The
interchangeability of function return values is now a moot point,
because C99 requires that a function declaration be visible at the
point of call (a default declaration is no longer provided)
It probably does (assume such declaration as you wrote), but as you are not passing parameters, it just works fine. It's the same like if you declare int main() where it should actually be int main(int argc, char *argv[]).
So probably if you tried to pass some parameters (different from default ones) from main then use them in display it would fail.
BTW, for me it compiles, but generates warning:
$ gcc z.c
z.c:8:6: warning: conflicting types for ‘display’ [enabled by default]
z.c:4:5: note: previous implicit declaration of ‘display’ was here
When I compile with gcc, I get warnings about redeclaration of display, as you would expect.
Did you get warnings?
It might "run" because C doesn't mangle function names (like C++). So the linker looks for a symbol 'display' and finds one. The linker uses this address to run display. I would expect results to not be what you expect all the time.
It seems I can call a function without prototype and definition of it in C, and the compilation (no link) worked well. Link would work if the function is defined in other module which is passed to the link command. But the call site would assume every parameter passed to it is int type. Is there any documentation for this or any part of the C standard mentioned this behavior?
For example, below source file could be compiled without any problem in VC++ 2010.
// NoPrototype.c
// Compile it as cl.exe /c NoPrototype.c
int main()
{
FakeFunction(1, 2, 3); // No definition for this function in this compilation unit.
}
Not having a declaration in scope is UB.
J.2 Undefined behavior
— For call to a function without a function prototype in scope where the function is defined with a function prototype, either the prototype ends with an ellipsis or the types of the arguments after promotion are not compatible with the types of the parameters (6.5.2.2).
Comeau rejects your code
"ComeauTest.c", line 5: error: identifier "FakeFunction" is undefined
FakeFunction(1, 2, 3); // No definition for this function in this compilation unit.
^
1 error detected in the compilation of "ComeauTest.c"
That is the way it worked in old, pre-standard C. It was (and is, pre C99) ok to have functions returning int and taking int parameters, without a prototype. It is your responsibility to make sure that is the way the function looks in some other .c file, including actually taking the number of parameters you have in each call.
This is the reason why functions like toupper is int toupper(int c);, not using char. It was originally used without a prototype, and that implicit interface got stuck!