//: Addresses help us spend less time copying data around. //: So far we've been operating on primitives like numbers and characters, and //: we've started combining these primitives together into larger logical //: units (containers or arrays) that may contain many different primitives at //: once. Containers and arrays can grow quite large in complex programs, and //: we'd like some way to efficiently share them between recipes without //: constantly having to make copies. Right now 'next-ingredient' and 'return' //: copy data across recipe boundaries. To avoid copying large quantities of //: data around, we'll use *addresses*. An address is a bookmark to some //: arbitrary quantity of data (the *payload*). It's a primitive, so it's as //: efficient to copy as a number. To read or modify the payload 'pointed to' //: by an address, we'll perform a *lookup*. //: //: The notion of 'lookup' isn't an instruction like 'add' or 'subtract'. //: Instead it's an operation that can be performed when reading any of the //: ingredients of an instruction, and when writing to any of the products. To //: write to the payload of an ingredient rather than its value, simply add //: the /lookup property to it. Modern computers provide efficient support for //: addresses and lookups, making this a realistic feature. //: //: To recap: an address is a bookmark to some potentially large payload, and //: you can replace any ingredient or product with a lookup to an address of //: the appropriate type. But how do we get addresses to begin with? That //: requires a little more explanation. Once we introduce the notion of //: bookmarks to data, we have to think about the life cycle of a piece of //: data and its bookmarks (because remember, bookmarks can be copied around //: just like anything else). Otherwise several bad outcomes can result (and //: indeed *have* resulted in past languages like C): //: //: a) You can run out of memory if you don't have a way to reclaim //: data. //: b) If you allow data to be reclaimed, you have to be careful not to //: leave any stale addresses pointing at it. Otherwise your program might //: try to lookup such an address and find something unexpected. Such //: "memory corruption" problems can be very hard to track down, and they //: can also be exploited to break into your computer over the network, etc. //: //: To avoid these problems, we introduce the notion of a *reference count* or //: refcount. The life cycle of a bit of data accessed through addresses looks //: like this. //: //: We create space in computer memory for it using the 'new' instruction. //: The 'new' instruction takes a type as an ingredient, allocates //: sufficient space to hold that type, and returns an address (bookmark) //: to the allocated space. //: //: x:address:num <- new number:type //: //: +------------+ //: x -------> | number | //: +------------+ //: //: That isn't entirely accurate. Under the hood, 'new' allocates an extra //: number -- the refcount: //: //: +------------+------------+ //: x -------> | refcount | number | //: +------------+------------+ //: //: This probably seems like a waste of space. In practice it isn't worth //: allocating individual numbers and our payload will tend to be larger, //: so the picture would look more like this (zooming out a bit): //: //: +-------------------------+ //: +---+ | //: x -------> | r | | //: +---+ DATA | //: | | //: | | //: +-------------------------+ //: //: (Here 'r' denotes the refcount. It occupies a tiny amount of space //: compared to the payload.) //: //: Anyways, back to our example where the data is just a single number. //: After the call to 'new', Mu's map of memory looks like this: //: //: +---+------------+ //: x -------> | 1 | number | //: +---+------------+ //: //: The refcount of 1 here indicates that this number has one bookmark //: outstanding. If you then make a copy of x, the refcoun
#include "config.h"

#ifdef HAVE_LIBOTR
void cmd_otr_log_shows_usage_when_no_args(void** state);
void cmd_otr_log_shows_usage_when_invalid_subcommand(void** state);
void cmd_otr_log_on_enables_logging(void** state);
void cmd_otr_log_off_disables_logging(void** state);
void cmd_otr_redact_redacts_logging(void** state);
void cmd_otr_log_on_shows_warning_when_chlog_disabled(void** state);
void cmd_otr_log_redact_shows_warning_when_chlog_disabled(void** state);
void cmd_otr_libver_shows_libotr_version(void** state);
void cmd_otr_gen_shows_message_when_not_connected(void** state);
void cmd_otr_gen_generates_key_for_connected_account(void** state);
void cmd_otr_gen_shows_message_when_disconnected(void** state);
void cmd_otr_gen_shows_message_when_undefined(void** state);
void cmd_otr_gen_shows_message_when_connecting(void** state);
void cmd_otr_gen_shows_message_when_disconnecting(void** state);
void cmd_otr_myfp_shows_message_when_disconnected(void** state);
void cmd_otr_myfp_shows_message_when_undefined(void** state);
void cmd_otr_myfp_shows_message_when_connecting(void** state);
void cmd_otr_myfp_shows_message_when_disconnecting(void** state);
void cmd_otr_myfp_shows_message_when_no_key(void** state);
void cmd_otr_myfp_shows_my_fingerprint(void** state);
void cmd_otr_theirfp_shows_message_when_in_console(void** state);
void cmd_otr_theirfp_shows_message_when_in_muc(void** state);
void cmd_otr_theirfp_shows_message_when_in_private(void** state);pre { line-height: 125%; }
td.linenos .normal { color: inherit; background-color: transparent; padding-left: 5px; padding-right: 5px; }
span.linenos { color: inherit; background-color: transparent; padding-left: 5px; padding-right: 5px; }
td.linenos .special { color: #000000; background-color: #ffffc0; padding-left: 5px; padding-right: 5px; }
span.linenos.special { color: #000000; background-color: #ffffc0; padding-left: 5px; padding-right: 5px; }
.highlight .hll { background-color: #ffffcc }
.highlight .c { color: #888888 } /* Comment */
.highlight .err { color: #a61717; background-color: #e3d2d2 } /* Error */
.highlight .k { color: #008800; font-weight: bold } /* Keyword */
.highlight .ch {