size_t and array indexing and address arithmetic 
Author Message
 size_t and array indexing and address arithmetic

I was looking through Plauger's THE STANDARD C LIBRARY and came across the following
advice:

   "You should make a point of using type size_t *anywhere* your program
   performs array subscripting or address arithmetic."

So should 'i' never be declared as int again, and always be declared as size_t?  I've
got so used to 'int i', that 'size_t i' would just seem like an imposter!  Especially
for short array indexing. :-)

More seriously though, is Plauger's advice overkill?

Martin



Tue, 22 Aug 2000 03:00:00 GMT  
 size_t and array indexing and address arithmetic

Quote:

>I was looking through Plauger's THE STANDARD C LIBRARY and came across
>the following advice:
>   "You should make a point of using type size_t *anywhere* your program
>   performs array subscripting or address arithmetic."
>So should 'i' never be declared as int again, and always be declared as
>size_t?  I've got so used to 'int i', that 'size_t i' would just seem
>like an imposter!  Especially for short array indexing. :-)
>More seriously though, is Plauger's advice overkill?

Perhaps, but it'll save you some headaches when you discover that
strlen() has returned a value that int can't hold and you now have a
negative index, causing your program to behave unpredictably.

I have found myself doing it more often after I turned on compiler
warnings up to a pretty extreme level.

--

http://www.cs.wustl.edu/~jxh/        Washington University in Saint Louis

Quote:
>>>>>>>>>>>>> I use *SpamBeGone* <URL:http://www.internz.com/SpamBeGone/>



Tue, 22 Aug 2000 03:00:00 GMT  
 size_t and array indexing and address arithmetic

Quote:

>I was looking through Plauger's THE STANDARD C LIBRARY and came across the
following
>advice:

>   "You should make a point of using type size_t *anywhere* your program
>   performs array subscripting or address arithmetic."

>So should 'i' never be declared as int again, and always be declared as
size_t?  I've
>got so used to 'int i', that 'size_t i' would just seem like an imposter!
Especially
>for short array indexing. :-)

>More seriously though, is Plauger's advice overkill?

The advice is good advice.  It gives you the maximum protection.  But the data
type to use is an engineering decision.  You might even choose char or
unsigned char if you know enough about the conditions of the loop.  It's
pretty hard to go wrong using a size_t, though.  If you use something besides
size_t, you ought to have some kind of reason.  I know I have a habit of int.
If the loop ever needs to go negative or there is a test for <= 0 or the like,
then obviously, a size_t won't work.  OTOH, it looks to be a very good habit
to get into.
--
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ ftp: ftp://rtfm.mit.edu, C-FAQ Book: ISBN 0-201-84519-9
Try "C Programming: A Modern Approach" ISBN 0-393-96945-2
Want Software?  Algorithms?  Pubs? http://www.infoseek.com


Tue, 22 Aug 2000 03:00:00 GMT  
 size_t and array indexing and address arithmetic

Quote:


> >I was looking through Plauger's THE STANDARD C LIBRARY and came across
> >the following advice:
> >   "You should make a point of using type size_t *anywhere* your program
> >   performs array subscripting or address arithmetic."
> >So should 'i' never be declared as int again, and always be declared as
> >size_t?  I've got so used to 'int i', that 'size_t i' would just seem
> >like an imposter!  Especially for short array indexing. :-)
> >More seriously though, is Plauger's advice overkill?
> Perhaps, but it'll save you some headaches when you discover that
> strlen() has returned a value that int can't hold and you now have a
> negative index, causing your program to behave unpredictably.
> I have found myself doing it more often after I turned on compiler
> warnings up to a pretty extreme level.

After advocating the use of size_t, Plauger does add the following
caveat(s):

``...unsigned integer arithmetic has more pitfalls than signed.
You cannot run a counter down until it goes negative -- it never
will. If the translator doesn't warn you of a silly test expression,
the program may loop forever. You may find, in fact, that counting
down to zero sometimes leads to clumsy tests. You will occasionally
miss the convenience of using negative values [...] and testing
for them easily. Nevertheless, the improvement in robustness is
well worth the learning investment.''

    - p. 219 _The Standard C Library_

--
========================================================================

       Well...Unix, of course. Because windoze is a pathethic toy...
      Yes, Texas, of course. Because anywhere else is just a place...



Wed, 23 Aug 2000 03:00:00 GMT  
 size_t and array indexing and address arithmetic


Quote:

>The advice is good advice.  It gives you the maximum protection.  But the data
>type to use is an engineering decision.  You might even choose char or
>unsigned char if you know enough about the conditions of the loop.  It's
>pretty hard to go wrong using a size_t, though.  If you use something besides
>size_t, you ought to have some kind of reason.

Unfortunately there are at least two other guidelines this contradicts:

* "if you're not using plain int you should have a reason" (because plain
  int is supposed to be the natural size for the machine)

* "if you're using an unsigned type you should have a reason" (because of
  the {*filter*} surprises you can get when they interact with signed types)

I agree, though: it's an engineering decision, and needs to be taken on a
case-by-case basis.  IMO it would be pretty silly using a size_t for your
index into a 10-element array.

Disclaimer: I haven't actually read the book in question, so I'm only
going by what's been quoted here.

Cheers,
Richard
--
Richard Stamp
Churchill College, Cambridge



Wed, 23 Aug 2000 03:00:00 GMT  
 size_t and array indexing and address arithmetic

Quote:

>I was looking through Plauger's THE STANDARD C LIBRARY and came across the
> following
>advice:

>   "You should make a point of using type size_t *anywhere* your program
>   performs array subscripting or address arithmetic."

>So should 'i' never be declared as int again, and always be declared as size_t?
>  I've
>got so used to 'int i', that 'size_t i' would just seem like an imposter!
> Especially
>for short array indexing. :-)

>More seriously though, is Plauger's advice overkill?

Yes, a little. The most fundamental rule is to pick a type that can represent
the range of values you are interested in, and will continue to do so for
foreseeable (and maybe even some unforeseeable) developments of the program.
Plauger's advice is safe as long as you remember you are dealing with an
unsigned type and take into account issues resulting from that. However
it isn't necessary to use size_t in cases where int or unsigned int are
clearly adequate. For example:

   char buffer[100];

   while (fgets(buffer, sizeof buffer, fp) != NULL) {
       int length = strlen(buffer);

       ...
   }

Here the size of buffer can clearly be represented as an int as can the
length of any string it may hold. That in itself may be a dangerous
assumption since the array size could be changed later on. However the
second argument to fgets() is of type int so it cannot write a string
into buffer whose length exceeds INT_MAX characters. That means that
assigning to an int here is a perfectly safe and sensible thing to do.

--
-----------------------------------------


-----------------------------------------



Wed, 23 Aug 2000 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. array indexing by pointer and long index

2. array index of smallest number in array?

3. Multiply and Add matrices with 2d array WITHOUT ARRAY INDEXING

4. Using array index in array initialization list's

5. address arithmetic

6. declared constant address-arithmetic

7. Address arithmetic: some days you feel like a newbie

8. array subscripts ptrdiff_t and size_t

9. Indexed addressing mode on MIPS R8000

10. Which 2D array of 2D array addressing method?

11. Managed arrays and pointer arithmetic

12. arrays of strings & possible pointer arithmetic

 

 
Powered by phpBB® Forum Software