Re: Updating C default type

From	glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups	comp.lang.c
Subject	Re: Updating C default type
Date	2014-04-24 21:03 +0000
Organization	Aioe.org NNTP Server
Message-ID	<ljbu6v$igd$1@speranza.aioe.org> (permalink)
References	<lj66ho$8fg$1@speranza.aioe.org> <lj6750$a10$2@speranza.aioe.org> <lj6802$cek$1@speranza.aioe.org> <ljbdub$k4p$1@dont-email.me>

Show all headers | View raw

Ken Brody <kenbrody@spamcop.net> wrote:
> On 4/22/2014 1:13 PM, Raj Pashwar wrote:

(snip)
>> Of course, it does NOT make sense. However in this case, the 
>> benefit is the extra RANGE of double, not precision.

> So malloc() should be passed an *approximate* number of bytes 
> to allocate?

>> With a double arg, malloc could allocate upto 1.7e308 bytes. 
>> It will be many years, before RAM density increases to exceed 
>> this size. Whereas, int can only allocate upto 2e9 bytes.

> First, I wasn't aware that ints were limited to 32 bits.

> Second, malloc() takes size_t, not int.

> Finally, since the value passed to malloc() must, logically, 
> be able to be express in no more bits than the number of bits 
> in an address, why do you feel it is important to be able to 
> pass values larger than the address space, and to do so using 
> approximate rather than exact values?

Not disagreeing with the rest, but this doesn't follow.

If the addressing space requires even one more bit than the next
smallest size, that size is used for size_t.

While we now have many "64 bit" machines that allocate 64 bits
for addresses, most (or all) are physically unable to address
that many bits. To save on logic that won't be used in the life
of the actual chip, they don't put it all in. Usually some address
bits are required to be zeros (or all ones).

It is not at all unusual for an address not to be a power of two
bits wide, though the available integer types might be. 

> I just tried a simple program which shows me sizeof() for "void *", 
> "size_t", and "double".  All return 8.  On such a system, it would 
> not be possible to pass malloc() an exact value for "sufficiently 
> large" buffers, if it were passed a double rather than size_t.  
> (Or, if size_t were a double.)

Assuming 4TB swapping disks, and that you could put eight of
them on a system, you could address all the virtual memory 
with 45 bits. Physical addresses are likely smaller than that.

-- glen

Thread

Updating C default type Raj Pashwar <raj121190@hotmail.NOSPAM.com> - 2014-04-22 16:48 +0000
  Re: Updating C default type jacob navia <jacob@spamsink.net> - 2014-04-22 18:59 +0200
    Re: Updating C default type Raj Pashwar <raj121190@hotmail.NOSPAM.com> - 2014-04-22 17:13 +0000
      Re: Updating C default type Keith Thompson <kst-u@mib.org> - 2014-04-22 11:59 -0700
      Re: Updating C default type Kaz Kylheku <kaz@kylheku.com> - 2014-04-22 19:12 +0000
        Re: Updating C default type jacob navia <jacob@spamsink.net> - 2014-04-25 19:31 +0200
      Re: Updating C default type Stephen Sprunk <stephen@sprunk.org> - 2014-04-22 15:41 -0500
      Re: Updating C default type "BartC" <bc@freeuk.com> - 2014-04-22 21:47 +0100
      Re: Updating C default type Ken Brody <kenbrody@spamcop.net> - 2014-04-24 12:25 -0400
        Re: Updating C default type Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-24 10:32 -0700
        Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-24 20:17 +0000
        Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-24 21:03 +0000
    Re: Updating C default type Gareth Owen <gwowen@gmail.com> - 2014-04-22 19:12 +0100
  Re: Updating C default type Keith Thompson <kst-u@mib.org> - 2014-04-22 10:26 -0700
  Re: Updating C default type Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 10:28 -0700
  Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-22 18:20 +0000
    Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-22 19:09 +0000
      Re: Updating C default type James Kuyper <jameskuyper@verizon.net> - 2014-04-22 15:35 -0400
        Re: Updating C default type James Kuyper <jameskuyper@verizon.net> - 2014-04-22 15:38 -0400
        Re: Updating C default type Kaz Kylheku <kaz@kylheku.com> - 2014-04-22 19:54 +0000
          Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-22 21:27 +0000
            Re: Updating C default type "BartC" <bc@freeuk.com> - 2014-04-22 23:08 +0100
    Re: Updating C default type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-22 22:03 +0100
    Re: Updating C default type Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-04-23 09:59 +0200
    Re: Updating C default type David Thompson <dave.thompson2@verizon.net> - 2014-05-25 16:44 -0400
      Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-05-26 05:48 +0000
  Re: Updating C default type "Osmium" <r124c4u102@comcast.net> - 2014-04-22 14:01 -0500
    Re: Updating C default type Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2014-04-23 16:57 +0000
      Re: Updating C default type James Kuyper <jameskuyper@verizon.net> - 2014-04-23 13:13 -0400
      Re: Updating C default type Kaz Kylheku <kaz@kylheku.com> - 2014-04-23 18:02 +0000
      Re: Updating C default type Keith Thompson <kst-u@mib.org> - 2014-04-23 11:33 -0700
  Re: Updating C default type Kaz Kylheku <kaz@kylheku.com> - 2014-04-22 19:08 +0000
    Re: Updating C default type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-22 22:08 +0100
      Re: Updating C default type "BartC" <bc@freeuk.com> - 2014-04-22 22:19 +0100
    Re: Updating C default type Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 14:13 -0700
      Re: Updating C default type Stephen Sprunk <stephen@sprunk.org> - 2014-04-23 11:55 -0500
        Re: Updating C default type Keith Thompson <kst-u@mib.org> - 2014-04-23 10:55 -0700
          Re: Updating C default type Robert Wessel <robertwessel2@yahoo.com> - 2014-04-24 00:03 -0500
        Re: Updating C default type Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-23 22:37 -0700
          Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-24 12:05 +0000
      Re: Updating C default type gordonb.ez7sl@burditt.org (Gordon Burditt) - 2014-04-25 06:11 -0500
        Re: Updating C default type James Kuyper <jameskuyper@verizon.net> - 2014-04-25 08:48 -0400
  Re: Updating C default type Stephen Sprunk <stephen@sprunk.org> - 2014-04-22 15:30 -0500
    Re: Updating C default type ralph <nt_consulting@yahoo.com> - 2014-04-22 23:18 -0500
  Re: Updating C default type Ken Brody <kenbrody@spamcop.net> - 2014-04-24 12:28 -0400
  Re: Updating C default type gordonb.oztxz@burditt.org (Gordon Burditt) - 2014-04-24 23:50 -0500
    Re: Updating C default type James Kuyper <jameskuyper@verizon.net> - 2014-04-25 08:41 -0400
  Re: Updating C default type Hans Vlems <hvlems@freenet.de> - 2014-05-25 23:57 -0700
    Re: Updating C default type Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-05-26 01:55 -0700
    Re: Updating C default type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-05-26 13:01 +0100
      Re: Updating C default type Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-05-26 13:12 -0700
        Re: Updating C default type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-05-26 22:31 +0100
          Re: Updating C default type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-05-26 23:55 +0100
          Re: Updating C default type Keith Thompson <kst-u@mib.org> - 2014-05-26 17:11 -0700
    Re: Updating C default type James Kuyper <jameskuyper@verizon.net> - 2014-05-27 07:54 -0400

csiph-web