uintptr for size_t. brucee On Nov 22, 2012 1:10 PM, "Dan Cross" <cro...@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.el...@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" <quans...@quanstro.net> wrote: >> >>> On Wed Nov 21 19:19:21 EST 2012, benave...@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 >>> >>> >
