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 ...
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 ...
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 ...
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.
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 ...
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.
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 ...
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 - ...
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 ...
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 ...
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 #! ...
So you had a cow, but you inadvertently converted it to hamburger, and now you want your cow back.
Sorry, it just doesn't work that way.
Simply restore the source file from your backups.
Ah, you didn't have backups. Unfortunately, the universe doens't give you a break for that.
You can decompile the binary. That won't give you your source code, but it'll ...
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 ...
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
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 ...
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() ...
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 ...
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 ...
(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 ...
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.
If you know the definition of the data type you want you can use getconf to find these values out on most Unix systems.
$ getconf CHAR_BIT
The list of variables is defined in the man page man limits.h as well as here, man sysconf, in addition to being on disk. You can use locate limits.h to find it, it's often here: /usr/include/linux/limits.h.
It does not affect the fork in any way.
In the first case, you end up with 8 processes with nothing to write, because the output buffer was emptied already (due to the \n).
In the second case you still have 8 processes, each one with a buffer containing "Hello world..." and the buffer is written at process end.
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 ...