On 2025-03-21, Waldek Hebisch <antispam@fricas.org> wrote:Those types are an invention of Microsoft and only appear in WinAPIs. There seem to be hundreds of them, but they are well defined. Mostly they are consistent between 32- and 64-bit systems too.bart <bc@freeuk.com> wrote:The bitness of modern mainstream machines is their address size.On 20/03/2025 13:36, Scott Lurndal wrote:>bart <bc@freeuk.com> writes:>On 20/03/2025 12:09, Tim Rentsch wrote:>Michael S <already5chosen@yahoo.com> writes:>>I suspected that, but was not sure, so suggested to DFS a type that I am>
sure about.
The width of char and [un]signed char must be at least 8 bits.
The width of [un]signed short must be at least 16 bits.
The width of [un]signed int must be at least 16 bits.
The width of [un]signed long must be at least 32 bits.
The width of [un]signed long long must be at least 64 bits.
>
That should be easy enough to remember now.
That table suggests that any program mixing 'short' and 'int' is
suspect. If 'int' doesn't need to store values beyond 16 bits, then why
not use 'short'?
>
'long' is another troublesome one. If the need is for 32-bit values,
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.
>So long can't be used in programs intended to be portable to>
other operating systems.
As defined by Unix/Linux, long is not portable between different
Unix/Linux OSes if they run on a different architecture.
It portably between 32 and 64 bit machines gives word-sized
integer type.
C99 gaves us address-sized integers: intptr_t and uintptr_t.
If you want a 64 bit type on a 64 bit system and 32 bit type
on a 32 bit system, use those.
(The problem is that idea observed in Unix-like environments that long
is expected to be address-sized precedes C99.)
In Microsoft land, there is a LONG type, which is involved inAs defined by Microsoft, long is portable between Windows OSes even on>
different architectures.
It gives 'long' different meaning than it had previously. And to
that matters rather useless meaning, as already 'int' gives 32
bit integers on bigger machines.
the Win32 ABIs. That was their mistake.
In plenty of interfaces, Windows uses the types WORD and DWORD, which
are 16 and 32 bits wide unsigned types. (As well as QWORD,
a 64 bitter).
Since I've mostly used WinAPI via an FFI, I'm used to creating my own bindings and using my own aliases for this ttypes. (Mostly it comes down to one of i32 i64 u32 u64 plus a pointer type.)
The problem is, when someone needed the signed versions ofThere really isn't much in it. Here's the evolution as I see it (I stand to be corrected if necessary):
WORD and DWORD, they found them to be missing, and stupidly came up with
the names INT and LONG (and derived typedefs like LPARAM).
Nobody caught this code smell and so it got woven into the Windows API.
Probably long before 32 bit Windows, I'm guessing.
Thus, LONG has to continue to be a 32 bit type, since it is
used as a "signed DWORD".
But it's inconceivable for LONG to to be a typedef for anything other
than long. Too much code depends on the wrong idea that LONG and long
are interchangeable.
Thus long has to be stuck on 32 bits.
C-Windows C-Linux My stuff
Machine int long int long int 'dint'
16 bits 16 32 16 32 16 32
32 bits 32 32 32 32 32 64
64 bits 32 32 32 64 64 [128]
The most logical and consistent progression seems to be with 'my stuff'!Except I no longer support 128-bit types after doing so briefly.
The point is that there was usually a size exactly double the width of 'int', but it become less necessary when 'int' reached 64 bits.
| Date | Sujet | # | Auteur | |
| 22 Apr 26 |  … |
Les messages affichés proviennent d'usenet.