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

On Thu, 20 Mar 2025 13:36:43 GMT
scott@slp53.sl.home (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.
 
So long can't be used in programs intended to be portable to
other operating systems.  '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.
 

Unfortunately, gcc people made a mess out of it as well, defining (on
64-bit Linux platforms) int64_t/uint64_t as aliases to respective 'long'
types instead of aliasing them to 'long long', to be the same on all
platforms that matter.
I'd guess they were afraid of being accused of being sensible.