I want a list of Header files in C which are not necessary to use them.
Example:
scanf(), printf(),.... etc. //can be use without stdio.h
getch()...etc. //can be used without conio.h
Is is necessary to write these headers(stdio.h, conio.h) while I use these(above) methods?
Using functions without prototypes is deprecated by the current standard, C99, and will probably be removed in the next version. And this is for a very good reason. Such usage is much error prone and leads to hard to track faults. Don't do that.
In the current C language standard, function declarations (but not prototypes) are mandatory, and prototypes have always been mandatory for variadic functions like printf. However, you are not required to include the headers; you're free to declare/prototype the functions yourself as long as you have the required types available. For example, with printf, you could do:
int printf(const char *, ...);
printf("%d\n", 1);
But with snprintf, you would need at least stddef.h to get size_t:
#include <stddef.h>
int snprintf(char *, size_t, const char *, ...);
And with non-variadic functions, a non-prototype declaration is valid:
int atoi();
Depends on your compiler.
For GCC: http://gcc.gnu.org/viewcvs/trunk/gcc/builtins.def?view=markup
Basically you can use any C function without a header. The header contains the prototypes for these functions making it possible to warn about wrong type or number of parameters.
So yes you can do without these headers.
But no you shouldn't do this.
But normally you don't write these header, these are provided by the build environment.
Another thing since these checks are only warnings in C you should switch on these warnings and treat them like errors. Otherwise you are in for a very bad C experience.
In gcc you should always run with options -W -Walland avoid all warnings these give.
An BTW these are not methods but functions.
Addendum: since you are gonna treat all warnings as errors you might turn on -Werror which turns all warnings into error just enforcing this.
Personally I'm not using this option but have the discipline to clean out all warnings in the end. This makes it possible to ignore the warnings for a while and usually do a clean up before I commit to version control.
But certainly for groups it makes sense to enforce this with -Werror e.g. in test scripts run before allowing commits.
Related
What is meant by the term "implicit declaration of a function"? A call to a standard library function without including the appropriate header file produces a warning as in the case of:
int main(){
printf("How is this not an error?");
return 0;
}
Shouldn't using a function without declaring it be an error? Please explain in detail. I searched this site and found similar questions, but could not find a definitive answer. Most answers said something about including the header file to get rid of the warning, but I want to know how this is not an error.
It should be considered an error. But C is an ancient language, so it's only a warning.
Compiling with -Werror (GCC) fixes this problem.
When C doesn't find a declaration, it assumes this implicit declaration: int f();, which means the function can receive whatever you give it, and returns an integer. If this happens to be close enough (and in case of printf, it is), then things can work. In some cases (e.g., the function actually returns a pointer, and pointers are larger than ints), it may cause real trouble.
Note that this was fixed in newer C standards (C99 and C11). In these standards, this is an error. However, GCC doesn't implement these standards by default, so you still get the warning.
Implicit declarations are not valid in C.
C99 removed this feature (present in C89).
GCC chooses to only issue a warning by default with -std=c99, but a compiler has the right to refuse to translate such a program.
To complete the picture, since -Werror might considered too "invasive",
for GCC (and LLVM), a more precise solution is to transform just this warning in an error, using the option:
-Werror=implicit-function-declaration
See How can I make this GCC warning an error?.
Regarding general use of -Werror: Of course, having warningless code is recommendable, but in some stage of development it might slow down the prototyping.
Because of historical reasons going back to the very first version of C, it passes whatever type the argument is. So it could be an int or a double or a char*. Without a prototype, the compiler will pass whatever size the argument is and the function being called had better use the correct argument type to receive it.
For more details, look up K&R C.
An implicitly declared function is one that has neither a prototype nor a definition, but is called somewhere in the code. Because of that, the compiler cannot verify that this is the intended usage of the function (whether the count and the type of the arguments match). Resolving the references to it is done after compilation, at link-time (as with all other global symbols), so technically it is not a problem to skip the prototype.
It is assumed that the programmer knows what he is doing and this is the premise under which the formal contract of providing a prototype is omitted.
Nasty bugs can happen if calling the function with arguments of a wrong type or count. The most likely manifestation of this is a corruption of the stack.
Nowadays this feature might seem as an obscure oddity, but in the old days it was a way to reduce the number of header files included, hence faster compilation.
C is a very low-level language, so it permits you to create almost any legal object (.o) file that you can conceive of. You should think of C as basically dressed-up assembly language.
In particular, C does not require functions to be declared before they are used. If you call a function without declaring it, the use of the function becomes its (implicit) declaration. In a simple test I just ran, this is only a warning in the case of built-in library functions like printf (at least in GCC), but for random functions, it will compile just fine.
Of course, when you try to link, and it can't find foo, then you will get an error.
In the case of library functions like printf, some compilers contain built-in declarations for them so they can do some basic type checking, so when the implicit declaration (from the use) doesn't match the built-in declaration, you'll get a warning.
If I use printf, scanf, puts or some other function in C (not C++) and don't write an include line, can it be treated as unspecified or undefined behaviour?
As I remember, C didn't require porotope declaration at all, but it was recommended to have them to allow compiler to make type casts on calling. And prototypes for printf and other such functions are not required still, not sure about custom functions.
PS: This question relates to discussion in comments of https://codegolf.stackexchange.com/a/55989/32091.
Is it correct to drop #include in C?
No, it's not correct. Always include it if you use a stdio.h function like printf.
C has removed implicit declarations (with C99) and the includes are required. The only other alternative is to have a visible prototyped declaration for printf.
Moreover even when C had implicit declarations, implicit declarations are not OK for variable argument functions; so in C89 not adding a stdio.h include and not having a visible prototype (for printf example) is undefined behavior.
For professional development, no.
For codegolfing, it is ok.
If you don't declare a function, the compiler automatically generates one, which may or may not match its real declaration. If it doesn't, it may or may not produce segfault or a software bug. gcc also gives in this case a warning.
No and Yes
stdio.h has an explicit declaration of the functions you want to use, such things are prohibited if it was a C++ compiler (g++ for example).
Since c++ requires explicit declarations of all functions, but any proper C compiler will create an implicit declaration of those functions, compile the code into object file, and when linked with the standard library, it will find a definition of those functions that accidentally will match the implicit declaration, probably gcc will give you a warning.
So if you are writing software that you want to be maintainable and readable, that's not an option to drop it, however for fast prototyping or code challenges, this might not be that important.
Technically you can skip #include in many cases. But for some functions the compiler cannot generate correct function call without prototype. E.g. if a parameter is double and you put 0 - with prototype it will be converted and stored as double value in stack and otherwise there will be int which will produce wrong calculations.
I have C code with lots of calls strcmp and strcpy that is causing all kinds of problems.
I want to migrate this to strncmp and strncpy but I can not update all the code right now. I want to add compiler warning where ever the functions is used.
The following forces the substitution #define strcmp(x,y) strncmp16(x,y,64) but the problem is still in the code.
Is there a way to add an #warning so that the code still compile but will give a warning for not using the sized functions.
It is a large code base and must compile in four different compilers (GCC, IAR, GHS and VC). It is our own C Library mainly used in embedded systems.
Edit: I am not looking to find all occurrences. There is thousands of tools that can be used to find and replace them. I want there to be a warning so the next time somebody looks at the code they would evaluate and fix the code.
Edit: Strncmp & strncpy have lots of issues and I am very aware of that. I am making an informed decision. These function is in our own C library not just the default functions from the compilers C library.
While you can use #define to force errors, there is no mechanism in the C99 standard (and probably none in C11 either) to force a warning.
If you are using gcc, you can use
__attribute_deprecated__
to mark a prototype as deprecated, e.g.:
int strcmp(const char *, const char *) __attribute_deprecated__;
For Visual Studio:
prefix the function prototype with __declspec(deprecated) as seen in MSDN
You'll need to raise the warning level to 3+.
Example:
#pragma deprecated(strcpy, strcmp)
This line will cause every call to either function to omit a C4995 warning.
These specific functions already emit a C4996 warning but you turn that warning off via a pragma:
#pragma warning(disable: 4996)
C function malloc() is defined under stdlib.h.
It should give an error if we don't include this file, but this code works fine with a little warning.
My question is, if malloc() works without this header file, then why do we need to include it? Please help clarify my concepts.
# include <stdio.h>
int main()
{
int a, b, *p;
p = (int*)malloc(sizeof(int)*5);
for(a=0;a<5;a++)p[a]=a*9;
for(b=0;b<5;b++)printf("%d ",p[b]);
}
In C unfortunately you don't need pre-declaration for functions. If the compiler encounters with a new function it will create an implicit declaration for it ("mmm`kay, this how it is used so I will assume that the type of the arguments are..").
Do not rely on this "feature" and in general do not write code that compiles with warnings.
Read the warning. It says it's invalid. The compiler is simply too kind to you. In Clang this works, but it might not in other compilers.
At least include it to suppress the warning. Unnecessary warnings are annoying. Any program should compile with warnings treated as errors (I always enable that).
It appears that that's your compiler's magic. Not including the necessary headers may work on your compiler (which I suppose is by Microsoft), but it won't necessarily compile elsewhere(that includes future versions of the same compiler). Write standard-conforming, portable code.
stdlib.h is of the general purpose standard header which includes functions of Dynamic Memory allocation and other Standard Functions.
For example if you want to display a message at the end of the execution of your program you will need to go for the getch() function,this functions reads a character from keyboard thus giving user the time to read the displayed Information.
The getch() function requires the stdlib header to be Included.
Like many things in c the reason that an error isn't generated when there is no prototype is for historical reasons. In the early days people often didn't bother prototyping functions because pointers and integers were usually the same size and integral types smaller than an integer were promoted to an integer when passed as a parameter (and floating point was rarely used for systems programming).
If at any point they had changed the compiler to give an error if a function was not prototyped then it would have broken many programs and would not have gained widespread acceptance.
With 64 bit addressing we are now entering a period when integers and pointers are not the same size and programs will most likely break if you do not prototype functions like malloc() that return a pointer.
In gcc always set the following options for your own programs: -Werror -Wstrict-prototypes
I am currently learning and experimenting with C and am using Bloodshed's DEV-C++ as an IDE.
Now, I just realized that the following piece of code (as it is...no includes or nothing) compiles and runs :
main ()
{
printf("%d", strlen("hello"));
}
Now, if I'm not mistaken, shouldn't two header files be included in this source for it to work ? stdio.h and string.h...but as you can see, I did not add them and the code still compiled and ran successfully.
My complaint is that I want the compiler to be "strict" because since I'm still learning C, I don't want the code to run if normally it shouldn't.
So, is there any way to prevent Dev-C++ from 'correcting my mistakes' when it comes to includes, ie making it more kinda "strict" ?
C90 had a feature (absent of C99 and C++) called implicit function declaration: when you used a name not declared yet in a function call, the compiler behaved as if
extern int identifier();
had been seen. That feature has been dropped from C99 and most compilers had option to warn about this even before C99 was promulgated.
Even when staying in C90, it is not recommended style to use this. If you have to maintain code making use of this and can't add prototypes, check that:
the functions returns an int (it is the case for printf but the validity is implementation dependent for strlen which returns a size_t which can be int or something else)
the function isn't variadic (it is the case for strlen but not printf)
the type of the arguments is not modified by default argument promotions (char, short, float are) and you must pay attention to cast pointers to void* when needed when the expected type is void*, you have to pay attention to cast NULL to the correct pointer type. (These are the same things you have to pay attention for variadic arguments BTW).
If those conditions aren't met -- and they aren't for any calls in your code -- you enter in the realm of undefined behavior.
I don't know if this actually is a DevC++ issue, but in any case you should consider ditching it. It is no longer being developed and is very buggy. I recommend changing to Code::Blocks, which is better in every way and alows you to use the very latest GCC compiler.
One of the possibilities for 'undefined behaviour' - which you get if you call a variadic function without a visible prototype - is that your code compiles and runs successfully.
If you're using gcc as the underlying compiler then you should be able to pass flags such as -std=c89 -pedantic -Wall -Wextra and get warnings about code such as the snippet that you've posted.