Re: [9fans] go forth and ulong no more!

[erik quanstrom <quanstro@quanstro.net>]

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