From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Thu, 22 Nov 2012 06:49:13 -0500 To: 9fans@9fans.net Message-ID: <1180b98907e2cb6d8528c3fcf09ef589@ladd.quanstro.net> In-Reply-To: <3405876c84b4b238ab22a9d1200a77a2@hamnavoe.com> References: <3405876c84b4b238ab22a9d1200a77a2@hamnavoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] go forth and ulong no more! Topicbox-Message-UUID: e00242a0-ead7-11e9-9d60-3106f5b1d025 On Thu Nov 22 06:01:38 EST 2012, 9fans@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