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: Sat, 22 Mar 2025 16:25:33 +0000
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <vrmo9s$933o$2@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> <vrk8vm$2f4gc$1@paganini.bofh.team>
 <vrkulk$2k04q$1@dont-email.me> <vrl4g4$2lf61$1@paganini.bofh.team>
 <2JzDP.1208306$_N6e.1205396@fx17.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 22 Mar 2025 17:25:33 +0100 (CET)
Injection-Info: dont-email.me; posting-host="3a1b95dc012bf976b84f52de7f297e21";
	logging-data="298104"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX188Y3Op1Azz191aYOTY7qoe"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:pGKMC6JjLexySPcRX1L0b2+C61Q=
Content-Language: en-GB
In-Reply-To: <2JzDP.1208306$_N6e.1205396@fx17.iad>
Bytes: 3167

On 22/03/2025 14:22, Scott Lurndal wrote:
> antispam@fricas.org (Waldek Hebisch) writes:
>> bart <bc@freeuk.com> wrote:
>>> On 21/03/2025 17:51, Waldek Hebisch wrote:
>>>> bart <bc@freeuk.com> wrote:
> 
>>> (Probably intptr_t or ssize_t is better for
>>> that purpose, and will be portable between Windows and Linux.)
>>
>> Those did not exist in 1991 and would be needed only for small
>> machines.  Except for Microsoft which decided to push its own,
>> different way.
> 
> ssize_t existed in before 1990 (in SVR4).   intptr_t came later.
> 
> $ grep ssize_t common/head/*
> common/head/aio.h:  ssize_t            aio__return;    /* operation result value       */
> common/head/unistd.h:extern ssize_t    read(int, void *, size_t);
> common/head/unistd.h:extern ssize_t    write(int, const void *, size_t);
> 
> 
>>> 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.
>>
>> One 'con' of any assumption is that somebody can make a different
>> assumption.
> 
> Programmers shouldn't be making 'assumptions' in the first place.
> 
> The architectural ABI describes fully the capabilities of the
> native types.  If the programmer isn't aware of that, they
> shouldn't be programming.
> 

This is 'making assumptions' when the code is subsequently run on a 
different platform.

And those assumptions made by a million programmers in myriad codebases 
are behind decisions on whether to increase 'int' and/or 'long' when 
implementing the language on a new architecture with wider types.