CSAPP | My solution of labs with CSAPP

const char m declares m to be a single character.

The initializer "mnopq" is a string literal. When used to initialize a variable other than a char array, it's converted to the address of its first character.

So this is initializing the character m to contain an address. But char only contains 1 byte, while addresses are likely 4 or 8 bytes. So most of the bytes of the address are being discarded when initializing m.

When you then cast this to byte_pointer, this 1-byte address is expanded 4 or 8 bytes. This will be very low-numbered addresses, which is probably reserved by the operating system. So you get a segmentation violation.

The issue with the dots is a buffering issue.

When stdout is connected to an interactive terminal (i.e. a shell) the it's by default line buffered, meaning that the output is actually written (flushed) on newline.

Since you print

The solution is to relinquish control of the tty to the other process group using tcsetpgrp, and when the child is done, take back the control of the tty using tcsetpgrp again. Note that tcsetpgrp sends SIGTTOU to its caller if the calling process belongs to a background process group, so SIGTTOU and SIGTTIN must be blocked.

Direct access to the Tcl_Interp struct has for long been deprecated. Given that this is a single source file (psim.c), you might want to patch it to properly use:

• Tcl_SetResult(), for example: Change interp->result = "No arguments allowed"; to Tcl_SetResult(interp, "No arguments allowed", TCL_STATIC);
• Tcl_GetStringResult(), for example: Change fprintf(stderr, "Error Message was '%s'\n", sim_interp->result); to fprintf(stderr, "Error Message was '%s'\n", Tcl_GetStringResult(sim_interp));

This is backwards compatible.

Not recommended, but doable: Set the macro

Assuming an int is 32 bit, the constant 0x80000000 is outside the range of an int and has type unsigned int. When used to initialize an int it is converted in an implementation defined manner. For gcc, that conversion results in x having the value -2³¹ (whose representation happens to be 0x80000000) which is the smallest value it can hold.

Then when you attempt to calcuate x-1, it causes signed integer overflow which is undefined behavior. As an example of this, if I compile this code under gcc 4.8.5 with -O0 or -O1 I get "False" as output, and if I compile with -O2 or -O3 it outputs "True".

One way to deal with this is to turn off the printf when your return is called recursively:

When you run gcc thatfile.c, this compiles your C code. This creates another file, normally called a.out, which you have to execute. You can do this by ./a.out.

The scale of float…

The scale is irrelevant. The number of digits used in the significand matters.

A floating-point representation of a number has the form ±d.ddd…ddd•b^e, where b is a fixed base, e is an exponent that scales the number, and d.ddd…ddd is a numeral in base b with a fixed number of digits.

In the format commonly used for float, b is 2 and d.ddd…ddd has 24 digits (which are bits because the numeral is in base 2).

In this format, 1e20 cannot be represented, because it would be +1.0101101011110001110101111000101101011000110001•2⁶⁶, and that has 51 bits. When you write float f = 1.0e20; in source code, f typically ends up with the value +1.01011010111100011101100•2⁶⁶, which has been rounded to 24 bits. (In decimal, this is 100000002004087734272.)

When you add one to this using real-number arithmetic, the result would be +1.010110101111000111011000000000000000000000000000000000000000000001•2⁶⁶, which again has too many bits. So the result is rounded. In float, this produces +1.01011010111100011101100•2⁶⁶, which is the same value f started with. However, you used f + d, which uses a double, so f is also converted to double, and double arithmetic is used for the multiplication. But, even in double, +1.010110101111000111011000000000000000000000000000000000000000000001•2⁶⁶ has too many bits. The format commonly used for double has 53 bits in the d.ddd…ddd part. So it is also rounded, to +1.01011010111100011101100000000000000000000000000000000•2⁶⁶, which is the same value as +1.01011010111100011101100•2⁶⁶.

Once a child process calls execve(), the child's (usually short-lived) initial address space is freed/released and replaced with space for the specified executable image; now the child no longer has a copy or access to the parent's data or text, like signal handlers.

Now consider a process-group associated with the control-terminal (tty). When a user types a CTRL-C (or CTRL-\ or CTRL-Z), the tty driver posts a signal to 1+ processes as members of the associated process-group. The result of delivering a signal would be the system default action unless a process established a different signal disposition (signal(), sigaction(), or related).

The posted code excerpt indicates a relayed event: user types a CTRL-C, tty driver posts a SIGINT to the shell, shell's handler looks for a foreground job, calls kill() with a negative pid to post a signal to members of that process-group.

For related info see these man pages: