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

On 21/03/2025 17:51, Waldek Hebisch wrote:

bart <bc@freeuk.com> wrote:

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.

Which was not its intention. (Probably intptr_t or ssize_t is better for that purpose, and will be portable between Windows and Linux.)

As defined by Microsoft, long is portable between Windows OSes even on
different architectures.

 It gives 'long' different meaning than it had previously.

I explained the differences without necessarily saying one is better than the other. Sometimes one is more more useful, sometimes the other.

And to
that matters rather useless meaning, as already 'int' gives 32
bit integers on bigger machines.

Well, 'long' is also useless on 32-bit Linux machines as it is the same size as 'int'. Why didn't it also increase when 'int' migrated from i16 to i32?
One 'con' for Linux' approach is when someone assumes 'long' is i32; when they run code on 64 bits, it will either be wasteful, or it could go badly wrong.
While those running on Linux64 and expect 'long' to be double the width of 'int', may also experience failures on Linux32.
On Windows, you just learn to avoid 'long' completely. After all you don't need 5 basic types for four integer sizes!

 

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

Sorry, yes. But it shows how confusing it all is:
LL/ll is used for 64 bits on 32-bit systems
L/l   is used for 32 bits on 64-bit systems!
(I'm so glad I switched to all-64-bits in my own stuff, early last decade.
However lots of software has taken a long time to catch up. I acquired an RPi 4 board 5 years ago with a view to doing 64-bit ARM development, but most OSes were still 32 bits, and 64-bit ones immature. (You need a 64-bit OS to easily develop and run 64-bit programs.)
Even now, 32-bit OSes are supplied by default. I finally got a solid 64-bit OS for it last week. I just wondered what the point is of having 64-bit hardware if people just run 32-bit stuff on it.)

 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.
 

(I'll tell you a secret: my C compiler automatically reads a special header that includes these definitions:
   typedef signed char     i8;
   typedef short           i16;
   typedef int             i32;
   typedef long long int   i64;
   typedef unsigned char           u8;
   typedef unsigned char           byte;
   typedef unsigned short          u16;
   typedef unsigned int            u32;
   typedef unsigned long long int  u64;
   typedef float           r32;
   typedef double          r64;
It makes the writing of hundreds of small test programs so much easier. I wonder how many do the same, although they'd have to use a discrete header.)