On Thu Nov 22 06:01:38 EST 2012, 9f...@hamnavoe.com wrote: > > .B char > > can generally be assumed to be a signed value. > > What does "generally" mean here? Is it safe to assume or not?
good point. > > 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? do you think this should be changed. i don't mind. i didn't want to state an absolte then break it. :-). > > .B uintptr > > as a physical address may be the same size, larger (PAE), or smaller than > > a> virtual address. > > Should that be uintmem? yes. > 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.) so what do you want to do about usize. i can't easily just make it 64-bits on nix, because that would require that we get some changes in sources. malloc would need to be fixed, etc. > 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 ... you need it for PAE. i also find it to be great documentation. imo, it helps in writing correct code, and understanding it later. - erik
