* administriva -- Brandon out next week; no review section * table driven programming overview ** goals -- what makes a good table driven design? 1. simplify the code by shifting "logic" into a data structure very minimal to zero duplicated code 2. makes modifications to support new settings trivial table update, no code update ** examples / ideas *** showtty uses separate table for each flag type minimizes repeated code with the args to show_flagset adding an new setting for a supported flag -- just add a row to the table adding a new flag type add a table with settings add one call to show_flagset adding support to modify settings 1. add a field to the table for the cli arg 2. search the tables for a matching cli arg from argv 3. use fl_value in the table to modify the flagset *** could we just use a single table? **** use function pointers to differentiate arg types void (*func)(type, type, type) <-- basically a standard function declaration but with (* ) around the name table.func(arg, arg, arg) **** create and enum of constants for arg types and add a field **** or maybe, just put a pointer to the flag value directly in the table declare the termios struct as a static global so you can reference the addresses in the table create the termios struct and table at function scope somewhere **** offsetof(struct termios, c_lflag) * review the termios struct ** mechanics each of the tcflag_t fields is a bit-array use bitwise operations to turn a setting on or off off: use the bitwise and operator with the bitwise complement ttyp->c_lflag &= ~table.fl_value on: use the bitwise or operator ttyp->c_lflag |= table.fl_value c_cc -- just change the value in the array; the constant is an array index ** how changing settings works 1. tcgetattr -- gets the current settings 2. change everything the user asks for 3. tcsetattr -- updates the settings to match the termios struct * display of control chars read Bruce's write about control char display do some investigation into ""