Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?)

On 24.03.2025 17:14, Scott Lurndal wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 20.03.2025 16:11, bart wrote:

On 20/03/2025 14:32, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 20/03/2025 13:36, Scott Lurndal wrote:

then it's surprisingly rare in source code.

>
Long is useless, because Microsoft made the mistake of defining
'long' as 32-bits on 64-bit architectures, while unix and linux
define it as 64-bits.

>
Unix and Linux define it as 32 bits on 32-bit architectures and 64 bits
on 64-bit ones.

>
That's what I said.  Thanks for the confirmation.  It doesn't change
the fact that Microsoft didn't define long as 64-bit on 64-bit
architectures,
creating incompatibilities that didn't exist in the 32-bit world
between the two dominant operating systems.
>
Remainder of bart's typical windows-centric complaints elided.
>

>
But your typical anti-Microsoft remarks are fine? Since you called it a
'mistake' to keep 'long' the same between 32/64-bit machines, even
though both OSes kept 'int' the same.

>
Many things (more or less related) come to my mind when reading that.
>
Of primary interest here is certainly what the "C" standard defines.
It's not that enlightening (IMO) what Microsoft did/does (or Linux);
these are just two [common contemporary] examples.
>
When I started with "C" or C++ there were not only 8-bit multiples
defined for the integral types; there were 9 bit or 36 bit entities
on some machines. And a 'int' type could be 16 or 32 bit (or 36 bit);
'int' reflected (sort of) the "machine register size". And the other
types were woven around; 'short' not larger than 'int', 'long' not
smaller than 'int'. Optimization considerations made it possible to
have just a single actual size for all numeric integral types' sizes.
>
Unless you are focused with your development on just a single machine
architecture you may choose the appropriate types with their specific
"C" language names.
>
In our application cases we needed certainty about actual sizes, so
(as many others did) we introduced our own types; like the entities
that you find now defined in "types.h". (Back these days there was
no "types.h" available.)

 
When would that have been?

Oh, right! - It was existing, and we were actually also using it;
there's a couple types we needed. (Thanks for catching that.)

I don't think it had all the sized types like 'u_int8_t' defined.
Or did we all just miss it back these days to have it reimplemented
like so many did?

Janis

 
/work/reference/usl/unix/v7/usr/include/sys/types.h
 
stdint.h came much later.
 
v7 types.h:
 
typedef long            daddr_t;        /* disk address */
typedef char *          caddr_t;        /* core address */
typedef unsigned int    ino_t;          /* i-node number */
typedef long            time_t;         /* a time */
typedef int             label_t[6];     /* program status */
typedef int             dev_t;          /* device code */
typedef long            off_t;          /* offset in file */
        /* selectors and constructor for device code */
#define major(x)        (int)(((unsigned)x>>8))
#define minor(x)        (int)(x&0377)
#define makedev(x,y)    (dev_t)((x)<<8|(y))