From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Thu, 22 Nov 2012 09:53:16 -0500 To: 9fans@9fans.net Message-ID: In-Reply-To: <4ffeabe415eb136f18a308b2f677ce39@hamnavoe.com> References: <4ffeabe415eb136f18a308b2f677ce39@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: e0c28718-ead7-11e9-9d60-3106f5b1d025 > 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