Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: "Chris M. Thomasson" Newsgroups: comp.lang.c Subject: Re: Suggested method for returning a string from a C program? Date: Sat, 22 Mar 2025 14:51:23 -0700 Organization: A noiseless patient Spider Lines: 64 Message-ID: References: <868qp1ra5f.fsf@linuxsc.com> <20250319115550.0000676f@yahoo.com> <20250319201903.00005452@yahoo.com> <86r02roqdq.fsf@linuxsc.com> <874izntt5t.fsf@nosuchdomain.example.com> <87ecyrs332.fsf@nosuchdomain.example.com> <20250320171505.221@kylheku.com> <8734f7rw7z.fsf@nosuchdomain.example.com> <87tt7mqk7w.fsf@nosuchdomain.example.com> <87cye9afl0.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 22 Mar 2025 22:51:25 +0100 (CET) Injection-Info: dont-email.me; posting-host="ddbd8dee764340b262a6f4719cfb8c95"; logging-data="858929"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX180tXxNTyO6ogITgh47WvBbyWhKo0pX1N4=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:N1XXfDBIm8kKOgrATrxnAlOFGI0= Content-Language: en-US In-Reply-To: Bytes: 4604 On 3/22/2025 6:06 AM, bart wrote: > On 22/03/2025 03:50, Keith Thompson wrote: >> bart writes: >>> On 21/03/2025 19:04, Keith Thompson wrote: >>>> bart writes: >>>>> On 21/03/2025 01:47, Keith Thompson wrote: >>>>>> bart writes: >>>>>> You're complaining about how much work it is.  All that work >>>>>> has been done for you by the implementers.  Decades ago. >>>>> >>>>> We are talking about defining types like 'int32' on top of 'char short >>>>> int long', yes? Then how difficult could it possibly be? >>>> If you want and headers that work correctly >>>> with all relevant compilers, it's not particularly easy.  I'll note >>>> that the MUSL implementation of is 117 lines, compared to >>>> 308 for GNU libc. >>>> >>>>>> I just did a quick test comparing complation times for an empty >>>>>> program with no #include directives and an empty program with >>>>>> #include directives for and .  The >>>>>> difference was about 3 milliseconds.  I quite literally could not >>>>>> care care less. >>>>> >>>>> I'm sorry but that's a really poor attitude, with bad >>>>> consequences. You're saying it doesn't matter how complex a header or >>>>> set of headers is, even when out of proportion to the task. >>>>> >>>>> But this is why we end up with such complicated headers. >>>> Complicated headers that work. >>>> [...\ >>>> >>>>> I think your response clarifies matters. Nobody cares, even as >>>>> compilers grind to a halt under all preprocessing. >>>> If compilers ground to a halt, I would certainly care.  They don't. >>> >>> 50 modules each including GTK.h say, which was 0.33Mloc across 500 >>> headers (so reading 16Mloc and 25,000 headers in total when all are >>> compiled) would not impact your builds at all? OK. >> >> First you talked about compilers grinding to a halt, then you talked >> about headers not impacting builds at all.  Those goalposts of yours >> move *fast*. > > You missed the "?". > >> For the record, as you can see above, I did not say that builds would >> not be impacted.  Do not put words into my mouth again. > > Let me ask it again: so ploughing through a third of a million lines of > code across hundreds of #includes, even at the faster throughput > compared with compiling code, for a module of a few hundred lines, will > have little impact? > > How about a project with 50 or 100 modules, each using that big header, > that needs to be built from scratch? For some reason you are making me think of pre-compiled headers. Ever include even with WIN32_LEAN_AND_MEAN? ;^) Not even sure of this is in context, but you make be think of PCH. Sorry. ;^o [...]