Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Suggested method for returning a string from a C program?
Date: Thu, 20 Mar 2025 14:00:29 +0000
Organization: A noiseless patient Spider
Lines: 73
Message-ID: <vrh71t$3be42$1@dont-email.me>
References: <vrd77d$3nvtf$2@dont-email.me> <868qp1ra5f.fsf@linuxsc.com>
 <vrdhok$47cb$2@dont-email.me> <20250319115550.0000676f@yahoo.com>
 <vreuj1$1asii$4@dont-email.me> <vreve4$19klp$2@dont-email.me>
 <20250319201903.00005452@yahoo.com> <86r02roqdq.fsf@linuxsc.com>
 <vrh1br$35029$2@dont-email.me> <LRUCP.2$541.0@fx47.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 20 Mar 2025 15:00:30 +0100 (CET)
Injection-Info: dont-email.me; posting-host="b23726e8530270bdb8279be50ba9c02e";
	logging-data="3520642"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX189+XYJJAbG0X6XucJB+TRQ"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:K9Xn6Q4Jcd7r61l8oBCS4m5a6hw=
In-Reply-To: <LRUCP.2$541.0@fx47.iad>
Content-Language: en-GB
Bytes: 4069

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.