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

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.
As defined by Microsoft, long is portable between Windows OSes even on different architectures.
   'long long' is defined as a 64-bit

type in both Windows and Linux.
 Using the defined width types is far better (e.g. uint64_t);
even if the standard allows the type to not exist on a particular
implementation.  No useful implementation would fail to define
uint64_t in these modern times.

The point was made earlier on that int64_t types are awkward to work with; they need that stdint.h header to even exist, and they need those ugly macros in inttypes.h to print out their values.
This is why it popular to just do:
   typedef long long int i64;
and to use %lld to print, and -LL on literals to force a 64-bit type.
stdint.h et al are just ungainly bolt-ons, not fully supported by the language.
The problem with 'long' manifests itself there too, since on Linux, 'int64_t' appears to be commonly defined on top of 'long' for 32-bit systems, and 'long long' for 64-bit ones.
So somebody eschewing those ugly macros and using "%ld" to print an 'int64_t' type, will find it doesn't work when run on a 64-bit system, where "%lld" is needed. Same problem with using '1L' to define an int64_t literal.