Sizeof int

[write2gops]

Hi,

Is there a way to change the sizeof int type? Is it posible to make it
return 3 or 5 by changing some header file in the compiler?

Thanks in advance.

 

[sandy]

Hi,

Is there a way to change the sizeof int type? Is it posible to make it

No there is no ways, by whihc you can change the size of the int from
your program.
Well, The size of int depends upon the size of word on the machine and
is very much architecture dependent.

return 3 or 5 by changing some header file in the compiler?

Ya you can surely do that by making changes or writing your own custom
compiler but on what machine would you execute the program,
The compiler is depending on the underlying machine, and doing so would
not make any sense.

Thanks in advance.

Cheers,
SandeepKsinha.

 

[Tom St Denis]

Hi,

Is there a way to change the sizeof int type? Is it posible to make it
return 3 or 5 by changing some header file in the compiler?

Supposing you could, why would you?

Tom

 

[Eric Sosman]

Supposing you could, why would you?

/* The high-precision calculations in this module
* need a 1000-bit signed integer, so ...
*/
#include <limits.h>
sizeof(int) = (1000 + CHAR_BIT - 1) / CHAR_BIT;
/*
* Ain't science wonderful?
*/

It doesn't work that way, though: sizeof just describes
the data types the implementation provides, but does not
control their characteristics. Similarly with CHAR_BIT and
the like: you cannot get "fat integers" by re-#defining
INT_MAX to a larger-than-usual number.

<off-topic>

The very first computer I ever programmed actually had
this ability! Integers were normally five decimal digits
wide, with values between -99999 and +99999, but at the drop
of an option card you could make them wider for more precision
or narrower for better storage economy. I'm pretty sure you
couldn't make them narrower than two digits (-99 to +99), but
I can no longer remember what the upper limit was. If there
was an upper limit, though, it was imposed by the compiler and
not by the underlying hardware: the machine itself was quite
happy to work on thousand-digit integers using the same
instructions as for five-digit values.

That was in the mid-1960's, using FORTRAN II on an IBM 1620.
It is a sign of how far we've advanced that we no longer have
this kind of flexibility and are instead made to lie in whatever
Procrustean bed some machine designer chooses to inflict on us ;-)

</off-topic>

 

[jacob navia]

Eric Sosman a écrit :

<off-topic>

The very first computer I ever programmed actually had
this ability! Integers were normally five decimal digits
wide, with values between -99999 and +99999, but at the drop
of an option card you could make them wider for more precision
or narrower for better storage economy. I'm pretty sure you
couldn't make them narrower than two digits (-99 to +99), but
I can no longer remember what the upper limit was. If there
was an upper limit, though, it was imposed by the compiler and
not by the underlying hardware: the machine itself was quite
happy to work on thousand-digit integers using the same
instructions as for five-digit values.

That was in the mid-1960's, using FORTRAN II on an IBM 1620.
It is a sign of how far we've advanced that we no longer have
this kind of flexibility and are instead made to lie in whatever
Procrustean bed some machine designer chooses to inflict on us ;-)

</off-topic>

This is still used today.

lcc-win32 provides a "bignums" package where you have to set
before any calculations are done how big an integer should be,
i.e. set the maximal precision of the package. I think Gnu's
multi-precision package has a similar stuff in it.

 

[Richard Heathfield]

jacob navia said:

lcc-win32 provides a "bignums" package where you have to set
before any calculations are done how big an integer should be,
i.e. set the maximal precision of the package.

That's a good reason to avoid it. Thanks for sharing.

 

[Tom St Denis]

This is still used today.

lcc-win32 provides a "bignums" package where you have to set
before any calculations are done how big an integer should be,
i.e. set the maximal precision of the package. I think Gnu's
multi-precision package has a similar stuff in it.

cough....

http://math.libtomcrypt.com

A *portable* public domain bignum library that doesn't need to know the
maximum precision at build time [well aside from the fact the array
size has to conform to C specs].

[OT boasting...] It also happens to be the bignum provider for the Tcl
scripting language.

No need for non-portable standards violating addons to compute bignums.

Tom

 

[Lars]

Eric Sosman a écrit :

We have much greater flexibility. We have languages with built-in
bignums; C just isn't one of them.

This is still used today.

lcc-win32 provides a "bignums" package where you have to set
before any calculations are done how big an integer should be,
i.e. set the maximal precision of the package. I think Gnu's
multi-precision package has a similar stuff in it.

GNU MP doesn't require a precision to be set beforehand. It
automatically resizes bignums.

 

[jacob navia]

Lars a écrit :

We have much greater flexibility. We have languages with built-in
bignums; C just isn't one of them.



GNU MP doesn't require a precision to be set beforehand. It
automatically resizes bignums.

From the GMP manual:

http://www.swox.com/gmp/manual/Memory-Management.html#Memory-Management

mpf_t variables, in the current implementation, use a fixed amount of
space, determined by the chosen precision and allocated at
initialization, so their size doesn't change.

 

[jacob navia]

Tom St Denis a écrit :

This is still used today.

lcc-win32 provides a "bignums" package where you have to set
before any calculations are done how big an integer should be,
i.e. set the maximal precision of the package. I think Gnu's
multi-precision package has a similar stuff in it.

cough....

http://math.libtomcrypt.com

A *portable* public domain bignum library that doesn't need to know the
maximum precision at build time [well aside from the fact the array
size has to conform to C specs].

cough cough

You write in your documentation:

/* init to a given number of digits */
int mp_init_size(mp_int *a, int size);
The mp init size function will initialize the integer and set the
allocated size to a given value.

The library from lcc-win32 does it in a global way, and not in
a per digit basis. That is the only difference.

 

[Barry Schwarz]

Hi,

Is there a way to change the sizeof int type? Is it posible to make it
return 3 or 5 by changing some header file in the compiler?

sizeof(int) is determined by the compiler you are using, subject to
the restraints in the standard (the only one that comes to mind is
that it be large enough to hold any integer in the range INT_MIN to
INT_MAX inclusive). It is usually related to some hardware
characteristics of the system the compiled object code is intended to
run on but that is a decision made by the compiler writer, taking into
account whatever factors he desires.

The standard does describe any method for changing the size of an int
but does not prohibit an implementation from providing one. If it
were possible , it would therefore be specific to your implementation
(and hopefully described in its documentation). However, it would be
off-topic here and you need to ask in a group where your compiler is
topical.

By the way, if you find a compiler that allows this, see if you can
find out how they make the run-time library flexible enough to deal
with it and what impact it has on performance.


Remove del for email

 

[Mark McIntyre]

Hi,

Is there a way to change the sizeof int type? Is it posible to make it
return 3 or 5 by changing some header file in the compiler?

The question doesn't make sense. The size of types depends on your
hardware and operating system.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Gordon Burditt]

Is there a way to change the sizeof int type? Is it posible to make it

The question doesn't make sense. The size of types depends on your
hardware and operating system.

Sometimes you do have a limited choice, and you can select a different
implementation with compiler flags or use a completely different
compiler. For example, Windows can run code with 16-bit ints or
32-bit ints (the choice also affects a number of other things like
pointer sizes. It also interacts with your choice of memory model).
A number of other platforms have choices of 32-bit vs. 64-bit code,
and this may or may not affect the size of int used.

Generally, you can't link code from the two implementations together
without a lot of effort. You probably need different sets of system
libraries for each implementation.

Gordon L. Burditt

 

[Tom St Denis]

You write in your documentation:

/* init to a given number of digits */
int mp_init_size(mp_int *a, int size);
The mp init size function will initialize the integer and set the
allocated size to a given value.

The library from lcc-win32 does it in a global way, and not in
a per digit basis. That is the only difference.

hehehe ... you're treading into my world now ...

"mp" stands for "multiple precision" as in the algorithms will adjust
the precision as required for you.

The "init_size" function is just for the cases where you know the size
of your numbers and want to avoid the realloc.

Tom

 

[Tom St Denis]

http://www.swox.com/gmp/manual/Memory-Management.html#Memory-Management

mpf_t variables, in the current implementation, use a fixed amount of
space, determined by the chosen precision and allocated at
initialization, so their size doesn't change.

mpf is for the floats. mpz_t is for integers and will grow as required
[GMP is one of the three math libs my crypto lib supports]

Tom

 

[Andrew Poelstra]

No there is no ways, by whihc you can change the size of the int from
your program.
Well, The size of int depends upon the size of word on the machine and
is very much architecture dependent.

C has no concept of "size of word".

Ya you can surely do that by making changes or writing your own custom
compiler but on what machine would you execute the program,

"you can surely"..."make changes [to the compiler]. I have reason to
doubt that that is a true statement.

The compiler is depending on the underlying machine, and doing so would
not make any sense.

Hardly. My version of gcc running on a i386 has a "long long" type of 64
bits, even though my underlying machine has no such type.

 

[Giorgio Silvestri]

The question doesn't make sense. The size of types depends on your
hardware and operating system.

Strictly speaking it depends by compiler, and ISO C of course!

With the same hw and OS I can write a compiler
with 39 bits for long and another compiler with
32 bits, always for long type.

Of course compilers listen the hw suggestion.


Giorgio Silvestri

 

[Kenneth Brody]

Hi,

Is there a way to change the sizeof int type? Is it posible to make it
return 3 or 5 by changing some header file in the compiler?

If the compiler supports it, yes. (However, how this is done is not
topical to clc. You would need to check the documentation for the
compiler on how to do this.) If the compiler doesn't support it, then
there is nothing you can do (short of using, or writing, a different
compiler) do get 3 or 5 byte ints.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Richard Tobin]

Well, The size of int depends upon the size of word on the machine and
is very much architecture dependent.

[/QUOTE]

C has no concept of "size of word".

I often find that to explain something you have to refer to concepts
not defined in ISO standards, don't you?

-- Richard

 

[jacob navia]

Tom St Denis a écrit :

http://www.swox.com/gmp/manual/Memory-Management.html#Memory-Management

mpf_t variables, in the current implementation, use a fixed amount of
space, determined by the chosen precision and allocated at
initialization, so their size doesn't change.

mpf is for the floats. mpz_t is for integers and will grow as required
[GMP is one of the three math libs my crypto lib supports]

Tom

Big numbers in lcc-win32 are ratios of two big integers, i.e.
floats. That is why it needs (as GMP) a size limit.