Path: ...!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: Fri, 21 Mar 2025 01:23:12 +0000
Organization: A noiseless patient Spider
Lines: 118
Message-ID: <vrif1v$c9ev$3@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>
 <vrhviu$h5c$1@dont-email.me> <87ecyrs332.fsf@nosuchdomain.example.com>
 <vri9t1$a29t$1@dont-email.me> <20250320171505.221@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 21 Mar 2025 02:23:11 +0100 (CET)
Injection-Info: dont-email.me; posting-host="01edc3bdc8bae69ef7cb5aa841da74a4";
	logging-data="402911"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+DbgWvBm5ZOXKS2p4KCS9T"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:y0xP31SXRfI9K9NMC9GbLdJDXNs=
Content-Language: en-GB
In-Reply-To: <20250320171505.221@kylheku.com>
Bytes: 6026

On 21/03/2025 00:46, Kaz Kylheku wrote:
> On 2025-03-20, bart <bc@freeuk.com> wrote:
>> On 20/03/2025 23:18, Keith Thompson wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 20/03/2025 19:10, Keith Thompson wrote:
>>>>> bart <bc@freeuk.com> writes:
>>> [...]
>>>>>> 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').
>>>
>>> Sure, they could; see Doug Gwyn's q8, for example.
>>
>> Isn't that what I said? However I've just looked at this 700-line header:
>>
>>    https://www.lysator.liu.se/c/q8/stdint.h
>>
>> Sorry, but there's something wrong if you have to write all that to get
>> a handful of fixed-width types.
> 
> That's not all that is needed; the material in Q8defs.h is required
> to make the material in the above file work.
> 
> It's not just the types, but all the standard-required identifiers.
> 
> I feel that this Q8 could probably have been organized a little
> differently to make it more compact.
> 
> The Q8defs.h header already has conditionals for platforms.
> Then Q8's inttypes.h still has to switch on some more abstract
> conditions in the preprocessor to select the types.
> 
> This two layer business could just be one, more or less.
> Q8defs.h could just define, for instance, q8_uintptr_t,
> for each platform, and then inttypes just has to expose it under the
> standard name:
> 
> typedef q8_uintptr_t uintptr_t;
> 
>> (And if this is for a multitude of
>> targets, then there should be a dedicated header per target).
> 
> What? That would pretty much defeat the whole point of this Q8 library.
> 
> What would would select which file to use where?
> 
> You drop those files into your C90, and then you have a facsimile
> of C99 compatibility, on all the platforms supported by Q8.
> 
>> GCC's stdint.h is 200 lines. Mine is 75 lines. It these types were part
> 
> Q8 tries to add the C99 stuff for something like 7 implementations
> or implementation familes. GCC is one implementation, but with
> many targets.

I just tried to compile it; it needs an extra q8defs.h file (600 more 
lines), but it fails: "CPU not recognised" (it might have a point if 
this was from the 1990s!).

gcc just gives lots of errors. To me it's all an ugly lot of code which 
reminds me of what system headers looked like: a messy, fragile 
patchwork of #ifdef blocks.

>> of the core language, it would be zero lines.
> 
> This kind of argumentation is really not of good quality.
> 
> A feature requires lines of code. If those lines are not in some
> satellite file like a C header, then they are elsewhere, like in the
> compiler source code.

Doing stuff the C way requires LOTs of lines of code. Look at all those 
MIN/MAX macros, the PRINT/SCAN macros; there's hundreds of them!

In the compiler it can be compact (and faster, not having to parse such 
headers millions and millions of times), and if the language was done 
properly, much of it is not needed. For example I showed in another post 
that all MIN/MAX macros can be replaced with T.min and T.max, or 
equivalent syntax.

> It's not "zero lines" because you hid it in the compiler.

The compile has to cope with fundamental types anyway; there's a limit 
to what headers can do: they have to build on something.

This is about defining fixed-width types on top of the 
implementation-defined 'char short int long' types.

I've done this and it's usually a dozen lines. If it takes 1300 lines, 
then you need to look again:

  typedef signed char         i8;
  typedef short              i16;
  typedef int                i32;
  typedef long long          i64;

  typedef unsigned char       u8;
  typedef unsigned short     u16;
  typedef unsigned int       u32;
  typedef unsigned long long u64;

  typedef unsigned char     byte;

  typedef float              r32;
  typedef double             r64;

(This is used at the top of generated code, to keep the rest of it 
somewhat more compact and readable. Such a file actually uses zero 
headers including no standard headers.)

I don't bother with LEAST/FAST types, whatever those mean. Where did 
that all come from anyway? I've never seen those used.