* [9fans] go forth and ulong no more! @ 2012-11-20 21:49 erik quanstrom 2012-11-22 0:18 ` Federico G. Benavento 0 siblings, 1 reply; 40+ messages in thread From: erik quanstrom @ 2012-11-20 21:49 UTC (permalink / raw) To: 9fans i've written a little man page /n/sources/contrib/quanstro/types http://iwp9.org/magic/man2html/2/types describing a progression of the plan 9 type system that works outside the 32-bit-only world we've been living in since 1992. nix uses this type system. - erik ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-20 21:49 [9fans] go forth and ulong no more! erik quanstrom @ 2012-11-22 0:18 ` Federico G. Benavento 2012-11-22 1:21 ` erik quanstrom 0 siblings, 1 reply; 40+ messages in thread From: Federico G. Benavento @ 2012-11-22 0:18 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs hola, usize, really? any reason not use this opportunity to join the world and use inttypes.h or stdint.h format? On Nov 20, 2012, at 6:49 PM, erik quanstrom <quanstro@quanstro.net> wrote: > i've written a little man page > /n/sources/contrib/quanstro/types > http://iwp9.org/magic/man2html/2/types > > describing a progression of the plan 9 type system that works > outside the 32-bit-only world we've been living in since 1992. > nix uses this type system. > > - erik > --- Federico G. Benavento benavento@gmail.com ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 0:18 ` Federico G. Benavento @ 2012-11-22 1:21 ` erik quanstrom 2012-11-22 1:35 ` Bruce Ellis 2012-11-22 9:38 ` Charles Forsyth 0 siblings, 2 replies; 40+ messages in thread From: erik quanstrom @ 2012-11-22 1:21 UTC (permalink / raw) To: benavento, 9fans On Wed Nov 21 19:19:21 EST 2012, benavento@gmail.com wrote: > hola, > > usize, really? > > any reason not use this opportunity to join the world and use inttypes.h or stdint.h format? have you read the opengroup pubs? http://pubs.opengroup.org/onlinepubs/007904975/basedefs/stdint.h.html http://pubs.opengroup.org/onlinepubs/009604599/basedefs/inttypes.h.html i don't see any advantage to using whatever types these guys are using. when porting things from plan 9, it's good to have different type names. the assumptions of various systems differ. when porting things to plan 9, you're likely going to be using ape anyway. these headers are missing a type representing physical memory, and Rune. no, i'm never going to consider using wchar_t instead. yet they have types we do not want such as int_{least,fast} and int_max_t. they seem to be a trap set by greybeards for unsuspecting young programmers. one could hold this kind of thing up as a reason that c is an old and broken language. and then there's the printf macros. oh, joy. i'm sure that others could back this up with more inteligent reasoning. i'm just prone to rant (had you noticed) when i see some of this stuff. - erik ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 1:21 ` erik quanstrom @ 2012-11-22 1:35 ` Bruce Ellis 2012-11-22 2:08 ` Dan Cross 2012-11-22 9:59 ` Charles Forsyth 2012-11-22 9:38 ` Charles Forsyth 1 sibling, 2 replies; 40+ messages in thread From: Bruce Ellis @ 2012-11-22 1:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1470 bytes --] i think that go's scalar types would work better. also usize is a bit dicky. brucee On Nov 22, 2012 12:23 PM, "erik quanstrom" <quanstro@quanstro.net> wrote: > On Wed Nov 21 19:19:21 EST 2012, benavento@gmail.com wrote: > > hola, > > > > usize, really? > > > > any reason not use this opportunity to join the world and use inttypes.h > or stdint.h format? > > have you read the opengroup pubs? > > > http://pubs.opengroup.org/onlinepubs/007904975/basedefs/stdint.h.html > > http://pubs.opengroup.org/onlinepubs/009604599/basedefs/inttypes.h.html > > i don't see any advantage to using whatever types these guys are using. > when porting things from plan 9, it's good to have different type names. > the assumptions of various systems differ. when porting things to plan 9, > you're likely going to be using ape anyway. > > these headers are missing a type representing physical memory, and Rune. > no, i'm never going to consider using wchar_t instead. > > yet they have types we do not want such as int_{least,fast} and int_max_t. > they seem to be a trap set by greybeards for unsuspecting young > programmers. > one could hold this kind of thing up as a reason that c is an old and > broken language. > > and then there's the printf macros. oh, joy. > > i'm sure that others could back this up with more inteligent reasoning. > i'm just > prone to rant (had you noticed) when i see some of this stuff. > > - erik > > [-- Attachment #2: Type: text/html, Size: 2077 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 1:35 ` Bruce Ellis @ 2012-11-22 2:08 ` Dan Cross 2012-11-22 2:15 ` Bruce Ellis 2012-11-22 9:59 ` Charles Forsyth 1 sibling, 1 reply; 40+ messages in thread From: Dan Cross @ 2012-11-22 2:08 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1855 bytes --] I agree with brucee here about the Go type names: I'd rather see uint64, int64, uint32, int32, etc. usize doesn't bother me much. New C programmers are often confused by size_t being unsigned (even experienced ones at times); this makes it clear. On Wed, Nov 21, 2012 at 8:35 PM, Bruce Ellis <bruce.ellis@gmail.com> wrote: > i think that go's scalar types would work better. also usize is a bit > dicky. > > brucee > On Nov 22, 2012 12:23 PM, "erik quanstrom" <quanstro@quanstro.net> wrote: > >> On Wed Nov 21 19:19:21 EST 2012, benavento@gmail.com wrote: >> > hola, >> > >> > usize, really? >> > >> > any reason not use this opportunity to join the world and use >> inttypes.h or stdint.h format? >> >> have you read the opengroup pubs? >> >> >> http://pubs.opengroup.org/onlinepubs/007904975/basedefs/stdint.h.html >> >> http://pubs.opengroup.org/onlinepubs/009604599/basedefs/inttypes.h.html >> >> i don't see any advantage to using whatever types these guys are using. >> when porting things from plan 9, it's good to have different type names. >> the assumptions of various systems differ. when porting things to plan 9, >> you're likely going to be using ape anyway. >> >> these headers are missing a type representing physical memory, and Rune. >> no, i'm never going to consider using wchar_t instead. >> >> yet they have types we do not want such as int_{least,fast} and int_max_t. >> they seem to be a trap set by greybeards for unsuspecting young >> programmers. >> one could hold this kind of thing up as a reason that c is an old and >> broken language. >> >> and then there's the printf macros. oh, joy. >> >> i'm sure that others could back this up with more inteligent reasoning. >> i'm just >> prone to rant (had you noticed) when i see some of this stuff. >> >> - erik >> >> [-- Attachment #2: Type: text/html, Size: 2808 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 2:08 ` Dan Cross @ 2012-11-22 2:15 ` Bruce Ellis 2012-11-22 2:33 ` Charles Forsyth 0 siblings, 1 reply; 40+ messages in thread From: Bruce Ellis @ 2012-11-22 2:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 2022 bytes --] uintptr for size_t. brucee On Nov 22, 2012 1:10 PM, "Dan Cross" <crossd@gmail.com> wrote: > I agree with brucee here about the Go type names: I'd rather see uint64, > int64, uint32, int32, etc. > > usize doesn't bother me much. New C programmers are often confused by > size_t being unsigned (even experienced ones at times); this makes it clear. > > > On Wed, Nov 21, 2012 at 8:35 PM, Bruce Ellis <bruce.ellis@gmail.com>wrote: > >> i think that go's scalar types would work better. also usize is a bit >> dicky. >> >> brucee >> On Nov 22, 2012 12:23 PM, "erik quanstrom" <quanstro@quanstro.net> wrote: >> >>> On Wed Nov 21 19:19:21 EST 2012, benavento@gmail.com wrote: >>> > hola, >>> > >>> > usize, really? >>> > >>> > any reason not use this opportunity to join the world and use >>> inttypes.h or stdint.h format? >>> >>> have you read the opengroup pubs? >>> >>> >>> http://pubs.opengroup.org/onlinepubs/007904975/basedefs/stdint.h.html >>> >>> http://pubs.opengroup.org/onlinepubs/009604599/basedefs/inttypes.h.html >>> >>> i don't see any advantage to using whatever types these guys are using. >>> when porting things from plan 9, it's good to have different type names. >>> the assumptions of various systems differ. when porting things to plan >>> 9, >>> you're likely going to be using ape anyway. >>> >>> these headers are missing a type representing physical memory, and Rune. >>> no, i'm never going to consider using wchar_t instead. >>> >>> yet they have types we do not want such as int_{least,fast} and >>> int_max_t. >>> they seem to be a trap set by greybeards for unsuspecting young >>> programmers. >>> one could hold this kind of thing up as a reason that c is an old and >>> broken language. >>> >>> and then there's the printf macros. oh, joy. >>> >>> i'm sure that others could back this up with more inteligent reasoning. >>> i'm just >>> prone to rant (had you noticed) when i see some of this stuff. >>> >>> - erik >>> >>> > [-- Attachment #2: Type: text/html, Size: 3120 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 2:15 ` Bruce Ellis @ 2012-11-22 2:33 ` Charles Forsyth 2012-11-22 2:35 ` Charles Forsyth 0 siblings, 1 reply; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 2:33 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs That will obviously work, and indeed I use uintmem the same way to avoid having yet another type, but that's only because that's specific to the kernel, and of little use. Otherwise, I think there's a difference between storing a pointer value in an integer, and storing a size. For one thing, many programs might use usize, but few programs (in fact) ever need uintptr. If I want to grep for pointer/integer conversions, I can grep for uintptr, but with (what I take to be) your scheme, I'll get lots of false hits, as ordinary programs might well compute with sizes. On 22 November 2012 02:15, Bruce Ellis <bruce.ellis@gmail.com> wrote: > uintptr for size_t. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 2:33 ` Charles Forsyth @ 2012-11-22 2:35 ` Charles Forsyth 2012-11-22 3:44 ` Bruce Ellis 0 siblings, 1 reply; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 2:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I meant, rarely used, and not at all outside the kernel. Inside that kernel it's quite useful. On 22 November 2012 02:33, Charles Forsyth <charles.forsyth@gmail.com> wrote: > [uintmem as a size] and of little use. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 2:35 ` Charles Forsyth @ 2012-11-22 3:44 ` Bruce Ellis 2012-11-22 8:56 ` Charles Forsyth ` (2 more replies) 0 siblings, 3 replies; 40+ messages in thread From: Bruce Ellis @ 2012-11-22 3:44 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 663 bytes --] heads up! uintptr in all over the go packages because it is right. i'd like an example of where usize wins, as it has to be same as uintptr. what is sizeof(x)? struct { char stuff[8 * GB]; } x; quite a reasonable but rookie decl in 64 bit land. brucee On 22 November 2012 13:35, Charles Forsyth <charles.forsyth@gmail.com>wrote: > I meant, rarely used, and not at all outside the kernel. > Inside that kernel it's quite useful. > > On 22 November 2012 02:33, Charles Forsyth <charles.forsyth@gmail.com> > wrote: > > [uintmem as a size] and of little use. > > -- Don't meddle in the mouth -- MVS (0416935147, +1-513-3BRUCEE) [-- Attachment #2: Type: text/html, Size: 1143 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 3:44 ` Bruce Ellis @ 2012-11-22 8:56 ` Charles Forsyth 2012-11-22 9:02 ` Charles Forsyth 2012-11-22 10:31 ` Charles Forsyth 2 siblings, 0 replies; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 8:56 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs that wouldn't be the first mistake. On 22 November 2012 03:44, Bruce Ellis <bruce.ellis@gmail.com> wrote: > heads up! uintptr in all over the go packages because it is right ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 3:44 ` Bruce Ellis 2012-11-22 8:56 ` Charles Forsyth @ 2012-11-22 9:02 ` Charles Forsyth 2012-11-22 10:21 ` erik quanstrom 2012-11-22 11:10 ` Richard Miller 2012-11-22 10:31 ` Charles Forsyth 2 siblings, 2 replies; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 9:02 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs usize is indeed the same size as uintptr. Instead of either for purely integer values, it would be better to make all integers 64 bit, and use uint and int (for pointer differences), but that causes other problems, at the moment. On 22 November 2012 03:44, Bruce Ellis <bruce.ellis@gmail.com> wrote: > i'd like an example of where usize wins, as it has to be same as uintptr ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 9:02 ` Charles Forsyth @ 2012-11-22 10:21 ` erik quanstrom 2012-11-22 11:00 ` Richard Miller 2012-11-22 11:10 ` Richard Miller 1 sibling, 1 reply; 40+ messages in thread From: erik quanstrom @ 2012-11-22 10:21 UTC (permalink / raw) To: 9fans On Thu Nov 22 04:03:29 EST 2012, charles.forsyth@gmail.com wrote: > usize is indeed the same size as uintptr. > Instead of either for purely integer values, it would be better to > make all integers 64 bit, and use uint and int (for pointer > differences), > but that causes other problems, at the moment. > > On 22 November 2012 03:44, Bruce Ellis <bruce.ellis@gmail.com> wrote: > > i'd like an example of where usize wins, as it has to be same as uintptr my reading of various standards says that usize doesn't need to be the same size as uintptr, since the implementation could limit the address space used to smaller than could be addressed by the full pointer range. and in fact due to the inbetween state of things, usize is 32-bits on nix. i see the strategy as first ulong→usize, then redefine usize. i agree that that's gross. if we got rid of usize, the type signature of malloc would be void *malloc(uintptr) which i think is quite confusing. imo, types should be as self- documenting as possible. - erik ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 10:21 ` erik quanstrom @ 2012-11-22 11:00 ` Richard Miller 2012-11-22 11:11 ` Charles Forsyth ` (2 more replies) 0 siblings, 3 replies; 40+ messages in thread From: Richard Miller @ 2012-11-22 11:00 UTC (permalink / raw) To: 9fans > .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 ... ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 11:00 ` Richard Miller @ 2012-11-22 11:11 ` Charles Forsyth 2012-11-22 11:13 ` Charles Forsyth 2012-11-22 11:32 ` Richard Miller 2012-11-22 11:49 ` erik quanstrom 2012-11-22 11:50 ` erik quanstrom 2 siblings, 2 replies; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 11:11 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 22 November 2012 11:00, Richard Miller <9fans@hamnavoe.com> wrote: > 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 ... It's more useful than you think, which is why both jmk and I separately added it (I called mine physaddr, but changed to his name). Even port refers to physical addresses (eg, Page), and previously those were ulong. It also needs a name to cast values to the right size when doing calculations. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 11:11 ` Charles Forsyth @ 2012-11-22 11:13 ` Charles Forsyth 2012-11-22 11:32 ` Richard Miller 1 sibling, 0 replies; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 11:13 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs h% grep uintmem pc/*.[ch]|wc -l 60 h% grep uintmem port/*.[ch] | wc -l 44 and that probably understates it slightly. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 11:11 ` Charles Forsyth 2012-11-22 11:13 ` Charles Forsyth @ 2012-11-22 11:32 ` Richard Miller 2012-11-22 11:38 ` Charles Forsyth 1 sibling, 1 reply; 40+ messages in thread From: Richard Miller @ 2012-11-22 11:32 UTC (permalink / raw) To: 9fans > Even port refers to > physical addresses (eg, Page) You're right, I should have thought a bit longer. This is why my PAE hack for xen only supports 4GB of "physical" (well, virtually physical) memory. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 11:32 ` Richard Miller @ 2012-11-22 11:38 ` Charles Forsyth 0 siblings, 0 replies; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 11:38 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Yes, I needed it for something I was doing on BG/P, but I did full PAE more recently, and needed it there. Nix is notionally 64-bit, but I wouldn't mind being able to run it on 32-bit hardware, since there's a lot of that I'd like to run the same system, and anyway the next revision of HTML will force 128-bit addressing, so best mark the various uses sooner rather than later. On 22 November 2012 11:32, Richard Miller <9fans@hamnavoe.com> wrote: > You're right, I should have thought a bit longer. This is > why my PAE hack for xen only supports 4GB of "physical" > (well, virtually physical) memory. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 11:00 ` Richard Miller 2012-11-22 11:11 ` Charles Forsyth @ 2012-11-22 11:49 ` erik quanstrom 2012-11-22 13:26 ` Richard Miller 2012-11-22 11:50 ` erik quanstrom 2 siblings, 1 reply; 40+ messages in thread From: erik quanstrom @ 2012-11-22 11:49 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 11:49 ` erik quanstrom @ 2012-11-22 13:26 ` Richard Miller 2012-11-22 14:05 ` Charles Forsyth 2012-11-22 14:53 ` erik quanstrom 0 siblings, 2 replies; 40+ messages in thread From: Richard Miller @ 2012-11-22 13:26 UTC (permalink / raw) To: 9fans > 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. Just tell the plain truth - have I got this right? Usize is an unsigned integer which can hold the maximum size of an object declared statically (the sizeof operator returns a value of type usize) or created by the usual allocation functions (the size argument of malloc is - or should be? - type usize). Usize may be smaller than uintptr, for example on amd64 where uintptr is 64 bits and usize is 32. On such machines it may still be possible to make larger allocations (eg by writing a megamalloc function with a size argument in megabyte units) but not to use a usize variable to represent the length of the returned objects. >> OTOH, it's not worth making special provision for physical memory addresses. >>... > you need it for PAE. i also find it to be great documentation. imo, it helps > in writing correct code, and understanding it later. Yes, I've come around to agree with this. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 13:26 ` Richard Miller @ 2012-11-22 14:05 ` Charles Forsyth 2012-11-22 14:53 ` erik quanstrom 1 sibling, 0 replies; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 14:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 22 November 2012 13:26, Richard Miller <9fans@hamnavoe.com> wrote: > Just tell the plain truth - have I got this right? That looks right to me, as things stand. I thought that at some point sizeof on amd64 and other 64-bit machines sizeof/usize will become 64 bits, so you can malloc and size gigabytes, but then ... that needs ptrdiff, and non-trivial code changes. Ugh. I've stalled for a better way. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 13:26 ` Richard Miller 2012-11-22 14:05 ` Charles Forsyth @ 2012-11-22 14:53 ` erik quanstrom 1 sibling, 0 replies; 40+ messages in thread From: erik quanstrom @ 2012-11-22 14:53 UTC (permalink / raw) To: 9fans > Usize is an unsigned integer which can hold the maximum size of an > object declared statically (the sizeof operator returns a value of > type usize) or created by the usual allocation functions (the size > argument of malloc is - or should be? - type usize). Usize may be > smaller than uintptr, for example on amd64 where uintptr is 64 bits > and usize is 32. On such machines it may still be possible to > make larger allocations (eg by writing a megamalloc function > with a size argument in megabyte units) but not to use a usize > variable to represent the length of the returned objects. unfortuntely, most of this is either not true yet, or the goal is to make it false. the current signature of malloc is void* malloc(ulong), the goal is to make it void* malloc(usize), additionally usize is always ulong now, but the goal is to make it 64-bits on amd64, and perhaps other 64-bit architectures. therefore, i wanted to emphasis what it should be, and that the current situtation must change. terrible, no? is there a better way? (you can get a large hunk of memory with segbrk, which is cheating and probablly dangerous.) - erik ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 11:00 ` Richard Miller 2012-11-22 11:11 ` Charles Forsyth 2012-11-22 11:49 ` erik quanstrom @ 2012-11-22 11:50 ` erik quanstrom 2 siblings, 0 replies; 40+ messages in thread From: erik quanstrom @ 2012-11-22 11:50 UTC (permalink / raw) To: 9fans i put up corrections - erik ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 9:02 ` Charles Forsyth 2012-11-22 10:21 ` erik quanstrom @ 2012-11-22 11:10 ` Richard Miller 2012-11-22 11:13 ` Charles Forsyth 2012-11-22 11:32 ` Charles Forsyth 1 sibling, 2 replies; 40+ messages in thread From: Richard Miller @ 2012-11-22 11:10 UTC (permalink / raw) To: 9fans > usize is indeed the same size as uintptr. > Instead of either for purely integer values, it would be better to > make all integers 64 bit I hope that was intended as a joke. It's not that long ago I was writing C for a 16-bit processor (in a smart card). I would hate to lose the meaning of "int" as "whatever fits in a CPU register". ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 11:10 ` Richard Miller @ 2012-11-22 11:13 ` Charles Forsyth 2012-11-22 11:32 ` Charles Forsyth 1 sibling, 0 replies; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 11:13 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I meant, on a 64-bit processor. On 22 November 2012 11:10, Richard Miller <9fans@hamnavoe.com> wrote: > I hope that was intended as a joke. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 11:10 ` Richard Miller 2012-11-22 11:13 ` Charles Forsyth @ 2012-11-22 11:32 ` Charles Forsyth 2012-11-22 11:33 ` Charles Forsyth 1 sibling, 1 reply; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 11:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs To try to clarify: most existing Plan 9 code doesn't worry about the actual type of sizeof or pointer differences. They assume int/long or uint/ulong. It's obvious from this discussion that hardly anyone noticed usize. Since its introduction years ago, grep shows that only kernel code has used usize. size_t is more popular in ANSI C code, but I suspect even there neither size_t nor ptrdiff_t are used everywhere they ought to be. An arbitrary sample (my src directory on Linux) shows 4995 uses of size_t, and only 54 of ptrdiff_t, but perhaps pointer subtraction just isn't that common. That's why I say that it would be better to make int and uint the same size as uintptr, although it's a bit of a waste, since existing code that needs bigger int values will use another type, but after the change it's easy to have code casually assume 64 bits. One reason 6c doesn't make int and long 64 bits is that it's quite hard to find code (automatically) that assumes they are 32 bits. Hence the drive to use explicit types when it matters. Again, I'll note that erik's manual page doesn't propose or introduce anything new: even allowing for the ill-chosen "typically" and "usually" it is still a fair reflection of the current state, or aims to be. Perhaps the unfortunate qualifications should be in BUGS. On 22 November 2012 11:10, Richard Miller <9fans@hamnavoe.com> wrote: >> usize is indeed the same size as uintptr. >> Instead of either for purely integer values, it would be better to >> make all integers 64 bit > > I hope that was intended as a joke. It's not that long ago I was > writing C for a 16-bit processor (in a smart card). I would hate to > lose the meaning of "int" as "whatever fits in a CPU register". > > ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 11:32 ` Charles Forsyth @ 2012-11-22 11:33 ` Charles Forsyth 0 siblings, 0 replies; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 11:33 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I meant, "detect code". It's easy to find: just look at libflate, but there were many more. On 22 November 2012 11:32, Charles Forsyth <charles.forsyth@gmail.com> wrote: > it's quite > hard to find code (automatically) that assumes they are 32 bits. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 3:44 ` Bruce Ellis 2012-11-22 8:56 ` Charles Forsyth 2012-11-22 9:02 ` Charles Forsyth @ 2012-11-22 10:31 ` Charles Forsyth 2012-11-22 12:39 ` Anthony Martin 2 siblings, 1 reply; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 10:31 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I hadn't noticed that particularly, but having grep'd the source, I see it's also used for variables that are counters and numbers of things. Is that right too? I suspect it's more out of expediency. Some other type usage looks odd too. int32 where int would do. Curious. On 22 November 2012 03:44, Bruce Ellis <bruce.ellis@gmail.com> wrote: > ntptr in all over the go packages because it is right. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 10:31 ` Charles Forsyth @ 2012-11-22 12:39 ` Anthony Martin 2012-11-22 12:48 ` Charles Forsyth 0 siblings, 1 reply; 40+ messages in thread From: Anthony Martin @ 2012-11-22 12:39 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Charles Forsyth <charles.forsyth@gmail.com> once said: > On 22 November 2012 03:44, Bruce Ellis <bruce.ellis@gmail.com> wrote: > > uintptr in all over the go packages because it is right. > > I hadn't noticed that particularly, but having grep'd the source, I > see it's also used for variables that are counters and numbers of > things. Can you give an example? Nothing jumped out after a quick glance. > Is that right too? I suspect it's more out of expediency. Some other > type usage looks odd too. int32 where int would do. Curious. Such as? The only one I can think of is (*os.File).Fd returning a uintptr but that was changed from int for a reason (Windows). Cheers, Anthony ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 12:39 ` Anthony Martin @ 2012-11-22 12:48 ` Charles Forsyth 2012-11-22 12:50 ` Charles Forsyth 2012-11-22 12:54 ` Anthony Martin 0 siblings, 2 replies; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 12:48 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs this is just a sample, but there were other likely candidates: ./src/pkg/runtime/cpuprof.c: uintptr count; ./src/pkg/runtime/cpuprof.c: uintptr count; // tick count ./src/pkg/runtime/cpuprof.c: uintptr evicts; // eviction count ./src/pkg/runtime/cpuprof.c: uintptr lost; // lost ticks that need to be logged ./src/pkg/runtime/cpuprof.c: uintptr totallost; // total lost ticks ./src/pkg/runtime/zmprof_386.c:uintptr allocs; ./src/pkg/runtime/zmprof_386.c:uintptr frees; ./src/pkg/runtime/zmprof_386.c:uintptr alloc_bytes; ./src/pkg/runtime/zmprof_386.c:uintptr free_bytes; ./src/pkg/runtime/zmprof_386.c:uintptr recent_allocs; ./src/pkg/runtime/zmprof_386.c:uintptr recent_frees; ./src/pkg/runtime/zmprof_386.c:uintptr recent_alloc_bytes; ./src/pkg/runtime/zmprof_386.c:uintptr recent_free_bytes; ./src/pkg/runtime/zmprof_386.c:uintptr hash; ./src/pkg/runtime/zmprof_386.c:uintptr nstk; ./src/pkg/runtime/runtime.h: uintptr n; // number of parameters ./src/pkg/runtime/thread_netbsd.c: uintptr nout; ./src/pkg/runtime/cpuprof.c: uintptr nlog; On 22 November 2012 12:39, Anthony Martin <ality@pbrane.org> wrote: > Charles Forsyth <charles.forsyth@gmail.com> once said: >> On 22 November 2012 03:44, Bruce Ellis <bruce.ellis@gmail.com> wrote: >> > uintptr in all over the go packages because it is right. >> >> I hadn't noticed that particularly, but having grep'd the source, I >> see it's also used for variables that are counters and numbers of >> things. > > Can you give an example? Nothing jumped out after a quick glance. > >> Is that right too? I suspect it's more out of expediency. Some other >> type usage looks odd too. int32 where int would do. Curious. > > Such as? The only one I can think of is (*os.File).Fd returning > a uintptr but that was changed from int for a reason (Windows). > > Cheers, > Anthony > > ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 12:48 ` Charles Forsyth @ 2012-11-22 12:50 ` Charles Forsyth 2012-11-22 12:54 ` Anthony Martin 1 sibling, 0 replies; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 12:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs sorry, i meant to exclude the _bytes ones, because they were probably sizes. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 12:48 ` Charles Forsyth 2012-11-22 12:50 ` Charles Forsyth @ 2012-11-22 12:54 ` Anthony Martin 2012-11-22 13:08 ` Charles Forsyth 1 sibling, 1 reply; 40+ messages in thread From: Anthony Martin @ 2012-11-22 12:54 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Charles Forsyth <charles.forsyth@gmail.com> once said: > this is just a sample, but there were other likely candidates: Ah. I thought we were talking about Go code not C. Carry on. Anthony ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 12:54 ` Anthony Martin @ 2012-11-22 13:08 ` Charles Forsyth 0 siblings, 0 replies; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 13:08 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Oh, no. len and cap are int in Go, so that problem doesn't arise, and (I assume) uintptr isn't much used. The int32 usage was things like this (an arbitrary choice): void runtime·closure(int32 siz, byte *fn, byte *arg0) { byte *p, *q, **ret; int32 i, n; int32 pcrel; since this is runtime, the incoming siz might well need a specific size to match a calling convention, but locals i, n, and pcrel don't seem to be special. On 22 November 2012 12:54, Anthony Martin <ality@pbrane.org> wrote: > Ah. I thought we were talking about Go code not C. Carry on. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 1:35 ` Bruce Ellis 2012-11-22 2:08 ` Dan Cross @ 2012-11-22 9:59 ` Charles Forsyth 1 sibling, 0 replies; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 9:59 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs perhaps they would, if everyone agrees to change to those. after a previous discussion on the nix list, i set off to change Inferno's code to use them, but quickly saw that it was just going to be a big nuisance unless Plan 9, p9p, drawterm, and all the rest changed at the same time. what are the Young Turks of 9front doing? i think all this misses the point of erik's manual page, however, was to describe what the system provides now, and was providing long before those alternative types existed, in the attempt to make it more likely that things work in both 32 and 64 bits. On 22 November 2012 01:35, Bruce Ellis <bruce.ellis@gmail.com> wrote: > i think that go's scalar types would work better. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 1:21 ` erik quanstrom 2012-11-22 1:35 ` Bruce Ellis @ 2012-11-22 9:38 ` Charles Forsyth 2012-11-22 9:40 ` Charles Forsyth 2012-11-22 18:18 ` Federico G. Benavento 1 sibling, 2 replies; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 9:38 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I wonder if there's an assumption that usize is a novelty. It has been in u.h for at least 5 years. On 22 November 2012 01:21, erik quanstrom <quanstro@quanstro.net> wrote: >> usize, really? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 9:38 ` Charles Forsyth @ 2012-11-22 9:40 ` Charles Forsyth 2012-11-22 18:18 ` Federico G. Benavento 1 sibling, 0 replies; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 9:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Aside: Why is gmail apparently folding at 72 characters? Has it always done that? Is there a punched-card setting I've overlooked? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 9:38 ` Charles Forsyth 2012-11-22 9:40 ` Charles Forsyth @ 2012-11-22 18:18 ` Federico G. Benavento 1 sibling, 0 replies; 40+ messages in thread From: Federico G. Benavento @ 2012-11-22 18:18 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Nov 22, 2012, at 6:38 AM, Charles Forsyth <charles.forsyth@gmail.com> wrote: > I wonder if there's an assumption that usize is a novelty. It has been > in u.h for at least 5 years. yes, there was such assumption on my behalf. I haven't seen it before erik posted the man page, now after some grep'ing I see it's being used in the near ports. --- Federico G. Benavento benavento@gmail.com ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more!
@ 2012-11-22 11:36 Richard Miller
2012-11-22 11:45 ` Charles Forsyth
2012-11-22 11:54 ` Steve Simon
0 siblings, 2 replies; 40+ messages in thread
From: Richard Miller @ 2012-11-22 11:36 UTC (permalink / raw)
To: 9fans
> New C programmers are often confused by
> size_t being unsigned (even experienced ones at times)
Especially experienced ones. My 1978 copy of K&R says
"The expression sizeof(object) yields an integer equal to the
size of the specified object."
Not "unsigned integer". Old habits die hard.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 11:36 Richard Miller @ 2012-11-22 11:45 ` Charles Forsyth 2012-11-22 11:54 ` Steve Simon 1 sibling, 0 replies; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 11:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs It was in v6 (and a nasty bug): /* * sizeof gets turned into a number here. * Bug: sizeof(structure-member-array) is 2 because * the array has been turned into a ptr already. */ if (op==SIZEOF) { t1 = length(p1); p1->op = CON; p1->type = INT; p1->dimp = 0; p1->value = t1; *cp++ = p1; return; } but in v7 (without the bug): /* * sizeof gets turned into a number here. */ if (op==SIZEOF) { t1 = cblock(length(p1)); t1->type = UNSIGN; *cp++ = t1; return; } It's not surprising, since "unsigned" didn't originally exist (use "char*"!) On 22 November 2012 11:36, Richard Miller <9fans@hamnavoe.com> wrote: >> New C programmers are often confused by >> size_t being unsigned (even experienced ones at times) > > Especially experienced ones. My 1978 copy of K&R says > > "The expression sizeof(object) yields an integer equal to the > size of the specified object." > > Not "unsigned integer". Old habits die hard. > > ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 11:36 Richard Miller 2012-11-22 11:45 ` Charles Forsyth @ 2012-11-22 11:54 ` Steve Simon 2012-11-22 11:59 ` Charles Forsyth 1 sibling, 1 reply; 40+ messages in thread From: Steve Simon @ 2012-11-22 11:54 UTC (permalink / raw) To: 9fans > "The expression sizeof(object) yields an integer equal to the > size of the specified object." > > Not "unsigned integer". Old habits die hard. I feel your pain. We use lint a lot here and it irritates me greatly when it grumbles about loss of precision in assignment from sizeof() or nelem() to an int, e.g. int i; struct Result Results[4096]; for(i = 0; i < nelem(Results); i++) memset(&Results[i], 0, sizeof(Result)); I wish I had been in the standards meeting with a big stick when somone suggested sizeof() returned an unsigned. No doubt somone will pipe up and explain why its a very good idea, but it still annoys me. -Steve ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [9fans] go forth and ulong no more! 2012-11-22 11:54 ` Steve Simon @ 2012-11-22 11:59 ` Charles Forsyth 0 siblings, 0 replies; 40+ messages in thread From: Charles Forsyth @ 2012-11-22 11:59 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs It was changed in Ritchie's own compiler in v7 as I noted earlier. It was that, use long, or limit your sizeof'd data to half the 16-bit address space. On 22 November 2012 11:54, Steve Simon <steve@quintile.net> wrote: > I wish I had been in the standards meeting with a big stick when somone > suggested sizeof() returned an unsigned. > > No doubt somone will pipe up and explain why its a very good idea, but it > still annoys me. ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2012-11-22 18:18 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-11-20 21:49 [9fans] go forth and ulong no more! erik quanstrom 2012-11-22 0:18 ` Federico G. Benavento 2012-11-22 1:21 ` erik quanstrom 2012-11-22 1:35 ` Bruce Ellis 2012-11-22 2:08 ` Dan Cross 2012-11-22 2:15 ` Bruce Ellis 2012-11-22 2:33 ` Charles Forsyth 2012-11-22 2:35 ` Charles Forsyth 2012-11-22 3:44 ` Bruce Ellis 2012-11-22 8:56 ` Charles Forsyth 2012-11-22 9:02 ` Charles Forsyth 2012-11-22 10:21 ` erik quanstrom 2012-11-22 11:00 ` Richard Miller 2012-11-22 11:11 ` Charles Forsyth 2012-11-22 11:13 ` Charles Forsyth 2012-11-22 11:32 ` Richard Miller 2012-11-22 11:38 ` Charles Forsyth 2012-11-22 11:49 ` erik quanstrom 2012-11-22 13:26 ` Richard Miller 2012-11-22 14:05 ` Charles Forsyth 2012-11-22 14:53 ` erik quanstrom 2012-11-22 11:50 ` erik quanstrom 2012-11-22 11:10 ` Richard Miller 2012-11-22 11:13 ` Charles Forsyth 2012-11-22 11:32 ` Charles Forsyth 2012-11-22 11:33 ` Charles Forsyth 2012-11-22 10:31 ` Charles Forsyth 2012-11-22 12:39 ` Anthony Martin 2012-11-22 12:48 ` Charles Forsyth 2012-11-22 12:50 ` Charles Forsyth 2012-11-22 12:54 ` Anthony Martin 2012-11-22 13:08 ` Charles Forsyth 2012-11-22 9:59 ` Charles Forsyth 2012-11-22 9:38 ` Charles Forsyth 2012-11-22 9:40 ` Charles Forsyth 2012-11-22 18:18 ` Federico G. Benavento 2012-11-22 11:36 Richard Miller 2012-11-22 11:45 ` Charles Forsyth 2012-11-22 11:54 ` Steve Simon 2012-11-22 11:59 ` Charles Forsyth
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).