It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I am searching for some information.
I have seen in many programmes following files included
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>
I want to know more what the above header files are used for i.e. in which conditions which header file is used.
Any link which clearly mentions which header file serves what purpose that will be great.
sys/types.h: "data types"
sys/socket.h: "main sockets header"
sys/un.h: "definitions for UNIX domain sockets"
unistd.h: "standard symbolic constants and types"
Header files are used for declaring items that are defined in some existing library.
If you want to use socket(), you'll need to include sys/types.h and sys/socket.h. If you want to use atan(), you'll need to include math.h. If you want to use printf(), you'll need to include stdio.h.
Knowing which header file is needed for a function is given in its documentation (man printf on Unix/Linux).
Knowing which function can be used for solving a problem is given by experience, stackoverflow and Google.
If you want to know what's in a header file, try looking at it, seriously: most will start with some comment describing the content if it's not obvious anyway.
If you want to know what part of a header file is being used by the program that's including, try removing it and looking at the error messages. That may also sound glib, but sadly there's generally not a better way to find this out. But, it may be that on one platform some functionality requires including two headers, whereas on some other platform only one of them is required (perhaps because the second header is indirectly picked up by some earlier include anyway): if you test on the platform where one header is needed and decide to remove the second include, you may break the build on the other platform. So, when you find stuff that is needed, consult the man pages for the required headers - they may be specified by some Standard that both platforms honour.
If you want to know which header files to use yourself, then again - you have to look at the documentation for the functions you need to call. Even then, as a C++ programmer you should prefer the C++ versions of certain C headers, and standard documentation tools like man - given the C function name - won't tell you about the C++ headers. Have a read of e.g. http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt01ch03s02.html - it's GCC documentation but describes C++ Standard requirements for these headers.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm trying to understand the Linux kernel, so I'm reading Linux kernel source. So how can I determine where a header file located, because there are many header files have the same name but locate in different directories?
Example: they include fcntl.h in fs/open.c
I can find fcntl.h in 17 different directories
arch/alpha/include/asm/fcntl.h
arch/arm/include/asm/fcntl.h
....
Generally, it's going to depend on the way the file was included. If included with quotes like this:
#include "QuotedHeader.h"
It should be in the same directory. (It can also be in the "include" directories.)
If included with angle brackets like this:
#include <BracketedHeader.h>
It's located in an "include" directory. These are directories that the compiler is told at compile-time to search in for header files. These can be passed as parameters, or set in an environment variable.
For the examples provided, the directories make it clear why there are duplicates: generally, different architecture-specific files are separated by folders named for different architectures.
In the example provided, you're looking at different fcntl.h files for the Alpha and ARM architectures. The file your compiler will use depends on the CPU being compiled for, and the compiler will be told which to use during compile time.
In my personal opinion, if you don't already know this, you may be starting in the wrong place to understand the linux kernel. Try first researching C
You could add preprocessor options to the CFLAGS governing the compilation of your kernel module. In particular, the -H option (passed to gcc) displays the path of each #include-d header, and -I option augments the list of searched include directories.
Look up the name of the header file in the man pages...or google it.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
What is the correct way to name files and functions that are part of a C based code library/API?
What you can (but should not) do is be completely careless and use no systematic naming conventions at all. This 'works', but makes life uncomfortable for your customers; they have no easy way of knowing which names they can use in their own program. (I came across a library which defined a undocumented function for its internal use that was called error(). The name didn't match any part of the external documented namespaces. At the time, one of my own standard error reporting functions was also called error() — though it is now err_error(); that meant I couldn't use my own standard error reporting functions with that library. The upshot was I didn't use that library if I didn't have to; it was too much of a nuisance to use.)
So, you shouldn't be like that. You should be careful in the names you expose.
Your public header should use one (or a very few) systematic prefixes, which are documented. Typically, you'd choose a prefix such as PFX, and use that:
enumeration constants start PFX_.
macros start PFX_.
functions start pfx_.
global variables (you don't have any of those, do you) start pfx_.
type names and structure or union tags start pfx_.
Your private variables and functions that are visible outside their own source file have a systematic prefix (possibly pfx_ again, or maybe pfxp_ where the last p is for private, or perhaps pfx[A-Z] so that private names are camel-cased but start with pfx).
Only variables or functions that are strictly file scope (no external linkage) are not constrained by these rules, but even then, it is advisable to use the naming convention (so if a function needs to be used by two files later, you don't have to revise the calls in the code where the function was previously static).
This way, you can simply document that names starting PFX_ or pfx_ are reserved by your library. Users can still use names with the same prefix (you can't stop them), but they do so at their own risk because upgrades to the library might add names that are reserved. They can keep well clear of your names because you've documented them, and because the documentation is (relatively) easy to understand.
Note that the C standard and the POSIX standards both lay down rules for reserved names. However, the rules for the reserved POSIX and C names are considerably more complex than just a single prefix. They're also sweeping. For example, POSIX reserves all names ending _t for use as type names if any POSIX header is included.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
Every program written in C that I've ever seen #includes <stdlib.h>, at least indirectly. You can't really do much useful without it.
Why aren't its functions just part of "standard C"?
Why should I have to #include <stdlib.h> before malloc()ing something?
C is a minimalistic language. There are no built-in functions.
The C language was designed, from the start, to be used both in ordinary applications (running in a 'hosted environment') and OS kernels (and other specialized environments, running in a 'freestanding environment'). In the latter, ordinary C library functions like malloc() may be unavailable.
In order to allow the same compiler to be used for both hosted and freestanding environments, library functions are not hardcoded into the compiler, but rather are placed into header files loaded by the compiler - such as stdlib.h. OS kernels and other specialized programs do not (and cannot) include these standard headers.
Not all programs need to call malloc(). And those that do need dynamic memory allocation may prefer to do it a different way. C does not try to force a single way of working on programmers.
This is still a perfectly valid program that doesn't require libc and can do much stuff apart from interfacing with the underlying operating system:
int main (void) {
int x = 2;
int y = 3;
return x + y;
}
One reason I can think of is that by putting the stdlib functions into a library, they exist in their own namespace, making it easier to overload them.
It might sound a little crazy to think of overloading malloc, but it's one way to implement a resource buffering system that might be used for say... dynamically creating game objects during a game loop without triggering allocations. You can preallocate a buffer, then overload malloc to create the objects into the buffer rather than allocating new memory for them.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
Is there a way to have a C source file print to the screen without including <stdio.h>?
Here's my situation: I was asked to programatically handle 1000 C source files that will each implements several numerical functions in C (these functions are supposed to work on data that is in memory, eithout any I/O). The origin of these source files in unclear, and hence, I'd like to make sure there will be no harm to my machine when I compile & run these source files.
Is there a way to find out if a C source file is potentially harmful? I thought of asking the developers to avoid any #include statements whatsoever, but I do need just printf -- as I'd like them to include an output of their calculations within main().
Any ideas?
Sure, add the prototype for printf at the top of your source file, as long as you're linking to the CRT libraries you can use the function without including stdio.h
printf prototype
int printf ( const char * format, ... );
There are, though they are probably a bit larger than the scope of the format of SO. In essence you leverage assembler calls in C. The blog KSplice touches on the subject ( with code and examples ) here.
Is there a way to find out if a C source file is potentially harmful?
No, there is none. A malicious source file could possibly do anything it wanted by defining its own prototypes, or by using inline assembly -- #include is just a compile-time convenience.
I would like to clarify why we need printf and studio.h to maybe make the concept more clear. C is a portable language. You can compile c for Linux, Mac OSX, Windows. In each, causing output normally boils down to a system call, or in embedded systems, dealing directly with a frame buffer or Uart device.
So of course it is possible, do you want to do it? Depends why. If you are coding against a specific platform and dont have printf(), then you may have to look into invoking a system call directly for that platform/writing some platform specific assembly code. It all depends on your use case.
Sure, put the necessary function prototypes in your program.
If you mean by not using printf, then you have several options - you can use fwrite, or you could dispense with streams and use write, or you could invoke operating system I/O services directly, or perhaps you could talk to the display hardware directly, or many other things.
If you want a better answer, perhaps explain why you want to not include stdio.h
This is silly but still:
#include <string.h>
int main() {
puts ("hi");
return 0;
}
and Output:
$ gcc -o try try.c
$ ./try
hi
This question already has answers here:
Should I use #include in headers?
(9 answers)
Closed 7 years ago.
"C Interfaces and Implementations" shows some interesting usage patterns for data structures, but I am sure there are others out there.
http://www.amazon.com/Interfaces-Implementations-Techniques-Addison-Wesley-Professional/dp/0201498413
Look at the Goddard Space Flight Center (NASA) C coding standard (at this URL). It has some good and interesting guidelines.
One specific guideline, which I've adopted for my own code, is that headers should be self-contained. That is, you should be able to write:
#include "header.h"
and the code should compile correctly, with any other necessary headers included, regardless of what has gone before. The simple way to ensure this is to include the header in the implementation source -- as the first header. If that compiles, the header is self-contained. If it doesn't compile, fix things so that it does. Of course, this also requires you to ensure that headers are idempotent - work the same regardless of how often they are included. There's a standard idiom for that, too:
#ifndef HEADER_H_INCLUDED
#define HEADER_H_INCLUDED
...operational body of header.h...
#endif /* HEADER_H_INCLUDED */
It is imperative, of course, to have the #define at the top of the file, not at the bottom. Otherwise, if a header included by this also includes header.h, then you end up with an infinite loop - not healthy. Even if you decide to go with a strategy of:
#ifndef HEADER_H_INCLUDED
#include "header.h"
#endif /* HEADER_H_INCLUDED */
in the code that include the header - a practice which is not recommended - it is important to include the guards in the header itself too.
Update 2011-05-01
The GSFC URL above no longer works. You can find more information in the answers for the question Should I use #include in headers, which also contains a cross-reference to this question.
Update 2012-03-24
The referenced NASA C coding standard can be accessed and downloaded via the Internet archive:
http://web.archive.org/web/20090412090730/http://software.gsfc.nasa.gov/assetsbytype.cfm?TypeAsset=Standard
Makeheaders is an interesting approach: use a tool to generate the headers. Makeheaders is used in D. R. Hipp's cvstrac and fossil.
You might want to take a look at Large-Scale C++ Software Design by John Lakos.