Summary: The primary reason for switching from GCC to Clang is the incompatibility of GCC's GPL v3 license with the goals of the FreeBSD project. There are also political issues to do with corporate investment, as well as user base requirements. Finally, there are expected technical advantages to do with standards compliance and ease of debugging. Real world ...
To begin with, note that argv is not necessarily the program name. It is what the caller puts into argv of the execve system call (e.g. see this question on Stack Overflow). (All other variants of exec are not system calls but interfaces to execve.)
Suppose, for instance, the following (using execl):
execl("/var/tmp/mybackdoor", "top", NULL);
When outputting to standard output using the C library's printf() function, the output is usually buffered. The buffer is not flushed until you output a newline, call fflush(stdout) or exit the program (not through calling _exit() though). The standard output stream is by default line-buffered in this way when it's connected to a TTY.
When you fork the ...
You can't just run ./fork.c. It's not a program; it's the source for a program. Using ./ assumes that the file is a script (which it isn't) and treats it accordingly.
However, as noted in another answer, there are compilers (like Tiny C Compiler) that can execute C code without explicitly compiling it.
Since it's a C program, you have to compile the ...
xxd has a mode for this. The -i/--include option will:
output in C include file style. A complete static array definition is written (named after the input file), unless xxd reads from stdin.
You can dump that into a file to be #included, and then just access foo like any other character array (or link it in). It also includes a declaration of the ...
Bash runs in POSIX mode when argv is sh. It runs as a login shell when argv begins with -.
Vim behaves differently when run as vi, view, evim, eview, ex, vimdiff, etc.
Busybox, as already mentioned.
In systems with systemd as init, shutdown, reboot, etc. are symlinks to systemctl.
and so on.
GNU/Linux systems usually use either glibc (Fedora/Redhat family, Arch) or its close cousin, eglibc (Debian/Ubuntu family); since eglibc is now being merged back into glibc (see EGLIBC 2.19 Branch Created under "News"), in the near future they will all be glibc again.
The easiest way to check the exact version is to ask ldd, which ships with the C library.
Use pkill -U UID or pkill -u UID or username instead of UID. Sometimes skill -u USERNAME may work, another tool is killall -u USERNAME.
Skill was a linux-specific and is now outdated, and pkill is more portable (Linux, Solaris, BSD).
pkill allow both numberic and symbolic UIDs, effective and real http://man7.org/linux/man-pages/man1/pkill.1.html
I think this part of the clone(2) man page may clear up the difference re. the PID:
CLONE_THREAD (since Linux 2.4.0-test8)
If CLONE_THREAD is set, the child is placed in the same thread
group as the calling process.
Thread groups were a feature added in Linux 2.4 to support the
POSIX threads notion of a ...
Actually, your virtual stack size is 8388608 bytes (8 MB). Of course, it's natural to conclude that this can't be right, because that's a ridiculously large amount of memory for every thread to consume for its stack when 99% of the time a couple of KB is probably all they need.
The good news is that your thread only uses the amount of physical memory that ...
One thing worth considering is that FreeBSD is currently using GCC 4.2.1 as noted in ire_and_curses answer thus the performance comparisons aren't of 4.5 or even 4.6 aren't truly relevant to the project. Therefore, the questions you should be asking are:
What are the performance gains of the new Clang vs the older GCC that the project uses?
How do the same ...
You are right, indeed "something must have changed between 2001 and now". The book you are reading describes the world according to the first historical implementation of POSIX threads on Linux, called LinuxThreads (see also Wikipedia article for some).
LinuxThreads had some compatibility issues with POSIX standard - for example threads not sharing PIDs - ...
There have been many discussions about this. Mainly, the reason is a philosophical one.
C was invented as a simple language for system development (not so much application development). There are many arguments for using C++, but there are about as many for not using C++ and sticking to C.
In the end, it's a historical issue. Most application stuff is ...
Historically, argv is just an array of pointers to the "words" of the commandline, so it makes sense to start with the first "word", which happens to be the name of the program.
And there's quite a few programs that behave differently according to which name is used to call them, so you can just create different links to them and get different "commands". ...
No, it doesn't, mainly for the reason that it doesn't require systems to conform by default, or to comply to only the POSIX standard (to the exclusion of any other standard).
For instance, Solaris (a certified compliant system) chose backward compatibility for its utilities in /bin, which explains why those behave in arcane ways, and provide POSIX-compliant ...
In the latest versions of gcc compiler require that libraries follow the object or source files.
So to compile this it should be:
gcc pthread_sample.c -lpthread
Normally though pthread code is compiled this way:
gcc -pthread pthread_sample.c
That's not a program, that's the source code for a program.
C is a compiled language, meaning it must be "compiled" into machine-readable instructions before you can run it. As you are using C, the "C Compiler" (cc) can do this.
cc -o fork for.c # compile the code
chmod +x fork # ensure it it executable
./fork # run the compiled program
In general, it’s not very different; there are lists of known pitfalls on the Hurd’s site and on the Debian wiki. Many projects build fine, or after a few fixes (the most common issue being the absence of PATH_MAX).
However in your case you’ll find it difficult to get anywhere: netfilter and iptables are specific to the Linux kernel, so you won’t be able to ...
You can use the program name to change the program behavior.
For example you could create some symlinks to the actual binary.
One famous example where this technique is used is the busybox project which installs only one single binary and many symlinks to it. (ls, cp, mv, etc). They are doing it to save storage space because their targets are ...
(Userspace) threads are not implemented as processes as such on Linux, in that that they do not have their own private address space, they still share the address space of the parent process.
However, these threads are implemented to use the kernel process accounting system, so are allocated their own Thread ID (TID), but are given the same PID and 'thread ...
What's happening in both cases is the same: to execute a file directly, the execute bit needs to be set, and the filesystem can't be mounted noexec. But these things don't stop anything from reading those files.
When the bash script is run as ./hello_world and the file isn't executable (either no exec permission bit, or noexec on the filesystem), the #! ...
System calls per se are a concept. They represent actions that processes can ask the kernel to perform.
Those system calls are implemented in the kernel of the UNIX-like system. This implementation (written in C, and in asm for small parts) actually performs the action in the system.
Then, processes use an interface to ask the system for the execution of ...
In addition to programs altering their behaviour depending on how they were called, I find argv useful in printing the usage of a program, like so:
printf("Usage: %s [arguments]\n", argv);
This causes the usage message to always use the name through which it was called. If the program is renamed, its usage message changes with it. It even includes ...
int pthread_attr_setstacksize(pthread_attr_t *attr, size_t stacksize);
The stacksize attribute shall define the minimum stack size (in
bytes) allocated for the created threads stack.
In your example, the stack size is set to 8388608 bytes which corresponds to 8MB, as returned by the command ulimit -s
So that matches.
From the pthread_create() ...
Even though GCC is GPLv3, the resulting binaries produced by GCC never had any license constraint. In clear you can use GCC to build software that falls under the license you want. Even the C library that comes with GCC and that is included in the binary is license-free. http://www.gnu.org/licenses/gcc-exception-faq.html
Section 2 of the GNU GPLv3:
There are several possibilities.
One method is to compile using
But a nicer strategy would be to have a Makefile and compile just using
Where the easiest Makefile would look like.
Others can explain this a lot better.
t_open() and its associated /dev/tcp and such are part of the TLI/XTI interface, which lost the battle for TCP/IP APIs to BSD sockets.
On Linux, there is a /dev/tcp of sorts. It isn't a real file or kernel device. It's something specially provided by Bash, and it exists only for redirections. This means that even if one were to create an in-kernel /dev/tcp ...