If I use malloc in my code:
int *x = malloc(sizeof(int));
I get this warning from gcc:
new.c:7: warning: implicit declaration of function ‘malloc’
new.c:7: warning: incompatible implicit declaration of built-in function ‘malloc’
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*).
You haven't done #include <stdlib.h>.
You need to include the header file that declares the function, for example:
#include <stdlib.h>
If you don't include this header file, the function is not known to the compiler. So it sees it as undeclared.
Make a habit of looking your functions up in help.
Most help for C is modelled on the unix manual pages.
Using :
man malloc
gives pretty useful results.
Googling man malloc will show you what I mean.
In unix you also get apropos for things that are related.
Beside the other very good answers, I would like to do a little nitpick and cover something what is not discussed yet in the other answers.
When you are at Linux, To use malloc() in your code,
You don´t actually have to #include <stdlib.h>.
(Although the use of stdlib.h is very common and probably every non-toy-program should include it either way because it provides a wide range of useful C standard library functions and macros)
You could also #include <malloc.h> instead.
But please note that the use of malloc.h is deprecated and it makes your code non-portable. If you want to use malloc() you should always and ever (except for explicit reasons to do otherwise) #include <stdlib.h>.
The reasons why, are best explained in the answers to this question:
difference between <stdlib.h> and <malloc.h>
Related
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 had an interview question where the interviewer asked me what error would we get from the below output:
int main()
{
printf("hello world");
return 0;
}
#include <stdio.h>
I answered "no error" and it will display the output.
can anyone help me with this???
Please note"the missing angular brackets is intentionally done by me so dont bother about that"
It depends on the compiler.
Most C compilers will probably accept that code (perhaps with a warning) and produce an executable that prints the expected output.
Under C90 rules, the behavior of the printf call is undefined; it's invalid to call a variadic function with no visible prototype. Variadic functions can have a different calling convention from ordinary functions, and you have to let the compiler know that printf is variadic so it can generate correct code for the call.
Under C99 and later rules, calling any function with no visible declaration (which may or may not be a prototype) is a constraint violation, requiring at least a compile-time warning.
The standard doesn't hint at what happens if you call printf without the required prototype, but in practice most compilers will handle it "correctly".
The missing '\n' at the end of the output means that the program's behavior is undefined if the implementation requires a newline at the end of the output; whether that's required or not is implementation-defined. In any case, adding a newline is a good idea.
The #include <stdio.h> at the end of the source file should be useless but harmless.
I'm assuming that the source file actually contains #include <stdio.h> and not #include stdio.h; the latter would be a syntax error.
(Practically speaking, of course, the #include <stdio.h> should be at the top. In a professional setting, the output is irrelevant, since the program will never survive a code review.)
You will get an error for missing quotes or <> in the filename for the #include. It should be:
#include <stdio.h>
Apart from that, it should compile with a warning about an implicit declaration to printf(). On Clang, it gives me:
test.c:3:5: warning: implicitly declaring library function 'printf' with type 'int (const char *, ...)'
printf("hello world");
^
When your main() function is being declared, the compiler will run into the first line of main() and it will have no idea what printf() is. You will get an error about the compiler complaining about an undeclared function.
Assuming, of course, the missing < and > was a mistake introduced when you copied your question over.
There are two errors here. The first is that the include directive must happen before the code that requires that header information, in this case printf() is declared in stdio.h, and the second is that the filename in the include directive must be enclosed in angle brackets, <>, or quotes, "".
I was able to run code that uses the randomize function without including the time.h library. is it automatically included with some other libraries i might have already included in my code? Below is a list of the libraries I included:
#include <graphics.h>
#include <stdlib.h>
#include <stdio.h>
#include <conio.h>
#include <dos.h>
#include <string.h>
#include <io.h>
This is very very specific to the version and implementation of your library. The standard doesn't force any header to include time.h 1 so you cannot rely on that.
In your case, it could be that one of dos.h, io.h, conio.h for example has included time.h (or any other of the headers there for all it's worth).
1 At least not the ones there and not likely in your seemingly ancient library. C11 says threads.h should include time.h
What does <compiler with high warning level> yourcode.c say? My guess would be:
either one of the non-standard DOS-specific headers (conio.h, dos.h, io.h, ...) includes it,
or there's no declaration at all, i. e. it's not included, in which case your compiler silently and implicitly assumes a function signature (specifically, it assumes a return value of int and whatever type of argument you call it with for the first time).
Note that the latter case is wrong, and you should pay attention not to do it (since it may lead your program invoking undefined behavior). Always compile with all warnings enabled so you can track down such an error.
When C compiler can't find a prototype to a function it assumes it is a function that returns int. It also prints a warning function if you didn't change the default settings.
So. In your case perhaps time.h was included, but be aware that it can cause a lot of problems if it wasn't.
When I use malloc in a C program, I get a warning:
warning: incompatible implicit declaration of built-in function 'malloc' [enabled by default]
I can then include <malloc.h> or <stdlib.h> to get rid of the warning although it works without it as well.
So I was wondering, what's the difference between these headers and which one does gcc links when I don't include anything?
(I'm using ubuntu 12.04 64-bit with gcc 4.6.3)
The <malloc.h> header is deprecated (and quite Linux specific, on which it defines non-standard functions like mallinfo(3)). Use <stdlib.h> instead if you simply need malloc(3) and related standard functions (e.g. free, calloc, realloc ....). Notice that <stdlib.h> is defined by C89 (and later) standards, but not <malloc.h>
Look into /usr/include/malloc.h you'll find there some non-standard functions (e.g. malloc_stats(3), etc...) - in addition of malloc....
And gcc don't link header files, but libraries. Read Levine's book about linkers & loaders for more.
If you don't include any headers (and dont explicitly declare malloc yourself, which would be a bad idea), malloc is implicitly declared as returning some int value (which is wrong). I do invite you to pass at least the -Wall flag to gcc when using it.
You might also pass -v to gcc to understand the actual programs involved: cc1 is the compiler proper (producing assembly code), as the assembler, ld the linker, and collect2 an internal utility which invokes the linker.
stdlib.h is a standard C header that declares among other things the malloc(), calloc(), free() functions. This is the header you should include.
malloc.h is a non-standard header, found on many systems where it often defines additional functions specific to the malloc implementation used by that platform.
If you do not include any of these, there's no default, however if you call malloc() without a prior declaration of the malloc function, C will assume the function prototype is int malloc();, which is often wrong. In addition to the headers, C compilers typically link to a standard library, e.g. glibc on Linux, where the implementation of malloc resides.
Note that there's a difference between header files and libraries. Header files declare things, like structs and function prototypes. Libraries contain the implementation, the compiled code. You link to library, and you #include header files.
The headers declare different sets of functions, but both forward-declare malloc.
If you don't include either of them then you don't have a prototype for malloc, hence the warning. But you link against the same function regardless, because there is only one malloc function. It's just forward-declared in two places. The forward-declarations aren't there to help link against the malloc function, they're there so that the compiler can emit the correct code around the call, to specify the arguments and read the return value.
Note that <malloc.h> is not a standard include. I don't think stdlib.h ever includes malloc.h on GCC, but you can imagine that it might since that's one way to provide the necessary declaration.
<malloc.h> is not a standard header and is thus not portable. The standard puts malloc() et al. in <stdlib.h>.
Others have already discussed the differences between <malloc.h> and <stdlib.h>
As for the warning when neither is included, that is the definition of how C functions work. A function without a prototype (which is what you have when you don't declare your own and don't include a header with one) is treated as a function with an int return type and an unspecified argument list.
The compiler will perform default promotions (e.g. float to double and others) and the function is called. If the number of arguments used by the function is different from the number passed, or if the argument types after default promotions are not compatible with the function's implementation, it is undefined behavior.
See ISO 9899:1999 (C99) §6.5.2.2, ¶ 6:
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.
In the case of calling malloc() without a prototype, this has the potential to be very bad. malloc() accepts a size_t argument and returns a void * pointer. If the result of default promotion of your integer argument produces an integer different in size from size_t, you will have undefined behavior. And if int is a different size from void * (e.g. on 64-bit systems, where int is often 32-bits and void * will be 64-bits,) the returned pointer will be messed up.
To learn the difference, you should read their contents for yourself.
By default, gcc reads neither.
When you read them, you will see that they declare malloc differently.
I'm looking at example abo3.c from Insecure Programming and I'm not grokking the casting in the example below. Could someone enlighten me?
int main(int argv,char **argc)
{
extern system,puts;
void (*fn)(char*)=(void(*)(char*))&system;
char buf[256];
fn=(void(*)(char*))&puts;
strcpy(buf,argc[1]);
fn(argc[2]);
exit(1);
}
So - what's with the casting for system and puts? They both return an int so why cast it to void?
I'd really appreciate an explanation of the whole program to put it in perspective.
[EDIT]
Thank you both for your input!
Jonathan Leffler, there is actually a reason for the code to be 'bad'. It's supposed to be exploitable, overflowing buffers and function pointers etc. mishou.org has a blog post on how to exploit the above code. A lot of it is still above my head.
bta, I gather from the above blog post that casting system would somehow prevent the linker from removing it.
One thing that is not immediately clear is that the system and puts addresses are both written to the same location, I think that might be what gera is talking about “so the linker doesn’t remove it”.
While we are on the subject of function pointers, I'd like to ask a follow-up question now that the syntax is clearer. I was looking at some more advanced examples using function pointers and stumbled upon this abomination, taken from a site hosting shellcode.
#include <stdio.h>
char shellcode[] = "some shellcode";
int main(void)
{
fprintf(stdout,"Length: %d\n",strlen(shellcode));
(*(void(*)()) shellcode)();
}
So the array is getting cast to a function returning void, referenced and called? That just looks nasty - so what's the purpose of the above code?
[/EDIT]
Original question
User bta has given a correct explanation of the cast - and commented on the infelicity of casting system.
I'm going to add:
The extern line is at best weird. It is erroneous under strict C99 because there is no type, which makes it invalid; under C89, the type will be assumed to be int. The line says 'there is an externally defined integer called system, and another called puts', which is not correct - there are a pair of functions with those names. The code may actually 'work' because the linker might associate the functions with the supposed integers. But it is not safe for a 64-bit machine where pointers are not the same size as int. Of course, the code should include the correct headers (<stdio.h> for puts() and <stdlib.h> for system() and exit(), and <string.h> for strcpy()).
The exit(1); is bad on two separate counts.
It indicates failure - unconditionally. You exit with 0 or EXIT_SUCCESS to indicate success.
In my view, it is better to use return at the end of main() than exit(). Not everyone necessarily agrees with me, but I do not like to see exit() as the last line of main(). About the only excuse for it is to avoid problems from other bad practices, such as functions registered with atexit() that depend on the continued existence of local variables defined in main().
/usr/bin/gcc -g -std=c99 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -c nasty.c
nasty.c: In function ‘main’:
nasty.c:3: warning: type defaults to ‘int’ in declaration of ‘system’
nasty.c:3: warning: type defaults to ‘int’ in declaration of ‘puts’
nasty.c:3: warning: built-in function ‘puts’ declared as non-function
nasty.c:8: warning: implicit declaration of function ‘strcpy’
nasty.c:8: warning: incompatible implicit declaration of built-in function ‘strcpy’
nasty.c:10: warning: implicit declaration of function ‘exit’
nasty.c:10: warning: incompatible implicit declaration of built-in function ‘exit’
nasty.c: At top level:
nasty.c:1: warning: unused parameter ‘argv’
Not good code! I worry about a source of information that contains such code and doesn't explain all the awfulness (because the only excuse for showing such messy code is to dissect it and correct it).
There's another weirdness in the code:
int main(int argv,char **argc)
That is 'correct' (it will work) but 100% aconventional. The normal declaration is:
int main(int argc, char **argv)
The names are short for 'argument count' and 'argument vector', and using argc as the name for the vector (array) of strings is abnormal and downright confusing.
Having visited the site referenced, you can see that it is going through a set of graduated examples. I'm not sure whether the author simply has a blind spot on the argc/argv issue or is deliberately messing around ('abo1' suggests that he is playing, but it is not helpful in my view). The examples are supposed to feed your mind, but there isn't much explanation of what they do. I don't think I could recommend the site.
Extension question
What's the cast in this code doing?
#include <stdio.h>
char shellcode[] = "some shellcode";
int main(void)
{
fprintf(stdout,"Length: %d\n",strlen(shellcode));
(*(void(*)()) shellcode)();
}
This takes the address of the string 'shellcode' and treats it as a pointer to a function that takes an indeterminate set of arguments and returns no values and executes it with no arguments. The string contains the binary assembler code for some exploit - usually running the shell - and the objective of the intruder is to get a root-privileged program to execute their shellcode and give them a command prompt, with root privileges. From there, the system is theirs to own. For practicing, the first step is to get a non-root program to execute the shellcode, of course.
Reviewing the analysis
The analysis at Mishou's web site is not as authoritative as I'd like:
One, this code uses the extern keyword in the C language to make the system and puts functions available. What this does (I think) is basically references directly the location of a function defined in the (implied) header files…I get the impression that GDB is auto-magically including the header files stdlib.h for system and stdio.h for puts. One thing that is not immediately clear is that the system and puts addresses are both written to the same location, I think that might be what gera is talking about “so the linker doesn’t remove it”.
Dissecting the commentary:
The first sentence isn't very accurate; it tells the compiler that the symbols system and puts are defined (as integers) somewhere else. When the code is linked, the address of puts()-the-function is known; the code will treat it as an integer variable, but the address of the integer variable is, in fact, the address of the function - so the cast forces the compiler to treat it as a function pointer after all.
The second sentence is not fully accurate; the linker resolves the addresses of the external 'variables' via the function symbols system() and puts() in the C library.
GDB has nothing whatsoever to do the compilation or linking process.
The last sentence does not make any sense at all. The addresses only get written to the same location because you have an initialization and an assignment to the same variable.
This didn't motivate me to read the whole article, it must be said. Due diligence forces me onwards; the explanation afterwards is better, though still not as clear as I think it could be. But the operation of overflowing the buffer with an overlong but carefully crafted argument string is the core of the operation. The code mentions both puts() and system() so that when run in non-exploit mode, the puts() function is a known symbol (otherwise, you'd have to use dlopen() to find its address), and so that when run in exploit mode, the code has the symbol system() available for direct use. Unused external references are not made available in the executable - a good thing when you realize how many symbols there are in a typical system header compared with the number used by a program that includes the header.
There are some neat tricks shown - though the implementation of those tricks is not shown on the specific page; I assume (without having verified it) that the information for getenvaddr program is available.
The abo3.c code can be written as:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, char **argv)
{
void (*fn)(char*) = (void(*)(char*))system;
char buf[256];
fn = (void(*)(char*))puts;
strcpy(buf, argv[1]);
fn(argv[2]);
exit(1);
}
Now it compiles with only one warning with the fussy compilation options I originally used - and that's the accurate warning that 'argc' is not used. It is just as exploitable as the original; it is 'better' code though because it compiles cleanly. The indirections were unnecessary mystique, not a crucial part of making the code exploitable.
Both system and puts normally return int. The code is casting them to a pointer that returns void, presumably because they want to ignore whatever value is returned. This should be equivalent to using (void)fn(argc[2]); as the penultimate line if the cast didn't change the return type. Casting away the return type is sometimes done for callback functions, and this code snippet seems to be a simplistic example of a callback.
Why the cast for system if it is never used is beyond me. I'm assuming that there's more code that isn't shown here.