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

Could you please discuss whether casting a size_t variable to unsigned int variable is the correct way to handle...

Started by	G G <gdotone@gmail.com>
First post	2015-05-07 17:12 -0700
Last post	2015-05-08 05:12 +0000
Articles	20 on this page of 57 — 16 participants

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

Page 1 of 3 [1] 2 3 Next page →

#61737 — Could you please discuss whether casting a size_t variable to unsigned int variable is the correct way to handle...

From	G G <gdotone@gmail.com>
Date	2015-05-07 17:12 -0700
Subject	Could you please discuss whether casting a size_t variable to unsigned int variable is the correct way to handle...
Message-ID	<a148e69a-0699-419d-ac3e-2fff86c8a158@googlegroups.com>

Could you please discuss whether casting a size_t variable
to an unsigned variable the correct way to handle a warning
I'm getting when I compile the program that follows.

Inside the function mode(), rating is declared as a size_t variable.
Ok, that makes sense to me because in the function, rating is
is used as a subscript for an array. In order to capture the mode
value, the author uses the variable rating and assigns it to
modeValue which is declared as an unsigned int.

I'm using Xcode 6.3, clang, I guess, the compiler gives a warning
"Implicit conversion loses integer precision: 'size_t (aka 'unsigned
long') to 'unsigned int"

The program compiles and runs.

In order to remove the warning I cast rating to ( unsigned int ).
I guess in a simple program such as this it does not matter, but
can should I do this anytime I run across a situation like this.

The program is an example from Deitel and Deitel  "C How To Program"
6.16. I have left the cast out on the following program for those 
who would like to test it with a different compiler.

And below that program is the original out of the book.

/**************************************************************************/
/*  
    This program has been reformatted and some comments
    have been removed.
*/


/*
    Fig. 6.16: fig06_16.c
    Survey data analysis with arrays:
    computing the mean, median and mode of the data.
*/

#include <stdio.h>

#define SIZE 99

/* function prototypes */ 
void mean( const unsigned int answer[] );
void median( unsigned int answer[] );
void mode( unsigned int freq[], unsigned const int answer[] );
void bubbleSort( unsigned int a[] );
void printArray( unsigned const int a[] );


int main( void )
{
   unsigned int frequency[ 10 ] = { 0 };
    
   unsigned int response[ SIZE ] = { 6, 7, 8, 9, 8, 7, 8, 9, 8, 9,
                                                      7, 8, 9, 5, 9, 8, 7, 8, 7, 8,
                                                      6, 7, 8, 9, 3, 9, 8, 7, 8, 7,
                                                      7, 8, 9, 8, 9, 8, 9, 7, 8, 9,
                                                      6, 7, 8, 7, 8, 7, 9, 8, 9, 2,
                                                      7, 8, 9, 8, 9, 8, 9, 7, 5, 3,
                                                      5, 6, 7, 2, 5, 3, 9, 4, 6, 4,
                                                      7, 8, 9, 6, 8, 7, 8, 9, 7, 8,
                                                      7, 4, 4, 2, 5, 3, 8, 7, 5, 6,
                                                      4, 5, 6, 1, 6, 5, 7, 8, 7 };
   
   mean( response );
   median( response );
   mode(frequency, response );
   
} /* end main( ... ) */

/*********** mean() ************/
void mean( const unsigned int answer[] )
{
   size_t j; 
   unsigned int total = 0; 
   
   printf( "%s\n%s\n%s\n", "********", "   Mean", "********" );
   
   for ( j = 0; j < SIZE; ++j ) 
      total += answer[ j ];
    
   printf( "The mean is the average value of the data\n"
           "items. The mean is equal to the total of\n"
           "all the data item divided by the number\n"
           "of data items ( %u ). The mean value for \n"
           " this run is: %u / %u = %.4f\n\n",
           SIZE, total, SIZE, (double) total / SIZE );
   
} 

/************ median() ************/
void median( unsigned int answer[] )
{
   printf ( "\n%s\n%s\n%s\n%s",
            "********", " Median", "********",
           "The unsorted array of responses is" );
   
   printArray( answer ); 
   
   bubbleSort( answer ); 
   
   printf( "%s", "\n\nThe sorted array is " );
   printArray( answer ); 
   
   printf( "\n\nThe median is element %u of\n"
           "the sorted %u element array.\n"
           "For this run the median is %u\n\n",
          SIZE / 2, SIZE, answer[ SIZE / 2 ] );
   
} 

/************ mode() ************/
void mode( unsigned int freq[], const unsigned int answer[] )
{
   size_t rating; 
   size_t j; 
   unsigned int h; 
   unsigned int largest = 0;
   unsigned int modeValue = 0; 
   
   printf( "\n%s\n%s\n%s",
          "********", "  Mode", "********" );
   
   for ( rating = 1; rating <= 9; ++rating ) 
      freq[ rating ] = 0;
     
   for ( j = 0; j < SIZE; ++j ) 
      ++freq[ answer[ j ] ];
   
   /* output headers for results columns */
   printf( "%s%11s%19s\n\n%54s\n%54s\n\n",
          "Response", "Frequency", "Histogram",
         "1     1     2     2", "5     0     5     0     5" );
   
   /* output results */
   for ( rating = 1; rating <= 9; ++rating ) 
   {
      printf( "%8zu%11u          ", rating, freq[ rating ] );
      
     
      if ( freq[ rating ] > largest ) 
      {
         largest = freq[ rating ];
         modeValue = rating;
      }
      
      /* output historgram bar representing frequency value */
      for ( h = 1; h <= freq[ rating ]; ++h ) 
         printf( "%s", "*" );
         
      puts( "" ); // being new line of output
      
   }
   
   /* display mode value */
   printf( "\nThe mode is the most frequent value.\n"
           "For this run the mode is %u which occurred"
          " %u times.\n", modeValue, largest );
} 

/************* bubbleSort ************/
void bubbleSort( unsigned int a[] )
{
   unsigned int pass; 
   size_t j; 
   unsigned int hold; 
   
   for ( pass = 1; pass < SIZE; ++pass ) 
   {
      for ( j = 0; j < SIZE - 1; ++j ) 
      {
         if ( a[ j ] > a[ j + 1 ] ) 
         {
            hold = a[ j ];
            a[ j ] = a[ j + 1 ];
            a[ j + 1 ] = hold;
         } 
         
      } 
      
   } 
   
}

/************ printArray() ************/
void printArray( const unsigned int a[] )
{
   size_t j; 
   
   // output array contents
   for ( j = 0; j < SIZE; ++j ) 
   {     
      if ( j % 20 == 0 ) 
         puts( "" );
      
      printf( "%2u", a[ j ] );
   }
} 


/************************** from the textbook *********************************/

// Fig. 6.16: fig06_16.c
// Survey data analysis with arrays:
// computing the mean, median and mode of the data.

#include <stdio.h>
#define SIZE 99

// function prototypes
void mean( const unsigned int answer[] );
void median( unsigned int answer[] );
void mode( unsigned int freq[], unsigned const int answer[] );
void bubbleSort( unsigned int a[] );
void printArray( unsigned const int a[] );

// function main begins program execution
int main( void )
{
   unsigned int frequency[ 10 ] = { 0 }; // initialize array frequency
   
  
        
        
   unsigned int response[ SIZE ] = 
       { 6, 7, 8, 9, 8, 7, 8, 9, 8, 9,
         7, 8, 9, 5, 9, 8, 7, 8, 7, 8,
         6, 7, 8, 9, 3, 9, 8, 7, 8, 7,
         7, 8, 9, 8, 9, 8, 9, 7, 8, 9,
         6, 7, 8, 7, 8, 7, 9, 8, 9, 2,
         7, 8, 9, 8, 9, 8, 9, 7, 5, 3,
         5, 6, 7, 2, 5, 3, 9, 4, 6, 4,
         7, 8, 9, 6, 8, 7, 8, 9, 7, 8,
         7, 4, 4, 2, 5, 3, 8, 7, 5, 6,
         4, 5, 6, 1, 6, 5, 7, 8, 7 };
         
    // process response
   mean( response );
   median( response );
   mode(frequency, response );
   
} // end main

// calculate average of all response values
void mean( const unsigned int answer[] )
{
   size_t j; // counter for totaling array elements
   unsigned int total = 0; // variable to hold sum of array elements
   
   printf( "%s\n%s\n%s\n", "********", "   Mean", "********" );
   
   // total response values
   for ( j = 0; j < SIZE; ++j ) {
      total += answer[ j ];
   } //end for
   
   printf( "The mean is the average value of the data\n"
           "items. The mean is equal to the total of\n"
           "all the data item divided by the number\n"
           "of data items ( %u ). The mean value for \n"
           " this run is: %u / %u = %.4f\n\n",
          SIZE, total, SIZE, (double) total / SIZE );
   
} // end function mean

//sort array and determin median element's value
void median( unsigned int answer[] )
{
   printf ( "\n%s\n%s\n%s\n%s",
            "********", " Median", "********",
           "The unsorted array of responses is" );
   
   printArray( answer ); // output unsorted array
   
   bubbleSort( answer ); // sort array
   
   printf( "%s", "\n\nThe sorted array is " );
   printArray( answer ); // output sorted array
   
   // display median element
   printf( "\n\nThe median is element %u of\n"
           "the sorted %u element array.\n"
           "For this run the median is %u\n\n",
          SIZE / 2, SIZE, answer[ SIZE / 2 ] );
   
} // end function median

// determine most frequent median
void mode( unsigned int freq[], const unsigned int answer[] )
{
   size_t rating; // counter for accessing elements 1-9 of array freq
   size_t j; // counter for summarizing elements 0-98 of array answer
   unsigned int h; // counter for displaying historgrams freq array values
   unsigned int largest = 0; // represents largest frequency
   unsigned int modeValue = 0; // represents most frequent response
   
   printf( "\n%s\n%s\n%s\n",
          "********", "  Mode", "********" );
   
   // initialize frequencies to 0
   for ( rating = 1; rating <= 9; ++rating ) {
      freq[ rating ] = 0;
   } // end for
   
   // summarize frequencies
   for ( j = 0; j < SIZE; ++j ) {
      ++freq[ answer[ j ] ];
   } // end for
   
   // output headers for results colums
   printf( "%s%11s%19s\n\n%54s\n%54s\n\n",
          "Response", "Frequency", "Histogram",
         "1     1     2     2", "5     0     5     0     5" );
   
   // output results
   for ( rating = 1; rating <= 9; ++rating ) {
      printf( "%8zu%11u          ", rating, freq[ rating ] );
      
      // keep track of mode value and largest frequency value
      if ( freq[ rating ] > largest ) {
         largest = freq[ rating ];
         modeValue = rating;
      } // end if
      
      // output historgram bar representing frequency value
      for ( h = 1; h <= freq[ rating ]; ++h ) {
         printf( "%s", "*" );
      } // end inner for
      
      puts( "" ); // being new line of output
   }// end out for
   
   // display the mode value
   printf( "\nThe mode is the most frequent value.\n"
           "For this run the mode is %u which occurred"
          " %u times.\n", modeValue, largest );
} // end function mode

// functon that sorts an array with bubble sort algorithm
void bubbleSort( unsigned int a[] )
{
   unsigned int pass; // pass counter
   size_t j; // comparison counter
   unsigned int hold; // temparary location used to swap elements
   
   // loop to control number of passes
   for ( pass = 1; pass < SIZE; ++pass ) {
      
      // loop to control number of comparisons per pass
      for ( j = 0; j < SIZE - 1; ++j ) {
      
         // swap elements if out of order
         if ( a[ j ] > a[ j + 1 ] ) {
            hold = a[ j ];
            a[ j ] = a[ j + 1 ];
            a[ j + 1 ] = hold;
         } // end if
      } //end inner for
   } // end outer for
}// end function bubbleSort

// output array contents ( 20 values per row )
void printArray( const unsigned int a[] )
{
   size_t j; // counter
   
   // output array contents
   for ( j = 0; j < SIZE; ++j ) {
      
      if ( j % 20 == 0 ) { // begin new line every 20 values
         puts( "" );
      } // end if
      
      printf( "%2u", a[ j ] );
   } // end for
} // end function printArray

[toc] | [next] | [standalone]

#61740

From	Keith Thompson <kst-u@mib.org>
Date	2015-05-07 18:18 -0700
Message-ID	<87ioc3j29h.fsf@kst-u.example.com>
In reply to	#61737

G G <gdotone@gmail.com> writes:
> Could you please discuss whether casting a size_t variable
> to an unsigned variable the correct way to handle a warning
> I'm getting when I compile the program that follows.
>
> Inside the function mode(), rating is declared as a size_t variable.
> Ok, that makes sense to me because in the function, rating is
> is used as a subscript for an array. In order to capture the mode
> value, the author uses the variable rating and assigns it to
> modeValue which is declared as an unsigned int.

Surely you could have demonstrated the issue with a smaller program.

I don't get a warning with either version, but looking at the mode()
function:

> /************ mode() ************/
> void mode( unsigned int freq[], const unsigned int answer[] )
> {
>    size_t rating; 
[...]
>       if ( freq[ rating ] > largest ) 
>       {
>          largest = freq[ rating ];
>          modeValue = rating;
>       }
[...]
>    /* display mode value */
>    printf( "\nThe mode is the most frequent value.\n"
>            "For this run the mode is %u which occurred"
>           " %u times.\n", modeValue, largest );
> } 

the assignment

    modeValue = rating;

could lose information of rating exceeds UINT_MAX.

The obvious solution is to define modeValue as a size_t.  Like rating,
modeValue is an index into the array.

It might also be reasonable for both rating and modeValue to be of type
unsigned int *if* you can be sure that the array won't exceed UINT_MAX
elements.  But if you use size_t you don't have to worry about that.

-- 
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]

#61745

From	G G <gdotone@gmail.com>
Date	2015-05-07 20:16 -0700
Message-ID	<3cd2ac79-aeaa-4b7a-91d7-6fc63f592f72@googlegroups.com>
In reply to	#61740

On Thursday, May 7, 2015 at 9:18:09 PM UTC-4, Keith Thompson wrote:
> G G <gdotone@gmail.com> writes:
> > Could you please discuss whether casting a size_t variable
> > to an unsigned variable the correct way to handle a warning
> > I'm getting when I compile the program that follows.
> >
> > Inside the function mode(), rating is declared as a size_t variable.
> > Ok, that makes sense to me because in the function, rating is
> > is used as a subscript for an array. In order to capture the mode
> > value, the author uses the variable rating and assigns it to
> > modeValue which is declared as an unsigned int.
> 
> Surely you could have demonstrated the issue with a smaller program.
> 

I didn't of think of it.  I was just puzzled because I thought size_t was
really and unsigned int.

> I don't get a warning with either version, but looking at the mode()
> function:

Hum. Ok thanks.

> 
> the assignment
> 
>     modeValue = rating;
> 
> could lose information of rating exceeds UINT_MAX.
> 
> The obvious solution is to define modeValue as a size_t.  Like rating,
> modeValue is an index into the array.
>

I would not have caught that it was an index into an array.
I don't see that. So, the meaning here is because modeValue
is taking a value from a veritable that is an index of an array
modeValue should (could) be thought of as index?

> It might also be reasonable for both rating and modeValue to be of type
> unsigned int *if* you can be sure that the array won't exceed UINT_MAX
> elements. 

Ok, I do understand this. 
Thanks.

It didn't dawn on me to create a smaller program and submit that
thanks for taking a look and explaining. Truth is I might have made
a bigger mess.

g.

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

#61753

From	mark.bluemel@gmail.com
Date	2015-05-08 01:09 -0700
Message-ID	<5895acc1-fc80-493d-9252-a10f90eace8a@googlegroups.com>
In reply to	#61745

On Friday, 8 May 2015 04:16:38 UTC+1, G G  wrote:
> On Thursday, May 7, 2015 at 9:18:09 PM UTC-4, Keith Thompson wrote:
> > G G <gdotone@gmail.com> writes:
> > > Could you please discuss whether casting a size_t variable
> > > to an unsigned variable the correct way to handle a warning
> > > I'm getting when I compile the program that follows.
...
> > 
> > Surely you could have demonstrated the issue with a smaller program.
> > 
> 
> I didn't of think of it.  I was just puzzled because I thought size_t was
> really and unsigned int.

<http://www.catb.org/esr/faqs/smart-questions.html>

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

#61763 — Re: Could you please discuss whether casting a size_t variable to unsigned int variable is the correct way to handle...

From	Tim Prince <tprince@computer.org>
Date	2015-05-08 09:16 -0400
Subject	Re: Could you please discuss whether casting a size_t variable to unsigned int variable is the correct way to handle...
Message-ID	<cr3r94Fo78U1@mid.individual.net>
In reply to	#61745

On 5/7/2015 11:16 PM, G G wrote:
  I was just puzzled because I thought size_t was
> really and unsigned int.
> 
I lost my first major C++ customer over their insistence on this point.
 "we can't accept a compiler which doesn't do it the way we used to"
Good to see that the attitude persists.

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

#61766

From	Keith Thompson <kst-u@mib.org>
Date	2015-05-08 08:03 -0700
Message-ID	<87a8xfi01c.fsf@kst-u.example.com>
In reply to	#61745

G G <gdotone@gmail.com> writes:
[...]
> I didn't of think of it.  I was just puzzled because I thought size_t was
> really and unsigned int.

size_t is an implementation-defined unsigned integer type.  It's
defined via a typedef, which creates an alias for an existing type,
not a new type.  It could in principle be *any* unsigned integer
type; in practice, it's usually either unsigned int or unsigned long.

It needs to be wide enough to hold the size in bytes of any possible
object.  (Conceivably an implementation *might* permit objects bigger
than SIZE_MAX bytes; in practice, any sane implementation will make
size_t wide enough to hold the size of any object it can support.)

-- 
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]

#61773

From	Malcolm McLean <malcolm.mclean5@btinternet.com>
Date	2015-05-08 10:30 -0700
Message-ID	<f7b3041d-29d8-42a9-b4ce-4bf7b81eaad0@googlegroups.com>
In reply to	#61766

On Friday, May 8, 2015 at 4:03:51 PM UTC+1, Keith Thompson wrote:
> 
> It needs to be wide enough to hold the size in bytes of any possible
> object.  (Conceivably an implementation *might* permit objects bigger
> than SIZE_MAX bytes; in practice, any sane implementation will make
> size_t wide enough to hold the size of any object it can support.)
>
Indexing is a very common operation. So if you have a machine that
supports 64 bit types, but can process 32 bit types twice as fast
(maybe because what limits it is cache size), and virtually no
indexing operation goes above 2 billion, then you can gain a 2x
speed up by making all your index variables 32 bit.

Probably a bad idea, but tempting.

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

#61776

From	jadill33@gmail.com
Date	2015-05-08 11:12 -0700
Message-ID	<12c555e8-ba35-4396-baa0-d9c0b6bced0d@googlegroups.com>
In reply to	#61773

On Friday, May 8, 2015 at 1:30:53 PM UTC-4, Malcolm McLean wrote:
> On Friday, May 8, 2015 at 4:03:51 PM UTC+1, Keith Thompson wrote:
> > 
> > It needs to be wide enough to hold the size in bytes of any possible
> > object.  (Conceivably an implementation *might* permit objects bigger
> > than SIZE_MAX bytes; in practice, any sane implementation will make
> > size_t wide enough to hold the size of any object it can support.)
> >
> Indexing is a very common operation. So if you have a machine that
> supports 64 bit types, but can process 32 bit types twice as fast
> (maybe because what limits it is cache size), and virtually no
> indexing operation goes above 2 billion, then you can gain a 2x
> speed up by making all your index variables 32 bit.
> 
> Probably a bad idea, but tempting.

Never dealt with file sizes over 2GB then.  It's not uncommon for me
to see network traffic captures that go 3-5 times that amount.

Best regards,
John D.

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

#61778

From	Keith Thompson <kst-u@mib.org>
Date	2015-05-08 11:22 -0700
Message-ID	<87y4kzgcab.fsf@kst-u.example.com>
In reply to	#61773

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Friday, May 8, 2015 at 4:03:51 PM UTC+1, Keith Thompson wrote:
>> It needs to be wide enough to hold the size in bytes of any possible
>> object.  (Conceivably an implementation *might* permit objects bigger
>> than SIZE_MAX bytes; in practice, any sane implementation will make
>> size_t wide enough to hold the size of any object it can support.)
>>
> Indexing is a very common operation. So if you have a machine that
> supports 64 bit types, but can process 32 bit types twice as fast
> (maybe because what limits it is cache size), and virtually no
> indexing operation goes above 2 billion, then you can gain a 2x
> speed up by making all your index variables 32 bit.
>
> Probably a bad idea, but tempting.

Sure, an implementation for such a machine can make size_t 32 bits
and refuse to support objects bigger than 2**32 bytes.  And code
that uses size_t for indexing automatically gets the performance
gains of that decision.

If an implementation supports objects bigger than 2**32 bytes,
but your program never creates such large objects, and if
using 32-bit indices rather than 64-bit size_t results in a
substantial performance improvement, then that could be a reasonable
application-level optimization -- but you risk a loss of portability
and/or extensibility.

-- 
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]

#61782

From	glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date	2015-05-08 18:42 +0000
Message-ID	<mij01v$tct$1@speranza.aioe.org>
In reply to	#61778

Keith Thompson <kst-u@mib.org> wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

(snip)
>> Indexing is a very common operation. So if you have a machine that
>> supports 64 bit types, but can process 32 bit types twice as fast
>> (maybe because what limits it is cache size), and virtually no
>> indexing operation goes above 2 billion, then you can gain a 2x
>> speed up by making all your index variables 32 bit.

>> Probably a bad idea, but tempting.

There are plenty of problems where the maximum size is known.
It is unlikely that years will ever have more than 32767 days...
 
> Sure, an implementation for such a machine can make size_t 32 bits
> and refuse to support objects bigger than 2**32 bytes.  And code
> that uses size_t for indexing automatically gets the performance
> gains of that decision.

I have seen installers not install something when the available
disk or RAM was greater than 2GB, complaining that not enough
(something) was available.

Someday soon, I want to see what SunOS 4.x does with an NFS server
and a 3TB disk. (I suspect they didn't think about that at the time.)
 
> If an implementation supports objects bigger than 2**32 bytes,
> but your program never creates such large objects, and if
> using 32-bit indices rather than 64-bit size_t results in a
> substantial performance improvement, then that could be a reasonable
> application-level optimization -- but you risk a loss of portability
> and/or extensibility.

-- glen

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

#61780

From	Bartc <bc@freeuk.com>
Date	2015-05-08 19:25 +0100
Message-ID	<miiv1e$s8n$1@dont-email.me>
In reply to	#61773

On 08/05/2015 18:30, Malcolm McLean wrote:
> On Friday, May 8, 2015 at 4:03:51 PM UTC+1, Keith Thompson wrote:
>>
>> It needs to be wide enough to hold the size in bytes of any possible
>> object.  (Conceivably an implementation *might* permit objects bigger
>> than SIZE_MAX bytes; in practice, any sane implementation will make
>> size_t wide enough to hold the size of any object it can support.)
>>
> Indexing is a very common operation. So if you have a machine that
> supports 64 bit types, but can process 32 bit types twice as fast
> (maybe because what limits it is cache size), and virtually no
> indexing operation goes above 2 billion, then you can gain a 2x
> speed up by making all your index variables 32 bit.

But if you're indexing an array, usually you will just use the single 
index, which most likely will reside in a register.

You might speed things up however if you have an array of size_t objects 
which can do with being 32-bits instead of 64-bits.

More significant I think are pointer objects that are 64-bits when the 
code and data in the program easily fit into a 32-bit space.

-- 
Bartc

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

#61784

From	Stephen Sprunk <stephen@sprunk.org>
Date	2015-05-08 15:12 -0500
Message-ID	<mij59h$lqa$1@dont-email.me>
In reply to	#61780

On 08-May-15 13:25, Bartc wrote:
> On 08/05/2015 18:30, Malcolm McLean wrote:
>> Indexing is a very common operation. So if you have a machine that 
>> supports 64 bit types, but can process 32 bit types twice as fast 
>> (maybe because what limits it is cache size), and virtually no 
>> indexing operation goes above 2 billion, then you can gain a 2x 
>> speed up by making all your index variables 32 bit.
> 
> But if you're indexing an array, usually you will just use the
> single index, which most likely will reside in a register.
> 
> You might speed things up however if you have an array of size_t
> objects which can do with being 32-bits instead of 64-bits.
> 
> More significant I think are pointer objects that are 64-bits when
> the code and data in the program easily fit into a 32-bit space.

On many architectures, the only difference between 32- and 64-bit modes
is the pointer size, so if you don't need 64-bit pointers, just compile
for 32-bit mode instead.  And if your assumption turns out to be wrong,
just recompile for 64-bit mode--no code changes required, if you wrote
the code correctly in the first place.

It's more complicated for x86 because x86-64 introduced many changes
(e.g. more GPRs) unrelated to pointer size.  The "x32" project has the
goal of getting those other benefits while retaining 32-bit pointers,
but it doesn't seem to be getting much traction so far.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#61789

From	Bartc <bc@freeuk.com>
Date	2015-05-08 22:38 +0100
Message-ID	<mijab2$8hf$1@dont-email.me>
In reply to	#61784

On 08/05/2015 21:12, Stephen Sprunk wrote:
> On 08-May-15 13:25, Bartc wrote:

>> More significant I think are pointer objects that are 64-bits when
>> the code and data in the program easily fit into a 32-bit space.

> On many architectures, the only difference between 32- and 64-bit modes
> is the pointer size, so if you don't need 64-bit pointers, just compile
> for 32-bit mode instead.  And if your assumption turns out to be wrong,
> just recompile for 64-bit mode--no code changes required, if you wrote
> the code correctly in the first place.
>
> It's more complicated for x86 because x86-64 introduced many changes
> (e.g. more GPRs) unrelated to pointer size.  The "x32" project has the
> goal of getting those other benefits while retaining 32-bit pointers,
> but it doesn't seem to be getting much traction so far.

(That's what I've done in my own 64-bit compiler for x64. But it's 
difficult to measure how much difference it makes as a I don't have a 
64-bit-pointer version to compare with, while C compilers will 
outperform it anyway even when compiling for x86/32-bits.

But it just seems right that a struct object for example is the 16 bytes 
it should be and not stretched to 24 (or even 32) bytes to accommodate a 
pointer range I don't want.

However, properly implementing 32-bit pointers under x64 I think would 
need OS support. I have to use 64-bit values to store pointers and 
handles obtained from the OS.)

-- 
Bartc

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

#61792 — Re: Could you please discuss whether casting a size_t variable to unsigned int variable is the correct way to handle...

From	Ian Collins <ian-news@hotmail.com>
Date	2015-05-09 11:01 +1200
Subject	Re: Could you please discuss whether casting a size_t variable to unsigned int variable is the correct way to handle...
Message-ID	<cr4ti9F1b5pU2@mid.individual.net>
In reply to	#61789

Bartc wrote:
> On 08/05/2015 21:12, Stephen Sprunk wrote:
>> On 08-May-15 13:25, Bartc wrote:
>
>>> More significant I think are pointer objects that are 64-bits when
>>> the code and data in the program easily fit into a 32-bit space.
>
>> On many architectures, the only difference between 32- and 64-bit modes
>> is the pointer size, so if you don't need 64-bit pointers, just compile
>> for 32-bit mode instead.  And if your assumption turns out to be wrong,
>> just recompile for 64-bit mode--no code changes required, if you wrote
>> the code correctly in the first place.
>>
>> It's more complicated for x86 because x86-64 introduced many changes
>> (e.g. more GPRs) unrelated to pointer size.  The "x32" project has the
>> goal of getting those other benefits while retaining 32-bit pointers,
>> but it doesn't seem to be getting much traction so far.
>
> (That's what I've done in my own 64-bit compiler for x64. But it's
> difficult to measure how much difference it makes as a I don't have a
> 64-bit-pointer version to compare with, while C compilers will
> outperform it anyway even when compiling for x86/32-bits.
>
> But it just seems right that a struct object for example is the 16 bytes
> it should be and not stretched to 24 (or even 32) bytes to accommodate a
> pointer range I don't want.
>
> However, properly implementing 32-bit pointers under x64 I think would
> need OS support. I have to use 64-bit values to store pointers and
> handles obtained from the OS.)

It would also add yet another set of system libraries on top of the 
existing 32 and 64 bit versions.  Modern OSs already have support for 
both 64 and 32 bit applications with a 64 bit kernel, so I guess nearly 
all of the effort would be in user-land.

-- 
Ian Collins

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

#61822

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2015-05-10 09:19 -0700
Message-ID	<kfnvbg0e76h.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#61766

Keith Thompson <kst-u@mib.org> writes:

> G G <gdotone@gmail.com> writes:
> [...]
>> I didn't of think of it.  I was just puzzled because I thought
>> size_t was really and unsigned int.
>
> size_t is an implementation-defined unsigned integer type.  It's
> defined via a typedef, which creates an alias for an existing
> type, not a new type.  [snip]

What makes you say size_t must be defined using 'typedef'?  I
agree that this will very likely be true, but I haven't found
anything in the Standard that implies that it _must_ be true.  Is
there some reason an implementation could not, for example, have
something like

    _Declare size_t;

in those header files required to provide size_t?  AFAICT the
type size_t may be distinct from any integer type that is
nameable without using 'size_t'.

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

#61834

From	Keith Thompson <kst-u@mib.org>
Date	2015-05-10 11:26 -0700
Message-ID	<876180gufr.fsf@kst-u.example.com>
In reply to	#61822

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> G G <gdotone@gmail.com> writes:
>> [...]
>>> I didn't of think of it.  I was just puzzled because I thought
>>> size_t was really and unsigned int.
>>
>> size_t is an implementation-defined unsigned integer type.  It's
>> defined via a typedef, which creates an alias for an existing
>> type, not a new type.  [snip]
>
> What makes you say size_t must be defined using 'typedef'?  I
> agree that this will very likely be true, but I haven't found
> anything in the Standard that implies that it _must_ be true.  Is
> there some reason an implementation could not, for example, have
> something like
>
>     _Declare size_t;
>
> in those header files required to provide size_t?  AFAICT the
> type size_t may be distinct from any integer type that is
> nameable without using 'size_t'.

You're right, size_t doesn't *necessarily* have to be a typedef.

The standard (7.19) says that <stddef.h>

    declares the following types.
    ...
    The types are
    ...
        size_t
    which is the unsigned integer type of the result of the sizeof
    operator;

The only way to define size_t in standard C is to use a typedef
-- but standard headers aren't restricted to using standard C.
Using an extension would be permissible.

I think it still has to be equivalent to some named predefined type.
size_t is an "unsigned integer type", which means (6.2.5) that it's
either one of the six "standard unsigned integer types" (it can't
be _Bool), or an "extended unsigned integer types".  A footnote
suggests, but doesn't quite say, that extended integer types have
names that are implementation-defined keywords, which "shall have the
form of an identifier reserved for any use as described in 7.1.3".
The name "size_t" doesn't qualify.  (Certainly "size_t" can't be
treated as a keyword.)

If an implementation used an extension to define size_t without using
"typedef", I'd have difficulty arguing that it's non-conforming -- but
it still quacks like a typedef.

I suspect the authors of the standard assumed size_t is a typedef and
didn't bother saying so explicitly.

-- 
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]

#61877

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2015-05-11 21:31 -0700
Message-ID	<kfnlhguct6u.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#61834

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> G G <gdotone@gmail.com> writes:
>>> [...]
>>>> I didn't of think of it.  I was just puzzled because I thought
>>>> size_t was really and unsigned int.
>>>
>>> size_t is an implementation-defined unsigned integer type.  It's
>>> defined via a typedef, which creates an alias for an existing
>>> type, not a new type.  [snip]
>>
>> What makes you say size_t must be defined using 'typedef'?  I
>> agree that this will very likely be true, but I haven't found
>> anything in the Standard that implies that it _must_ be true.  Is
>> there some reason an implementation could not, for example, have
>> something like
>>
>>     _Declare size_t;
>>
>> in those header files required to provide size_t?  AFAICT the
>> type size_t may be distinct from any integer type that is
>> nameable without using 'size_t'.
>
> You're right, size_t doesn't *necessarily* have to be a typedef.
>
> The standard (7.19) says that <stddef.h>
>
>     declares the following types.
>     ...
>     The types are
>     ...
>         size_t
>     which is the unsigned integer type of the result of the sizeof
>     operator;
>
> The only way to define size_t in standard C is to use a typedef --
> but standard headers aren't restricted to using standard C.  Using
> an extension would be permissible.
>
> I think it still has to be equivalent to some named predefined
> type.

I agree that size_t must refer to a particular (ie, predefined)
type - if not a standard integer type then an extended integer
type.  I just don't find anything in the Standard that implies
that type has to have a name other than (in this case) size_t.
Why couldn't the name just be size_t?  There would need to be a
way to declare the name, but that could be done using a reserved
keyword or #pragma.

> size_t is an "unsigned integer type", which means (6.2.5)
> that it's either one of the six "standard unsigned integer types"
> (it can't be _Bool), or an "extended unsigned integer types".  A
> footnote suggests, but doesn't quite say, that extended integer
> types have names that are implementation-defined keywords, which
> "shall have the form of an identifier reserved for any use as
> described in 7.1.3".  The name "size_t" doesn't qualify.
> (Certainly "size_t" can't be treated as a keyword.)

For some (or even most) extended integer types it could make
sense to refer to them by means of an inplementation-defined
keyword denoting the type in question.  But there isn't any
reason to do so if the type is normally referred to by a
standard name like size_t, especially if system headers are
not regular source files but some special internal format
that the compiler knows about.

> If an implementation used an extension to define size_t without
> using "typedef", I'd have difficulty arguing that it's
> non-conforming -- but it still quacks like a typedef.

It differs in one significant respect:  no other name for the
type must be given.

> I suspect the authors of the standard assumed size_t is a typedef
> and didn't bother saying so explicitly.

Certainly that is possible.  IMO it is just as possible that they
decided deliberately not to say anything one way or the other, to
impose as few constraints as possible on the structure of
implementation internals, particularly for system headers.

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

#61883

From	glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date	2015-05-12 05:50 +0000
Message-ID	<mis4as$48i$1@speranza.aioe.org>
In reply to	#61877

Tim Rentsch <txr@alumni.caltech.edu> wrote:
> Keith Thompson <kst-u@mib.org> writes:

(snip)
>> You're right, size_t doesn't *necessarily* have to be a typedef.

(snip)
>> The only way to define size_t in standard C is to use a typedef --
>> but standard headers aren't restricted to using standard C.  Using
>> an extension would be permissible.

>> I think it still has to be equivalent to some named predefined
>> type.
 
> I agree that size_t must refer to a particular (ie, predefined)
> type - if not a standard integer type then an extended integer
> type.  I just don't find anything in the Standard that implies
> that type has to have a name other than (in this case) size_t.
> Why couldn't the name just be size_t?  There would need to be a
> way to declare the name, but that could be done using a reserved
> keyword or #pragma.

OK, say, for example, a system where short is 16 bits, int
and long are 32 bits. Also, consider that size_t
might work just fine at 24 bits. 

If 24 bits could be done faster than 32, it seems reasonable
to use it.

-- glen

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

#61912

From	Keith Thompson <kst-u@mib.org>
Date	2015-05-12 10:05 -0700
Message-ID	<877fsdg205.fsf@kst-u.example.com>
In reply to	#61883

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Keith Thompson <kst-u@mib.org> writes:
> (snip)
>>> You're right, size_t doesn't *necessarily* have to be a typedef.
>
> (snip)
>>> The only way to define size_t in standard C is to use a typedef --
>>> but standard headers aren't restricted to using standard C.  Using
>>> an extension would be permissible.
>
>>> I think it still has to be equivalent to some named predefined
>>> type.
>  
>> I agree that size_t must refer to a particular (ie, predefined)
>> type - if not a standard integer type then an extended integer
>> type.  I just don't find anything in the Standard that implies
>> that type has to have a name other than (in this case) size_t.
>> Why couldn't the name just be size_t?  There would need to be a
>> way to declare the name, but that could be done using a reserved
>> keyword or #pragma.
>
> OK, say, for example, a system where short is 16 bits, int
> and long are 32 bits. Also, consider that size_t
> might work just fine at 24 bits. 
>
> If 24 bits could be done faster than 32, it seems reasonable
> to use it.

Sure -- and one reasonable way to do that would be to define an
extended integer type, say `__int24`, and then have

    typedef size_t unsigned __int24;

in <stddef.h>.

But if 24-bit integers are faster than 32-bit integers, and are
useful for representing object sizes, it could also make sense to
make one of the standard integer types 24 bits (say, 16-bit short,
24-bit int, 32-bit long).  On the other hand, the limited number
of standard integer types might make that awkward.

-- 
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]

#61918

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2015-05-12 11:10 -0700
Message-ID	<kfnvbfxbra4.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#61912

Keith Thompson <kst-u@mib.org> writes:

> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>>> Keith Thompson <kst-u@mib.org> writes:
>>
>> (snip)
>>
>>>> You're right, size_t doesn't *necessarily* have to be a typedef.
>>
>> (snip)
>>
>>>> The only way to define size_t in standard C is to use a typedef --
>>>> but standard headers aren't restricted to using standard C.  Using
>>>> an extension would be permissible.
>>>>
>>>> I think it still has to be equivalent to some named predefined
>>>> type.
>>>
>>> I agree that size_t must refer to a particular (ie, predefined)
>>> type - if not a standard integer type then an extended integer
>>> type.  I just don't find anything in the Standard that implies
>>> that type has to have a name other than (in this case) size_t.
>>> Why couldn't the name just be size_t?  There would need to be a
>>> way to declare the name, but that could be done using a reserved
>>> keyword or #pragma.
>>
>> OK, say, for example, a system where short is 16 bits, int
>> and long are 32 bits.  Also, consider that size_t
>> might work just fine at 24 bits. 
>>
>> If 24 bits could be done faster than 32, it seems reasonable
>> to use it.
>
> Sure -- and one reasonable way to do that would be to define an
> extended integer type, say `__int24`, and then have
>
>     typedef size_t unsigned __int24;
>
> in <stddef.h>.

Presumably you meant to say that the other way around.

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

Page 1 of 3 [1] 2 3 Next page →

csiph-web

Could you please discuss whether casting a size_t variable to unsigned int variable is the correct way to handle...

Contents

#61737 — Could you please discuss whether casting a size_t variable to unsigned int variable is the correct way to handle...

#61740

#61745

#61753

#61763 — Re: Could you please discuss whether casting a size_t variable to unsigned int variable is the correct way to handle...

#61766

#61773

#61776

#61778

#61782

#61780

#61784

#61789

#61792 — Re: Could you please discuss whether casting a size_t variable to unsigned int variable is the correct way to handle...

#61822

#61834

#61877

#61883

#61912

#61918