Path: ...!news.misty.com!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 20:59:10 +0000
Organization: A noiseless patient Spider
Lines: 68
Message-ID: <vrhviu$h5c$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>
 <vrh71t$3be42$1@dont-email.me> <874izntt5t.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 20 Mar 2025 21:59:11 +0100 (CET)
Injection-Info: dont-email.me; posting-host="b23726e8530270bdb8279be50ba9c02e";
	logging-data="17580"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/0KzgvQLnad7vL3PrOekJv"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:8t24fC32rpU20Pv4yF2yT14cf6U=
In-Reply-To: <874izntt5t.fsf@nosuchdomain.example.com>
Content-Language: en-GB
Bytes: 4076

On 20/03/2025 19:10, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
> [...]
>> 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.
> 
> Is it?  I don't recall seeing anyone other than you do that.

>> stdint.h et al are just ungainly bolt-ons, not fully supported by the
>> language.
> 
> No, they're fully supported by the language.  They've been in the ISO
> standard since 1999.

I don't think so. They are add-ons that could have been created in 
user-code even prior to C99 (user-defined typedefs for 64 bits would 
'need long long').

All that's happened is that 'stdint.h' has been blessed.

You wouldn't, in user-code, be able to invent new literal suffixes like 
-LL but for those new types.

And you wouldn't be able to get the *printf functions of your standard 
library to accept new format codes corresponding to those stdint types.

And in fact you can do neither of those things now; ergo they're not 
fully supported in the same way that 'char short int long' are.

>> 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.
> 
> If you're writing code for which that's a problem, you probably need to
> fix your code.
> 
>> 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.
> 
> Somebody writing blatantly non-portable code will run into problems when
> they try to port it.
> 
> I understand that you dislike <stdint.h>.  That's both perfectly
> acceptable and not very interesting.

I dislike it because this stuff it is not hard to do in a language with 
full support, but C always seems to make a dog's dinner of it:

               C                    Other (example)

Declare       uint64_t x;          u64 x
Literal       UINT64_C(123);       123
Print         printf(PRI64d, x);   print x
(Alt?)        printf("I64d", x);
Max of type   UINT64_MAX           u64.max
Max of expr   (1)                  x.max
Read          scanf(SCNd64...)     read x

Requires:     stdio.h                          (for printf/scanf)
               stdint.h                         (for uint64_t/UINT64_C)
               inttypes.h                       (for PRI64d/SCNd64)

((1) I believe not possible without using 'typeof' and _Generic to emulate)