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

On Thu, 04 Apr 2024 01:34:48 +0200, fir wrote:

> here is a problem in using 64 big ints on windows ...

#include <stdint.h>

int64_t signed_64bit_int;
uint64_t unsigned_64bit_int;

Lawrence D'Oliveiro wrote:
> On Thu, 04 Apr 2024 01:34:48 +0200, fir wrote:
>
>> 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)

On Thu, 04 Apr 2024 03:46:46 +0200, fir wrote:

> Lawrence D'Oliveiro wrote:
>
>> On Thu, 04 Apr 2024 01:34:48 +0200, fir wrote:
>>
>>> 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.

Lawrence D'Oliveiro wrote:
> On Thu, 04 Apr 2024 03:46:46 +0200, fir wrote:
>
>> Lawrence D'Oliveiro wrote:
>>
>>> On Thu, 04 Apr 2024 01:34:48 +0200, fir wrote:
>>>
>>>> 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)

On 04.04.2024 13:32, fir wrote:
> Lawrence D'Oliveiro wrote:
>> On Thu, 04 Apr 2024 03:46:46 +0200, fir wrote:
>>
>>> Lawrence D'Oliveiro wrote:
>>>
>>>> On Thu, 04 Apr 2024 01:34:48 +0200, fir wrote:
>>>>
>>>>> 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

On 4/4/24 09:15, Janis Papanagnou wrote:
....
> 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.

On Thu, 4 Apr 2024 12:02:16 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

> On 4/4/24 09:15, Janis Papanagnou wrote:
> ...
> > 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)

Michael S <already5chosen@yahoo.com> writes:
[...]
> 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+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Thu, 4 Apr 2024 15:15:26 +0200, Janis Papanagnou wrote:

> Sometimes it's useful to have an unbounded or parameterized integral
> data type available ...

Interestingly, Fortran (of all things) has that.

On 04.04.2024 19:04, Michael S wrote:
> On Thu, 4 Apr 2024 12:02:16 -0400
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 4/4/24 09:15, Janis Papanagnou wrote:
>> ...
>>> 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

On 05.04.2024 01:38, Lawrence D'Oliveiro wrote:
> On Thu, 4 Apr 2024 15:15:26 +0200, Janis Papanagnou wrote:
>
>> 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.

On Fri, 5 Apr 2024 02:25:22 +0200, Janis Papanagnou wrote:

> On 05.04.2024 01:38, Lawrence D'Oliveiro wrote:
>
>> On Thu, 4 Apr 2024 15:15:26 +0200, Janis Papanagnou wrote:
>>
>>> 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.

In article <uundl9$ugsb$2@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Thu, 4 Apr 2024 15:15:26 +0200, Janis Papanagnou wrote:
>
>> 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".

On 4/4/24 13:04, Michael S wrote:
> On Thu, 4 Apr 2024 12:02:16 -0400
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>
>> On 4/4/24 09:15, Janis Papanagnou wrote:
>> ...
>>> 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)

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.

On 4/4/24 20:04, Janis Papanagnou wrote:
> On 04.04.2024 19:04, Michael S wrote:
....
>> 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 <jameskuyper@alumni.caltech.edu> writes:
> On 4/4/24 13:04, Michael S wrote:
>> On Thu, 4 Apr 2024 12:02:16 -0400
>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>
>>> On 4/4/24 09:15, Janis Papanagnou wrote:
>>> ...
>>>> 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)
>
> 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.

> 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+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 05.04.2024 02:46, Lawrence D'Oliveiro wrote:
> On Fri, 5 Apr 2024 02:25:22 +0200, Janis Papanagnou wrote:
>
>> On 05.04.2024 01:38, Lawrence D'Oliveiro wrote:
>>
>>> On Thu, 4 Apr 2024 15:15:26 +0200, Janis Papanagnou wrote:
>>>
>>>> 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
> 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.

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

On Fri, 5 Apr 2024 08:30:16 +0200, Janis Papanagnou wrote:

> For the first question I thought you were referring to old Fortran
> versions ...

I did say “has”, not “had”.

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

On Fri, 5 Apr 2024 07:18:09 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> On Fri, 5 Apr 2024 08:30:16 +0200, Janis Papanagnou wrote:
>
> > For the first question I thought you were referring to old Fortran
> > versions ...
>
> I did say “has”, not “had”.
>
> > 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).

Michael S <already5chosen@yahoo.com> writes:
> On Fri, 5 Apr 2024 07:18:09 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Fri, 5 Apr 2024 08:30:16 +0200, Janis Papanagnou wrote:
>>
>> > For the first question I thought you were referring to old Fortran
>> > versions ...
>>
>> I did say “has”, not “had”.
>>
>> > 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).

I think this was the source of some confusion :

On 05.04.2024 01:38, Lawrence D'Oliveiro wrote:
> On Thu, 4 Apr 2024 15:15:26 +0200, Janis Papanagnou wrote:
>
>> 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+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */