2009.06.05	br
2009.06.08	br
2009.06.10	bx, brace
2009.06.11	b2b0
2009.06.12	cz_parse, cz_shuffle
2009.06.13	b2b1... split_use, split_vars, uniq
2009.06.14	started cz_includes, backup
2009.06.15	include_file, cache, load_config
2009.09.06	resolve_dep
2009.09.07	Makefile, test.b, cz_includes, cz_pc
2009.09.08	cz_header, -h, libb gen headers in 0.09, translate in 0.33, b_plain, help
2009.09.09	namespace.b (compiled but untested)
2009.09.10	macrospace.b (compiled but untested)
2009.09.11	started cz_expand
2009.09.22	cz_meta array members
2009.09.28	expand_macros


TODO:
* flat hashtables: store the hashcode and a pointer to the object in the flat bit. The hashcode enables to find (probably) the right object quickly.  Will require 8 bytes per object.  Could have another impl. with just the pointer?
* check that I am using int correctly, I should be using long in some cases.
* names beginning with an underscore should not be used by ordinary code
* check array globals are declared properly in extern...?
* make sure it barfs if there are extra spaces or tabs at the end of a (nonblank) line, or strip them
* there is an offsetof macro in stddef.h for struct member offsets ... talaga
* do: def NULL (void*)0   to avoid possible crap defs in libraries
* maybe check for integer overflow in buffers etc (an error)
* macros are often defined with capitalized or all-upper-case names
* I could wrap args like #define sqr(x) (*&x) * (*&x) to prevent side effects
* implement token pasting ^^ and stringification ^  for macros, ^foo -> "foo"
* implement varargs for macros, C99 has ... -> __VA_ARGS__
* "the thorniest parts of many C programs are those which use lots of tricky little pointers to pick apart strings" so try not to do that.
* "As run-time libraries accrete more and more features (especially having to do with Graphical User Interfaces), and when one library function calls another library function to do part of its job (which ought to be a Good Thing; that's what library functions are for), it can happen that calling anything in the library (particularly something relatively powerful like printf) eventually pulls in practically everything else, leading to horribly bloated executables."  avoid too much coupling like this.
* M_PI is not standard :(
* "64K is (still) a pretty big chunk of memory. No matter how much memory your computer has available, it's asking a lot to be able to allocate huge amounts of it contiguously. (The C Standard does not guarantee that single objects can be 32K or larger, or 64K for C99.) Often it's a good idea to use data structures which don't require that all memory be contiguous."  consider using a buffer made from linked lists of buffers... something like writev / readv use
* "How do I get an accurate error status return from system on MS-DOS?  A: You can't; COMMAND.COM doesn't tend to provide one. If you don't need COMMAND.COM's services (i.e. if you're just trying to invoke a simple program, without I/O redirection and such) try one of the spawn routines, instead."  might be needed for main translator program if it uses "system" to run the compiler.
* fix "slurp", "fslurp" etc to be better!
* "reference counting is great if you share resources and it doesn't have to be very hard: the basic interface is really just Retain() and Release()"
* setlocale stuff...
* middle-exit style loops:
	do
		pr(int, i++)
	 while i < 10
		print(" - ")
* fix ranges e.g. in back!  always inclusive?  or just fix back?
* use capital letters for type names, like plan 9 (and also for the safe function names)
* uuid - nic mac addr + pid + gettimeofday + static counter
* better way to read env-vars with defaults (i.e. don't set the var if the env var is not set), like my getargs Getargs Args.  in env.b
* <Peaker> sswam, I'd like macros to be unable to have stuff like unbalanced parens/etc that make a parser's life impossible without first preprocessing
* http://phil.ipal.org/c/if-i-could-change-the-c-language.txt
* <cehteh> i'd rather make a language without 'comments', but have first class documentation entities
* some C blemishes (from wikipedia):
	Some specific problems worth noting are:
	Not checking number and types of arguments when the function declaration has an empty parameter list. (This provides backward compatibility with K&R C, which lacked prototypes.)
	Some questionable choices of operator precedence, as mentioned by Kernighan and Ritchie above, such as == binding more tightly than & and | in expressions like x & 1 == 0.
	The use of the = operator, used in mathematics for equality, to indicate assignment, following the precedent of Fortran, PL/I, and BASIC, but unlike ALGOL and its derivatives. Ritchie made this syntax design decision consciously, based primarily on the argument that assignment occurs more often than comparison.
	Similarity of the assignment and equality operators (= and ==), making it easy to accidentally substitute one for the other. C's weak type system permits each to be used in the context of the other without a compilation error (although some compilers produce warnings). For example, the conditional expression in if (a=b) is only true if a is not zero after the assignment.[8]
	A lack of infix operators for complex objects, particularly for string operations, making programs which rely heavily on these operations (implemented as functions instead) somewhat difficult to read.
	A declaration syntax that some find unintuitive, particularly for function pointers. (Ritchie's idea was to declare identifiers in contexts resembling their use: "declaration reflects use".)