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

Groups > comp.lang.c > #42759 > unrolled thread

size_t, when to use it? (learning)

Back to article view | Back to comp.lang.c

Contents

  size_t, when to use it? (learning) G G <gdotone@gmail.com> - 2014-04-10 08:11 -0700
    Re: size_t, when to use it? (learning) James Kuyper <jameskuyper@verizon.net> - 2014-04-10 11:42 -0400
      Re: size_t, when to use it? (learning) G G <gdotone@gmail.com> - 2014-04-10 08:53 -0700
    Re: size_t, when to use it? (learning) Kaz Kylheku <kaz@kylheku.com> - 2014-04-10 16:20 +0000
    Re: size_t, when to use it? (learning) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-10 11:03 -0700
      Re: size_t, when to use it? (learning) Kaz Kylheku <kaz@kylheku.com> - 2014-04-10 18:48 +0000
        Re: size_t, when to use it? (learning) Tim Prince <tprince@computer.org> - 2014-04-10 19:10 -0400
      Re: size_t, when to use it? (learning) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-10 20:03 +0000
        Re: size_t, when to use it? (learning) James Kuyper <jameskuyper@verizon.net> - 2014-04-10 16:15 -0400
          Re: size_t, when to use it? (learning) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-10 13:47 -0700
            Re: size_t, when to use it? (learning) Keith Thompson <kst-u@mib.org> - 2014-04-10 16:27 -0700
            Re: size_t, when to use it? (learning) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-11 01:08 -0700
              Re: size_t, when to use it? (learning) Ian Collins <ian-news@hotmail.com> - 2014-04-11 20:11 +1200
                Re: size_t, when to use it? (learning) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-11 05:06 -0700
                  Re: size_t, when to use it? (learning) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-11 17:40 +0000
              Re: size_t, when to use it? (learning) Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-14 18:44 -0700
            Re: size_t, when to use it? (learning) Ike Naar <ike@iceland.freeshell.org> - 2014-04-11 17:44 +0000
              Re: size_t, when to use it? (learning) Keith Thompson <kst-u@mib.org> - 2014-04-11 12:33 -0700
                Re: size_t, when to use it? (learning) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-11 13:23 -0700
                  Re: size_t, when to use it? (learning) Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-14 18:48 -0700
                    Re: size_t, when to use it? (learning) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-15 00:49 -0700
                      Re: size_t, when to use it? (learning) gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-15 08:16 +0000
                        Re: size_t, when to use it? (learning) <william@wilbur.25thandClement.com> - 2014-04-18 16:57 -0700
                          Re: size_t, when to use it? (learning) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-19 00:25 +0000
                            Re: size_t, when to use it? (learning) Kaz Kylheku <kaz@kylheku.com> - 2014-04-19 01:03 +0000
                            Re: size_t, when to use it? (learning) Ian Collins <ian-news@hotmail.com> - 2014-04-19 13:04 +1200
                            Re: size_t, when to use it? (learning) Keith Thompson <kst-u@mib.org> - 2014-04-18 19:23 -0700
                            Re: size_t, when to use it? (learning) <william@wilbur.25thandClement.com> - 2014-04-18 19:32 -0700
                              Re: size_t, when to use it? (learning) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-19 03:38 -0700
                      Re: size_t, when to use it? (learning) Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-18 09:13 -0700
                        Re: size_t, when to use it? (learning) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-18 14:00 -0700
                          Re: size_t, when to use it? (learning) Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-20 16:24 -0700
                            Re: size_t, when to use it? (learning) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 03:36 -0700
                Re: size_t, when to use it? (learning) Ike Naar <ike@iceland.freeshell.org> - 2014-04-12 06:53 +0000
              Re: size_t, when to use it? (learning) Martin Shobe <martin.shobe@yahoo.com> - 2014-04-11 14:42 -0500
                Re: size_t, when to use it? (learning) Ike Naar <ike@iceland.freeshell.org> - 2014-04-12 06:55 +0000
      Re: size_t, when to use it? (learning) G G <gdotone@gmail.com> - 2014-04-10 13:42 -0700
        Re: size_t, when to use it? (learning) James Kuyper <jameskuyper@verizon.net> - 2014-04-10 17:07 -0400
          Re: size_t, when to use it? (learning) G G <gdotone@gmail.com> - 2014-04-10 16:11 -0700
        Re: size_t, when to use it? (learning) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-10 15:08 -0700
          Re: size_t, when to use it? (learning) Keith Thompson <kst-u@mib.org> - 2014-04-10 17:21 -0700
            Re: size_t, when to use it? (learning) gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-11 01:04 +0000
          Re: size_t, when to use it? (learning) Ian Collins <ian-news@hotmail.com> - 2014-04-11 20:06 +1200
      Re: size_t, when to use it? (learning) Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-14 18:33 -0700
      Re: size_t, when to use it? (learning) Rosario193 <Rosario@invalid.invalid> - 2014-04-15 09:37 +0200
    Re: size_t, when to use it? (learning) Ian Collins <ian-news@hotmail.com> - 2014-04-11 20:09 +1200
    Re: size_t, when to use it? (learning) Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-14 18:21 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#42951

On Tuesday, April 15, 2014 2:48:36 AM UTC+1, Tim Rentsch wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> > On Friday, April 11, 2014 8:33:58 PM UTC+1, Keith Thompson wrote:
> >> No, sizeof *short is a syntax error.
> >> A better way to write the original would be:
> >>     short *photons = malloc(N * sizeof *photons);
> >> but the "sizeof(short)" version is correct.
> 
> > We've discussed this many times in the past.
> > My view is that the more natural readability of sizeof(short)
> > outweighs the fact that you don't have to change the line if
> > photons is changed to point to another type.
> 
> Do you think simply repeating your opinion, without offering
> any further explanation or justification, will have any effect
> on other people's reaction to it?  For the better, I mean?
>
If I just said "I think you're wrong" you'd have a point. In fact I gave
a brief justification. Anyone new to the group knows that there isn't a
consensus that the sizeof *ptr method is superior to sizeof(type),
without starting an entire sub-thread on the topic.
Whether they agree with me of with Keith is up to them.

[toc] | [prev] | [next] | [standalone]

#42954

In article <adca5e66-f404-485d-8183-d590c404e291@googlegroups.com>,
Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
...
>If I just said "I think you're wrong" you'd have a point. In fact I gave
>a brief justification. Anyone new to the group knows that there isn't a
>consensus that the sizeof *ptr method is superior to sizeof(type),
>without starting an entire sub-thread on the topic.
>Whether they agree with me of with Keith is up to them.

Actually, it isn't.  In the mentality of Kiki (and Kikian disciples, such
as Tim), it is no more an individual choice than is the validity of the
Trinity.  Obviously, these sorts of decisions are made at the top and the
rank-and-file is expected to go along.  Dissent is not possible.

-- 
"There's no chance that the iPhone is going to get any significant market share. No chance." - Steve Ballmer

[toc] | [prev] | [next] | [standalone]

#43105

Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <adca5e66-f404-485d-8183-d590c404e291@googlegroups.com>,
> Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
> ...
>>If I just said "I think you're wrong" you'd have a point. In fact I gave
>>a brief justification. Anyone new to the group knows that there isn't a
>>consensus that the sizeof *ptr method is superior to sizeof(type),
>>without starting an entire sub-thread on the topic.
>>Whether they agree with me of with Keith is up to them.
> 
> Actually, it isn't.  In the mentality of Kiki (and Kikian disciples, such
> as Tim), it is no more an individual choice than is the validity of the
> Trinity.  Obviously, these sorts of decisions are made at the top and the
> rank-and-file is expected to go along.  Dissent is not possible.
> 

I've fixed several bugs in my career where people used `sizeof (type)',
where type was wrong. I've yet to encounter a similar bug where people used
`sizeof object'. Anecdotal, but the fact of the matter is that `sizeof
object' states more precisely what you want, and precision is important when
programming.

People keep repeating that rule for specific reasons, none of which are to
oppress you.

[toc] | [prev] | [next] | [standalone]

#43106

william@wilbur.25thandclement.com wrote:

(snip)

> I've fixed several bugs in my career where people used `sizeof (type)',
> where type was wrong. I've yet to encounter a similar bug where 
> people used `sizeof object'. Anecdotal, but the fact of the 
> matter is that `sizeof object' states more precisely what you 
> want, and precision is important when programming.
 
> People keep repeating that rule for specific reasons, none of 
>which are to oppress you.

Yes if you sizeof(type) someone could change the type, such that
it didn't match.

But one could also change the name such that it didn't match.

There might have been:

short *a;
(... some lines in between)
a=malloc(100*sizeof(*a));

and someone later changes it to:

short *a;
long *b;
(... some lines in between)
b=malloc(100*sizeof(*a));

Now, note that sizeof(*a) doesn't eliminate the possibility
of bugs, but changes the ones that are possible. 

I can't tell which one a given person is more or less likely
to do. 

-- glen

[toc] | [prev] | [next] | [standalone]

#43107

On 2014-04-19, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> william@wilbur.25thandclement.com wrote:
>
> (snip)
>
>> I've fixed several bugs in my career where people used `sizeof (type)',
>> where type was wrong. I've yet to encounter a similar bug where 
>> people used `sizeof object'. Anecdotal, but the fact of the 
>> matter is that `sizeof object' states more precisely what you 
>> want, and precision is important when programming.
>  
>> People keep repeating that rule for specific reasons, none of 
>>which are to oppress you.
>
> Yes if you sizeof(type) someone could change the type, such that
> it didn't match.
>
> But one could also change the name such that it didn't match.

In the expression sizeof(X) or sizeof X, the compiler doesn't verify
that X agrees with anything in the surrounding code semantically;
the sizeof expression stands completely alone.

Now in sizeof(X), where X is an identifier, X could contain a typo such
that it happens to match a declared identifier.  Since the parentheses are
present, this wrong X can be a typedef name or an object.

If X has a typo in sizeof X, X can only be an object, not a type; there is a
smaller "typo target space". There are usually fewer declared objects than
there are declared type names and objects.

If sizeof *X has a typo in identifier X, the typo has to land on an
identifier which is declared such that it takes a unary * operator.
There are usually fewer declared pointers than there are declared objects.

[toc] | [prev] | [next] | [standalone]

#43108

glen herrmannsfeldt wrote:
> william@wilbur.25thandclement.com wrote:
>
> (snip)
>
>> I've fixed several bugs in my career where people used `sizeof (type)',
>> where type was wrong. I've yet to encounter a similar bug where
>> people used `sizeof object'. Anecdotal, but the fact of the
>> matter is that `sizeof object' states more precisely what you
>> want, and precision is important when programming.
>
>> People keep repeating that rule for specific reasons, none of
>> which are to oppress you.
>
> Yes if you sizeof(type) someone could change the type, such that
> it didn't match.
>
> But one could also change the name such that it didn't match.
>
> There might have been:
>
> short *a;
> (... some lines in between)
> a=malloc(100*sizeof(*a));
>
> and someone later changes it to:
>
> short *a;
> long *b;
> (... some lines in between)
> b=malloc(100*sizeof(*a));

The "some lines in between" is one reason for preferring sizeof object, 
especially for a reviewer of the code.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#43109

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> william@wilbur.25thandclement.com wrote:
>
> (snip)
>
>> I've fixed several bugs in my career where people used `sizeof (type)',
>> where type was wrong. I've yet to encounter a similar bug where 
>> people used `sizeof object'. Anecdotal, but the fact of the 
>> matter is that `sizeof object' states more precisely what you 
>> want, and precision is important when programming.
[...]
>
> Yes if you sizeof(type) someone could change the type, such that
> it didn't match.
>
> But one could also change the name such that it didn't match.
>
> There might have been:
>
> short *a;
> (... some lines in between)
> a=malloc(100*sizeof(*a));
>
> and someone later changes it to:
>
> short *a;
> long *b;
> (... some lines in between)
> b=malloc(100*sizeof(*a));
>
> Now, note that sizeof(*a) doesn't eliminate the possibility
> of bugs, but changes the ones that are possible. 
>
> I can't tell which one a given person is more or less likely
> to do. 

If you write

    b = malloc(100 * sizeof (int));

where b is of type long*, the error isn't obvious when you look at that
line.  You have to track down the declaration of b to make sure that its
declared type is consistent with the argument to sizeof.  And in more
complex cases (such as "sizeof (int*)" vs. "sizeof (int**)"), it can
still take a moment to parse the declaration and determine just what the
type is.

None of this is horribly difficult, and smart editors and IDEs can make
it easier.  But if you write:

    b = malloc(100 * sizeof *a);

the inconsistency is much more obvious, even if you don't know the types
of a and b.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#43111

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> william@wilbur.25thandclement.com wrote:
> 
> (snip)
> 
>> I've fixed several bugs in my career where people used `sizeof (type)',
>> where type was wrong. I've yet to encounter a similar bug where 
>> people used `sizeof object'. Anecdotal, but the fact of the 
>> matter is that `sizeof object' states more precisely what you 
>> want, and precision is important when programming.
> 
>> People keep repeating that rule for specific reasons, none of 
>>which are to oppress you.
> 
> Yes if you sizeof(type) someone could change the type, such that
> it didn't match.

Change the type, don't change the type. It doesn't matter. The argument is
simply that at the time of originally writing the code, and thereafter, the
"bug space" is in practice smaller. There's an extra step of inference
required by your brain when using sizeof (type), and that extra step opens
the door for more bugs. C's type abstractions are few and thin; it's worth
using them to their fullest extent where you can.

In the grand scheme of things it's not really that big of an issue. But at
the same time the cost of recommending the idiom and using it is near nil
(notwithstanding threads like this).

[toc] | [prev] | [next] | [standalone]

#43116

On Saturday, April 19, 2014 3:32:57 AM UTC+1, wil...@wilbur.25thandClement.com wrote:
> 
> Change the type, don't change the type. It doesn't matter. The argument is
> simply that at the time of originally writing the code, and thereafter, the
> "bug space" is in practice smaller. There's an extra step of inference
> required by your brain when using sizeof (type), and that extra step opens
> the door for more bugs. C's type abstractions are few and thin; it's worth
> using them to their fullest extent where you can.
> 
I see it as similar to

if(10 == N)

which is justified on the basis that the programmer might accidentally
write

if(N = 10)

it is awful that the last compiles to valid C, admittedly. But in normal
English usage, we say "if N equals 10". The further you get away for normal
usage, the harder the code is to read.

Similarly some people routinely write for loops

for(i=N;i--;)

on the basis that the test for zero is faster than the test for equality to N.
Except in the very innermost, most time critical loop this is undesireable,
we count up not down, and the condition evaluations shouldn't have side-
effects.

or infinite loops

[toc] | [prev] | [next] | [standalone]

#43082

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Tuesday, April 15, 2014 2:48:36 AM UTC+1, Tim Rentsch wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> 
>> > On Friday, April 11, 2014 8:33:58 PM UTC+1, Keith Thompson wrote:
>> >> No, sizeof *short is a syntax error.
>> >> A better way to write the original would be:
>> >>     short *photons = malloc(N * sizeof *photons);
>> >> but the "sizeof(short)" version is correct.
>> 
>> > We've discussed this many times in the past.
>> > My view is that the more natural readability of sizeof(short)
>> > outweighs the fact that you don't have to change the line if
>> > photons is changed to point to another type.
>> 
>> Do you think simply repeating your opinion, without offering
>> any further explanation or justification, will have any effect
>> on other people's reaction to it?  For the better, I mean?
>
> If I just said "I think you're wrong" you'd have a point.

Actually I wasn't trying to make a point, just ask a question.

> In fact I gave a brief justification.  [snip amplification]

I took your opinion to be "My view is that the more natural
readability of sizeof(short) outweighs the fact that [etc]".
I believed, perhaps wrongly, that you had stated this opinion
before and were simply restating it (note, there was nothing
further in the posting).  Is that wrong?  If so, my apologies.

[toc] | [prev] | [next] | [standalone]

#43099

On Friday, April 18, 2014 5:13:35 PM UTC+1, Tim Rentsch wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> I took your opinion to be "My view is that the more natural
> readability of sizeof(short) outweighs the fact that [etc]".
> I believed, perhaps wrongly, that you had stated this opinion
> before and were simply restating it (note, there was nothing
> further in the posting).  Is that wrong?  If so, my apologies.
>
Yes, that's essentially it.
There's no point starting essentially the same sub-thread every time someone
posts a code snippet that contains a call to malloc(). OTOH newbies shouldn't
be led to think that there's a consensus that the dereferencing style is
to be recommended.

[toc] | [prev] | [next] | [standalone]

#43203

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Friday, April 18, 2014 5:13:35 PM UTC+1, Tim Rentsch wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> 
>> I took your opinion to be "My view is that the more natural
>> readability of sizeof(short) outweighs the fact that [etc]".
>> I believed, perhaps wrongly, that you had stated this opinion
>> before and were simply restating it (note, there was nothing
>> further in the posting).  Is that wrong?  If so, my apologies.
>
> Yes, that's essentially it.

Okay.

> There's no point starting essentially the same sub-thread every
> time someone posts a code snippet that contains a call to
> malloc().  OTOH newbies shouldn't be led to think that there's a
> consensus that the dereferencing style is to be recommended.

If your point is that there are different opinions on the
question, you might want to say it differently, eg, "Note that
not everyone agrees with this viewpoint;  for example, IMO ...".
What was written in your earlier posting led me to believe you
meant to have, or renew, a debate on the merits.  That is very
different from saying only that there are different schools of
thought in the matter.

[toc] | [prev] | [next] | [standalone]

#43273

On Monday, April 21, 2014 12:24:19 AM UTC+1, Tim Rentsch wrote:
>  
> If your point is that there are different opinions on the
> question, you might want to say it differently, eg, "Note that
> not everyone agrees with this viewpoint;  for example, IMO ...".
> What was written in your earlier posting led me to believe you
> meant to have, or renew, a debate on the merits.  That is very
> different from saying only that there are different schools of
> thought in the matter.
>
You need to very briefly outline the argument. Just saying "I disagree" isn't very illuminating.
Saying "I disagree because ... but we've discussed this many times" puts everyone in the picture.

It's not as if a sub-thread on the topic is the end of the world. But I don't really have anything new 
to say on the subject that most regs haven't heard already, and I don't want to start essentially the
same sub-thread under every code snippet containing a call to a memory allocation function.

[toc] | [prev] | [next] | [standalone]

#42817

On 2014-04-11, Keith Thompson <kst-u@mib.org> wrote:
> Ike Naar <ike@iceland.freeshell.org> writes:
>> On 2014-04-10, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>>> Fixed-point numbers are integers to C, but that's just a reflection of the
>>> fact that C doesn't have any native syntactical sugar for fixed-point
>>> arithmetic.
>>> The other question is whether
>>>
>>> int i;
>>> int N = 100000;
>>> short *photons = malloc(N * sizeof(short));
>>
>> You've tried to allocate space for N pointers-to-short ...
>
> You've mis-read the code.  He's tried to allocate space for N shorts.
>
>>> for(i=0;i<N;i++)
>>>   potons[i] = detectphoton();
>>
>> ... but here you use the space as if it holds N shorts (assuming
>> 'potons' is a typo for 'photons').
>>
>> Did you mean
>>
>>   short *photons = malloc(N * sizeof *short);
>>
>> ? 
>
> No, sizeof *short is a syntax error.
>
> A better way to write the original would be:
>
>     short *photons = malloc(N * sizeof *photons);
>
> but the "sizeof(short)" version is correct.

Yes I misread the code. Sorry for the confusion.

[toc] | [prev] | [next] | [standalone]

#42815

On 4/11/2014 12:44 PM, Ike Naar wrote:
> On 2014-04-10, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>> Fixed-point numbers are integers to C, but that's just a reflection of the
>> fact that C doesn't have any native syntactical sugar for fixed-point
>> arithmetic.
>> The other question is whether
>>
>> int i;
>> int N = 100000;
>> short *photons = malloc(N * sizeof(short));
>
> You've tried to allocate space for N pointers-to-short ...

No he hasn't.

>> for(i=0;i<N;i++)
>>    potons[i] = detectphoton();
>
> ... but here you use the space as if it holds N shorts (assuming
> 'potons' is a typo for 'photons').
>
> Did you mean
>
>    short *photons = malloc(N * sizeof *short);

I seriously doubt that would compile.

Martin Shobe

[toc] | [prev] | [next] | [standalone]

#42818

On 2014-04-11, Martin Shobe <martin.shobe@yahoo.com> wrote:
> On 4/11/2014 12:44 PM, Ike Naar wrote:
>> On 2014-04-10, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>>> Fixed-point numbers are integers to C, but that's just a reflection of the
>>> fact that C doesn't have any native syntactical sugar for fixed-point
>>> arithmetic.
>>> The other question is whether
>>>
>>> int i;
>>> int N = 100000;
>>> short *photons = malloc(N * sizeof(short));
>>
>> You've tried to allocate space for N pointers-to-short ...
>
> No he hasn't.
>
>>> for(i=0;i<N;i++)
>>>    potons[i] = detectphoton();
>>
>> ... but here you use the space as if it holds N shorts (assuming
>> 'potons' is a typo for 'photons').
>>
>> Did you mean
>>
>>    short *photons = malloc(N * sizeof *short);
>
> I seriously doubt that would compile.

It won't compile. My mistake, I misread the malloc argument.

[toc] | [prev] | [next] | [standalone]

#42785

On Thursday, April 10, 2014 2:03:32 PM UTC-4, Malcolm McLean wrote:
>  
>The original idea was that it would hold the size in bytes of an object in memory. Typically, 
> machines have an address space of 4GB. So if you want an object of over 2GB in size, you can't pass
> an int to malloc(), as was the interface in old C. 
> 
> But unfortunately the ANSI committee also used size_t for counts of objects in memory. If you have
> a string of over 2GB, an int won't hold the length. sort also takes two size_ts.
> But if your count of objects in memory is a size_t, then your index variable which goes from 0 to 
> N-1 must also be a size_t. That's where the problems start.

> Firstly, if sizes in bytes, counts of objects, index variables, and intermediate variables used in calculating
> indices are all size_t, then that's practically all the integers in a typical C program. So plain int fades
> away, it's no useful any more. Except that it's intuitive to say "int i" when you want an integer, not
> size_t i, when i doesn't hold a size. So in fact code that uses size_t is littered with conversions from 
> int to size_t. The other problem is that size_t is unsigned. So you have to be careful with code like

> for(i=0;i<N-1;i++)
> 
> if we use ints, the loop body won't execute, which is probably the intention. if we use size_t, we'll get either a crash or a very long delay, depending on whether i indexes into memory or not.
> 
> My own view is, don't use size_t at all. Just pass ints to the standard library functions and pretend it 
> was never invented. You're much more likely to get a size_t bug than to have to deal with N > 2G.
> But of course I'm advocating writing code which, strictly, is incorrect. So it's hardly the ideal answer.
> There isn't an ideal answer. The committee has imposed on us something that makes sense maybe 
> in the small embedded world, and certainly makes sense in a non-human way of thinking, but is
> just a danger to actual programmers writing scalable algorithms.

Malcolm,

your post has made me curious about the name size_t.  i won't ask why that's the name, but does it have a kind of meaning, like int, integer, char, character... 

so, kinda ... sort of ... like ..., size_t, size of object,  size_t  is like the word "size" and the "t" in object or is it size of int, where "size" and the last letter in int, the "t", are put together.

i know it's, this, a little off subject, please forgive me, but thanks.

[toc] | [prev] | [next] | [standalone]

#42788

On 04/10/2014 04:42 PM, G G wrote:
...
> Malcolm,
> 
> your post has made me curious about the name size_t.  i won't ask why that's the name, but does it have a kind of meaning, like int, integer, char, character... 
> 
> so, kinda ... sort of ... like ..., size_t, size of object,  size_t  is like the word "size" and the "t" in object or is it size of int, where "size" and the last letter in int, the "t", are put together.

The formal definition of size_t is

"the unsigned integer type of the result of the sizeof operator;" (7.19p2).

That explains the "size" part of the name. Using "_t" for type names is
a common convention. POSIX even reserves such identifiers for use as
POSIX types. That C uses the same convention reflects the fact that C an
Unix were both first developed in roughly the same place at roughly the
same time.

[toc] | [prev] | [next] | [standalone]

#42793

On Thursday, April 10, 2014 5:07:10 PM UTC-4, James Kuyper wrote:
> On 04/10/2014 04:42 PM, G G wrote:

 
> "the unsigned integer type of the result of the sizeof operator;" (7.19p2).

> That explains the "size" part of the name. Using "_t" for type names is 
> a common convention. POSIX even reserves such identifiers for use as 
> POSIX types. That C uses the same convention reflects the fact that C an
> Unix were both first developed in roughly the same place at roughly the
> same time.

thanks James,

g.

[toc] | [prev] | [next] | [standalone]

#42790

On Thursday, April 10, 2014 9:42:44 PM UTC+1, G G wrote:
> 
> your post has made me curious about the name size_t.  i won't ask why 
> that's the name, but does it have a kind of meaning, like int, integer, 
> char, character... 
> 
> so, kinda ... sort of ... like ..., size_t, size of object,  size_t  is 
> like the word "size" and the "t" in object or is it size of int, where 
> "size" and the last letter in int, the "t", are put together.
> 
> i know it's, this, a little off subject, please forgive me, but thanks.
>
The t stands for "type". 

The name is a big part of the problem with size_t. The underscore looks
ugly and clashes with the convention that underscores represent either
namespace prefixes or subscripts. size strongly implies that the variable
holds a size in bytes, which was the original intention. Also, there's
no "size" type in most other programming languages.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web