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

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.

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.

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

 

<snip>

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.

You mixed up this: 'int64_t' is defined as 'long long' for 32-bit
systems and as 'long' for 64-bit ones.  Doing it as you wrote
would give you variable length type.  Of course, if you need
word-sized integer in Windows you may define it as 'long' for 32-bit
Windows and as 'long long' for 64-bit ones.

--
                              Waldek Hebisch