ben> Of course, what really should happen is some more general ben> rethinking of the type names, in particular: [buffer positions, 1-based] Bufpos -> Charpos Bytind -> Bytepos Memind -> Mempos? I agree with Buf -> Char here, but prefer pos -> ind. The point is that all of these are array indicies. Of course "position" is a reasonable way to express that, but "Mempos" connotes "pointer" to me very strongly. "Memind" does not. (For those who aren't familiar with Emacs internal buffer representations: The Byte vs Mem distinction is due to the use of gap arrays to represent buffers. For positions on the high side of the gap, Byteind = Memind - gapsize, low side Byteind = Memind. The Byte/Mem vs. Char distinction is because in Mule non-ASCII characters have more than one byte---and not all characters are the same size in a Mule buffer, so you can't just count by 2s or 3s.) [string positions or character data counts, 0-based] Bytecount Charcount Extcount -> Bytecount? Does it make sense to distinguish these two? I don't think so. Get rid of Extcount. Furthermore, for me, there's no particular reason not to use Byteind rather than Bytecount, and similarly for Charind/Charcount. I think we can dispense with all of the *count typedefs, and rename Element_Count -> Elemind for indexing/counting arrays of structs. [coded character data] Bufbyte -> Intbyte Extbyte Ext for "external", Int for "internal"? *shrug* OK. [general] Element_Count Memory_Count Lstream_Data_Count -> Memory_Count? Does it make sense to distinguish these two? I don't think so. In fact, I would combine Memory_Count and Bytecount. The point is that I _do_ want to have different types where they occur in the same context and are easily confused (Memory_Counts would be passed to malloc, but the size of a frob block might be specified as an Element_Count). But the difference in type between i and n in Bytecount n = 10; Byteind i; for (i = 0; i < n; i++) { /* iterate me */ } escapes me. Char is a special case; for the foreseeable future I want Char* types to remind me that Char* objects are variable width, and that algorithms using them as if they were array elements should be suspected of felony inefficiency. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."