> .B char > can generally be assumed to be a signed value. What does "generally" mean here? Is it safe to assume or not?
> There are no signed variants of these as they > are not useful where size-specific types are appropriate. "Not useful" seems an arbitrary judgment. There are certainly cases where widths are "fixed by hardware" (eg device registers) but values are semantically signed (eg address increment/decrement value in a DMA controller). > .B Usize > represents the type returned by the C > .B sizeof > operator. It is typically the same width as a virtual address. What does "typically" mean here? Is it or isn't it? > In order to ease the transition to 64-bits, the AMD64 compiler > currently uses a 32-bit > .BR usize . Oh, so it isn't. > .B uintptr > as a physical address may be the same size, larger (PAE), or smaller than a> > virtual address. Should that be uintmem? > .B Uintmem > also stores the sizes of things that > .B uintmem > might address. Strange inconsistency - why then doesn't uintptr store the sizes of things that uintptr might address? > .B schar > is used when porting to other systems where it may matter. It should not > generally be used. Is this saying it doesn't matter in Plan 9 whether chars are signed or not? What is the exception to the "generally"? My opinion: A type system is useful if and only if it helps you write code which will be correct in every environment in which it might run. Guidelines for usage which will be "generally" or "typically" correct just encourage bad habits. (Of which I am as guilty as anyone.) OTOH, it's not worth making special provision for physical memory addresses. I think that any code which is dealing with those is not likely to be portable to another architecture for many other reasons. I can't envision a single mmu.c being applicable to both 386 and amd64 ...
