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

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

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.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca