Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #36200

Re: size of

Show all headers | View raw

Malcolm McLean wrote:
> On Sunday, September 1, 2013 5:43:59 PM UTC+1, Tim Rentsch wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> Logically speaking, they're equivalent.  Practically speaking, my
>>> point is that implementations should meet the new requirement (if
>>> they don't already) not by adding new error cases for huge objects,
>>> but by making size_t bigger.  And of course most, perhaps all,
>>> existing implementations won't have to do anything.
>>
>> What you're suggesting has practical difficulties.  Real life is
>> not so simple.  In many cases "an implementation" is not a single
>> thing but a combination of a compiler and a standard library (or
>> substantial parts of a standard library), and they come from two
>> different places.  The library component is not necessarily easy
>> to swap out, and even if it doesn't define size_t itself it can
>> impose restrictions that effectively make it impossible to
>> change.  Saying "the implementation" can just make size_t bigger
>> is too simplistic.
>>
> size_t has two justifications, the first is that it's a variable big
> enough to hold an object of any size, the second is that it documents
> that a variable holds the size of an object, in bytes.
> Justification 2 was ill-thought out, because in fact size_t is used in
> the standard library for counts, which means that strictly programmers
> should be using it for index variables. So the name is misleading.

Why?  size_t is the type of the sizeof operator.  It is a size type.

> But if you start watering down justification 1 as well, then the whole
> idea is exposed as misconceived. The reality is that with current high-end
> hardware, a program may have a few memory objects greater than  2GB,
> but it's very unlikely to have more than a handful of such objects.
> It can't have more than one or two in memory at any one time, and few
> programs constantly allocate and free different huge objects of
> different types, to be used in different routines.

It can have as many as it has (virtual) memory for for. Current 
"high-end hardware" tends to have many tens or hundreds of GB of RAM. 
32GB is my standard fit these days and I'm building some hybrid storage 
serves for a client with 512GB.

> So the vast majority of the code will operate on objects which are known
> at compile time to be under 2GB. Because 64 bits is rather inefficient,
> programmers are going to tend to want 32 bit general purpose counts and
> index variables.

Compared to the data being indexed, a 64 count has an inconsequential 
impact on performance.

> The then other issue is that binary interfaces will
> tend to expect 32 bits for such types. If they declare them size_t
> (because after all the integers are counting things in memory) then
> that forces size_t to be 32 bits, and the result is a smash.

Eh?  I can't parse that.

-- 
Ian Collins

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-24 14:23 -0500
  Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-24 15:42 -0700
    Re: size of Richard Damon <Richard@Damon-Family.org> - 2013-08-24 20:09 -0400
      Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-24 17:52 -0700
      Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-24 22:53 -0400
        Re: size of Richard Damon <Richard@Damon-Family.org> - 2013-08-25 08:44 -0400
          Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-26 14:27 -0700
            Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-26 15:35 -0700
            Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-26 16:08 -0700
              Re: size of Robert Wessel <robertwessel2@yahoo.com> - 2013-08-27 12:29 -0500
              Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-27 10:45 -0700
                Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-27 14:46 -0700
                Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-29 02:10 -0700
                Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-29 11:38 -0700
                Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-09-01 09:43 -0700
                Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-09-01 16:14 -0700
                Re: size of Ian Collins <ian-news@hotmail.com> - 2013-09-02 11:42 +1200
                Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-09-01 20:32 -0400
                Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-09-03 08:13 -0700
                Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-09-03 08:31 -0700
                Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-09-22 10:35 -0700
            Re: size of Richard Damon <Richard@Damon-Family.org> - 2013-08-26 23:48 -0400
              Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-26 21:50 -0700
                Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-27 06:46 -0400
                Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-27 08:39 -0700
              Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-28 14:10 -0700
                Re: size of glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-28 21:46 +0000
                Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-29 10:15 -0700
                Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-28 17:09 -0700
                Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-29 10:43 -0700
  Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-25 10:49 -0700
    Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-25 11:15 -0700

csiph-web