Discussion:
remark on defining size of basic types
(too old to reply)
fir
2024-04-03 23:34:48 UTC
Permalink
here is a problem in using 64 big ints on windows
(at least to me its a problem - there are few options
etc, being not sure how it works etc) and how much
more easy and good it would be if long would just have 64
bits

the conclusion is - whouldnt just compilers offer
a way of defining it how long long int shorts
are ? imo it should be much better andportability of
codes probably would be increased
Lawrence D'Oliveiro
2024-04-04 00:15:54 UTC
Permalink
here is a problem in using 64 big ints on windows ...
#include <stdint.h>

int64_t signed_64bit_int;
uint64_t unsigned_64bit_int;
fir
2024-04-04 01:46:46 UTC
Permalink
Post by Lawrence D'Oliveiro
here is a problem in using 64 big ints on windows ...
#include <stdint.h>
int64_t signed_64bit_int;
uint64_t unsigned_64bit_int;
maybe but thats not the point
i mean if types (like int.long) vary on different machines
and programmers use them - wouldnt it to be better to
allow redefine them like in compiler commandline
liek -long=64 -long=32 , something like that?

(i find it as not much interesting remark, but wonder it that wouldnt be
more logical)
Lawrence D'Oliveiro
2024-04-04 02:44:17 UTC
Permalink
Post by fir
Post by Lawrence D'Oliveiro
here is a problem in using 64 big ints on windows ...
#include <stdint.h>
int64_t signed_64bit_int;
uint64_t unsigned_64bit_int;
maybe but thats not the point
If you want specific-sized types, that’s the standard C mechanism for
providing them.
fir
2024-04-04 11:32:52 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by fir
Post by Lawrence D'Oliveiro
here is a problem in using 64 big ints on windows ...
#include <stdint.h>
int64_t signed_64bit_int;
uint64_t unsigned_64bit_int;
maybe but thats not the point
If you want specific-sized types, that’s the standard C mechanism for
providing them.
ok, but my point is maybe the convention to use that standard ones char
short int long and allowing them to be set (overwiitting defaults) from
the command line would/wouldnt be just better

someone can think here what they want, but i just wanted to pint that
idea (for eventuall discussion if someone wants)
Janis Papanagnou
2024-04-04 13:15:26 UTC
Permalink
Post by fir
Post by Lawrence D'Oliveiro
Post by fir
Post by Lawrence D'Oliveiro
here is a problem in using 64 big ints on windows ...
#include <stdint.h>
int64_t signed_64bit_int;
uint64_t unsigned_64bit_int;
maybe but thats not the point
If you want specific-sized types, that’s the standard C mechanism for
providing them.
ok, but my point is maybe the convention to use that standard ones char
short int long and allowing them to be set (overwiitting defaults) from
the command line would/wouldnt be just better
someone can think here what they want, but i just wanted to pint that
idea (for eventuall discussion if someone wants)
*If* the size matters you should/could use the sized data types that
you see above. If size doesn't matter, why redefine the basic types?

Since I remember C had always just defined a '<=' (or '>=') relation
between the unsized basic integral data types.

You may want to explain what (positive) effect you expect from such
a language change or feature. (And consider what drawbacks and issues
would be accompanied with it.)

Sometimes it's useful to have an unbounded or parameterized integral
data type available - this is what I initially thought your thread
might be about - and some language (not C) do support that.

Janis
James Kuyper
2024-04-04 16:02:16 UTC
Permalink
On 4/4/24 09:15, Janis Papanagnou wrote:
...
Post by Janis Papanagnou
Since I remember C had always just defined a '<=' (or '>=') relation
between the unsized basic integral data types.
There's several things not quite right about the form of that sentence,
so I'm not quite sure what you meant to say, but C originally defined
the relational operators for any arithmetic type (and for pointers to
compatible object types), including the unsigned types..

Some complications have been added since then. When extended integer
types and _Bool were added, the definitions were adjusted so that the
integer promotion rules apply to _Bool, and extended integer types are
included along with other integer types. When _Complex and _Imaginary
were added, the operands to the relational operators were explicitly
required to be real (which, as C defines the term, includes all integer
types). When decimal floating types were introduced, they added a
prohibition on comparing such values with values that had a standard
floating types. However, nothing matching the restrictions you imply has
ever been true.
Michael S
2024-04-04 17:04:54 UTC
Permalink
On Thu, 4 Apr 2024 12:02:16 -0400
Post by James Kuyper
...
Post by Janis Papanagnou
Since I remember C had always just defined a '<=' (or '>=') relation
between the unsized basic integral data types.
There's several things not quite right about the form of that
sentence, so I'm not quite sure what you meant to say, but C
originally defined the relational operators for any arithmetic type
(and for pointers to compatible object types), including the unsigned
types..
Some complications have been added since then. When extended integer
types and _Bool were added, the definitions were adjusted so that the
integer promotion rules apply to _Bool, and extended integer types are
included along with other integer types. When _Complex and _Imaginary
were added, the operands to the relational operators were explicitly
required to be real (which, as C defines the term, includes all
integer types). When decimal floating types were introduced, they
added a prohibition on comparing such values with values that had a
standard floating types. However, nothing matching the restrictions
you imply has ever been true.
He meant sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long
long)
Keith Thompson
2024-04-04 20:10:16 UTC
Permalink
Michael S <***@yahoo.com> writes:
[...]
Post by Michael S
He meant sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long
long)
Which isn't *strictly* true. The relationships are defined in terms of
ranges, so for example INT_MAX <= LONG_MAX. A weird but conforming
implementation with padding bits could have sizeof (int) > sizeof
(long). (As far as I know no such implementation exists.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+***@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
Janis Papanagnou
2024-04-05 00:04:59 UTC
Permalink
Post by Michael S
On Thu, 4 Apr 2024 12:02:16 -0400
...
Post by Janis Papanagnou
Since I remember C had always just defined a '<=' (or '>=') relation
between the unsized basic integral data types.
[...]
He meant sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long
long)
Yes, indeed I meant the size of the data types. The comparison
operators of the _values_ of data types wouldn't quite fit on
the topic at all, or so I thought. (Sorry for potentially bad
wording and any possible misinterpretation.)

I thought I've read about those properties at K&R times, that
these properties would hold, but a quick look into some old C
and UNIX books did not show that; only a comment that 'short'
is not larger than 'long'. But I found it in Stroustrup's C++
language book.

Not sure whether that's formally standardized for C.

Janis
James Kuyper
2024-04-05 04:43:22 UTC
Permalink
...
Post by Janis Papanagnou
Post by Michael S
He meant sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long
long)
Yes, indeed I meant the size of the data types. The comparison
operators of the _values_ of data types wouldn't quite fit on
the topic at all, or so I thought. (Sorry for potentially bad
wording and any possible misinterpretation.)
I thought I've read about those properties at K&R times, that
these properties would hold, but a quick look into some old C
and UNIX books did not show that; only a comment that 'short'
is not larger than 'long'. But I found it in Stroustrup's C++
language book.
Not sure whether that's formally standardized for C.
Restrictions on the representable ranges (NOT the sizes) of
various integer types are formally imposed by the standard. My response
to Michael's message lists those restrictions in terms of the limit
macros, though that's not how the standard expresses the requirements.
James Kuyper
2024-04-04 23:39:00 UTC
Permalink
Post by Michael S
On Thu, 4 Apr 2024 12:02:16 -0400
...
Post by Janis Papanagnou
Since I remember C had always just defined a '<=' (or '>=') relation
between the unsized basic integral data types.
...
Post by Michael S
He meant sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long
long)
That's not actually the case. In the above, you are not using <= as the
C operator, but simply to indicate relative order over multiple items; I
will do the same. What is specified is equivalent to the following

LONGLONG_MIN <= LONG_MIN <= INT_MIN <= SHORT_MIN <= SCHAR_MAX
SCHAR_MAX <= SHORT_MAX <= INT_MAX <= LONG_MAX <= LONGLONG_MAX
UCHAR_MAX <= USHORT_MAX <= UINT_MAX <= ULONG_MAX <= ULONGLONG_MAX

SCHAR_MAX <= UCHAR_MAX
INT_MAX <= UINT_MAX
LONG_MAX <= ULONG_MAX
LONGLONG_MAX <= ULONGLONG_MAX

The sizes are not required to be in the same order as the maximum
values, nor in the opposite order of the minimum values. If they were in
a different order, it would imply a lot of padding bits, which would be
very odd, but not prohibited.
Keith Thompson
2024-04-05 05:22:23 UTC
Permalink
Post by James Kuyper
Post by Michael S
On Thu, 4 Apr 2024 12:02:16 -0400
...
Post by Janis Papanagnou
Since I remember C had always just defined a '<=' (or '>=') relation
between the unsized basic integral data types.
...
Post by Michael S
He meant sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long
long)
That's not actually the case. In the above, you are not using <= as the
C operator, but simply to indicate relative order over multiple items; I
will do the same. What is specified is equivalent to the following
LONGLONG_MIN <= LONG_MIN <= INT_MIN <= SHORT_MIN <= SCHAR_MAX
SCHAR_MAX <= SHORT_MAX <= INT_MAX <= LONG_MAX <= LONGLONG_MAX
UCHAR_MAX <= USHORT_MAX <= UINT_MAX <= ULONG_MAX <= ULONGLONG_MAX
SCHAR_MAX <= UCHAR_MAX
INT_MAX <= UINT_MAX
LONG_MAX <= ULONG_MAX
LONGLONG_MAX <= ULONGLONG_MAX
SHRT, not SHORT.
LLONG, not LONGLONG.
Post by James Kuyper
The sizes are not required to be in the same order as the maximum
values, nor in the opposite order of the minimum values. If they were in
a different order, it would imply a lot of padding bits, which would be
very odd, but not prohibited.
For completeness, the way it's described in the standard (quoting N3220
6.2.5p10-11) is :

For any two integer types with the same signedness and different
integer conversion rank (see 6.3.1.1), the range of values of the
type with smaller integer conversion rank is a subrange of the
values of the other type.

The range of nonnegative values of a signed integer type is a
subrange of the corresponding unsigned integer type, and the
representation of the same value in each type is the same.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+***@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
Lawrence D'Oliveiro
2024-04-04 23:38:18 UTC
Permalink
Post by Janis Papanagnou
Sometimes it's useful to have an unbounded or parameterized integral
data type available ...
Interestingly, Fortran (of all things) has that.
Janis Papanagnou
2024-04-05 00:25:22 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by Janis Papanagnou
Sometimes it's useful to have an unbounded or parameterized integral
data type available ...
Interestingly, Fortran (of all things) has that.
Was that the e.g. '*8' syntax? - Did it allow arbitrary lengths?
I thought you could select only from few supported ranges (like,
the C scalar types, but declared as *1, *2, *4, *8, and that's
it). (I have only faint memories about Fortran, did not use it
for long.)

In Pascal you could define subranges, but I think also only on a
fixed integral base type, and Ada seems to have a similar concept.

But GNU Awk supports multiple precision arithmetic, optionally.
(No explicit data type, though.)

I'm reluctant[*] to say that I think Cobol[**] as well has such a
feature. And I think it had no size restriction on a machine word
as the other languages mentioned above. - Is that correct?

(That language feature might have got out of fashion long ago?)

Janis

[*] Some folks here might feel offended by mentioning Cobol again.

[**] A language I never programmed myself in.
Lawrence D'Oliveiro
2024-04-05 00:46:52 UTC
Permalink
Post by Janis Papanagnou
Post by Lawrence D'Oliveiro
Post by Janis Papanagnou
Sometimes it's useful to have an unbounded or parameterized integral
data type available ...
Interestingly, Fortran (of all things) has that.
Was that the e.g. '*8' syntax? - Did it allow arbitrary lengths?
No, and no. Since Fortran 2003, you can parameterize a custom type
definition with integer values. These can be used to specify the sizes of
arrays, or they can be used as codes for the different (implementation-
defined) precisions of integer and real types. An example from the
language spec:

TYPE :: t1(k1,k2)
INTEGER, KIND :: k1,k2
REAL(k1) a(k2)
END TYPE

This defines a custom type “t1”, which is an array of reals; the first
parameter determines the precision of the reals, and the second one
specifies the length of the array.

There are various query mechanisms (built-in functions, standard modules)
to determine the valid values of the number-precision codes.
Janis Papanagnou
2024-04-05 06:30:16 UTC
Permalink
Post by Janis Papanagnou
Post by Lawrence D'Oliveiro
Post by Janis Papanagnou
Sometimes it's useful to have an unbounded or parameterized integral
data type available ...
Interestingly, Fortran (of all things) has that.
Was that the e.g. '*8' syntax? - Did it allow arbitrary lengths?
No, and no. Since Fortran 2003, [...]
For the first question I thought you were referring to old Fortran
versions - I certainly was referring to that syntax, and I see that
my memories were correct -, where you can find types like INTEGER*1,
INTEGER*2, INTEGER*5, INTEGER*8 (see e.g. [*], Table 11 on page 17).

[*] https://docs.nvidia.com/hpc-sdk/pgi-compilers/17.9/pdf/pgi17fortref.pdf
you can parameterize a custom type
definition with integer values. These can be used to specify the sizes of
arrays, or they can be used as codes for the different (implementation-
defined) precisions of integer and real types. An example from the
TYPE :: t1(k1,k2)
INTEGER, KIND :: k1,k2
REAL(k1) a(k2)
END TYPE
This defines a custom type “t1”, which is an array of reals; the first
parameter determines the precision of the reals, and the second one
specifies the length of the array.
There are various query mechanisms (built-in functions, standard modules)
to determine the valid values of the number-precision codes.
Yes, but I read that 'KIND' specification as a readable variant
of the old syntax where you can also just select between a couple
standard sizes for integers (like SHORT, LONG, etc.).

(But I'm not much interested in Fortran, and we're off-topic.)

Janis
Lawrence D'Oliveiro
2024-04-05 07:18:09 UTC
Permalink
Post by Janis Papanagnou
For the first question I thought you were referring to old Fortran
versions ...
I did say “has”, not “had”.
Post by Janis Papanagnou
Yes, but I read that 'KIND' specification as a readable variant of the
old syntax ...
It’s parameterizable. That means it is easy to change the precision of the
type right through your code just by altering one definition.

Also, KIND participates in function overloading. That requires it to be
compile-time constant. There are also LEN parameters, which can be
dynamic, but can only be used to size arrays and strings.
Michael S
2024-04-05 14:19:26 UTC
Permalink
On Fri, 5 Apr 2024 07:18:09 -0000 (UTC)
Post by Lawrence D'Oliveiro
Post by Janis Papanagnou
For the first question I thought you were referring to old Fortran
versions ...
I did say “has”, not “had”.
Post by Janis Papanagnou
Yes, but I read that 'KIND' specification as a readable variant of
the old syntax ...
It’s parameterizable. That means it is easy to change the precision
of the type right through your code just by altering one definition.
Also, KIND participates in function overloading. That requires it to
be compile-time constant. There are also LEN parameters, which can be
dynamic, but can only be used to size arrays and strings.
I still think that Janis asked correct questions and that you answered
misleading answers.
I had never read the Fortran-2003 Standard, however I will be very
surprised if it mandates support for integer types wider than 64 bits
(or 18 decimal digits). I would not be surprised if hard mandate is
even lower, may be only 9 digits.
Also I would be surprised if there are implementations that support
integers that are wider than 128 bits (38 digits).
Keith Thompson
2024-04-05 15:07:03 UTC
Permalink
Post by Michael S
On Fri, 5 Apr 2024 07:18:09 -0000 (UTC)
Post by Lawrence D'Oliveiro
Post by Janis Papanagnou
For the first question I thought you were referring to old Fortran
versions ...
I did say “has”, not “had”.
Post by Janis Papanagnou
Yes, but I read that 'KIND' specification as a readable variant of
the old syntax ...
It’s parameterizable. That means it is easy to change the precision
of the type right through your code just by altering one definition.
Also, KIND participates in function overloading. That requires it to
be compile-time constant. There are also LEN parameters, which can be
dynamic, but can only be used to size arrays and strings.
I still think that Janis asked correct questions and that you answered
misleading answers.
I had never read the Fortran-2003 Standard, however I will be very
surprised if it mandates support for integer types wider than 64 bits
(or 18 decimal digits). I would not be surprised if hard mandate is
even lower, may be only 9 digits.
Also I would be surprised if there are implementations that support
integers that are wider than 128 bits (38 digits).
Post by Lawrence D'Oliveiro
Sometimes it's useful to have an unbounded or parameterized integral
data type available ...
Interestingly, Fortran (of all things) has that.
As far as I can tell, Fortran has parameterized integral types, but not
unbounded integral types.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+***@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
Kenny McCormack
2024-04-05 02:56:26 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by Janis Papanagnou
Sometimes it's useful to have an unbounded or parameterized integral
data type available ...
Interestingly, Fortran (of all things) has that.
GAWK has it (*) - when run with -M.

(*) Or at least it did. Latest scuttlebut is they might be removing it.
--
Modern Conservative: Someone who can take time out from flashing her
wedding ring around and bragging about her honeymoon to complain that a
fellow secretary who keeps a picture of her girlfriend on her desk is
"flauting her sexuality" and "forcing her lifestyle down our throats".
Loading...