Re: Suggested method for returning a string from a C program?

On 21/03/2025 18:51, Kaz Kylheku wrote:

On 2025-03-21, Waldek Hebisch <antispam@fricas.org> wrote:

bart <bc@freeuk.com> wrote:

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.

 The bitness of modern mainstream machines is their address size.
 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.)
 

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

 In Microsoft land, there is a LONG type, which is involved in
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).

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

There really isn't much in it. Here's the evolution as I see it (I stand to be corrected if necessary):
            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.