Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Suggested method for returning a string from a C program? Date: Sat, 22 Mar 2025 14:52:29 -0700 Organization: None to speak of Lines: 123 Message-ID: <871puoag2q.fsf@nosuchdomain.example.com> References: <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 Injection-Date: Sat, 22 Mar 2025 22:52:31 +0100 (CET) Injection-Info: dont-email.me; posting-host="560ef87f14dda6eab647556d5657da3c"; logging-data="859590"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19KMl1Y5/+HQwstQcWxUsy/" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:JGB9vg+n74WyrlHZJNeomQRY0GQ= sha1:JI6SVYvhqZtXtzV3uSvVVhxR7JU= Xref: csiph.com comp.lang.c:391526 bart writes: > On 22/03/2025 03:50, Keith Thompson wrote: >> bart writes: >>> On 21/03/2025 19:04, Keith Thompson wrote: >>>> bart writes: [...] >>>>> 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 "?". No, I didn't. You insinuated that I had implied that large headers would not impact builds. You phrased it as if you were questioning something I had said. I don't care to debate this specific issue further, but please be mmore careful. >> 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? I don't know. I haven't taken the time to measure the impact, and if I did there wouldn't be much I could do about it. It hasn't particularly inconvenienced me. Most of the builds I do from source are straightforward. The general pattern is roughly "configure;make;sudo make install". I have a wrapper script that does that, figures out what arguments to pass, adds some extra options, and so forth. I'm aware configures scripts can be very large (the one for coreutils close to 95,000 lines), but I really don't care or see why I should. It works. Building coreutils and installing 9.6 on my system took about 5 minutes, during which I was able to go off and do other things. Could the whole thing be streamlined? Could a new version of the autotools be developed that doesn't cater as much to obsolete systems and generates smaller configure scripts? Would it substantially improve build times? Quite possibly, but I'm not likely to be the one to work about the details (unless someone wants to hire me to look into it). [...] > So let me ask /this/ again: if such a library consisted of ONE compact > header file, would it make the process simpler? Would it make > compilation of multiple modules faster?) I don't know. >>> printf("%v\n", t); # (used to be '?'; changed to 'v') >>> } >>> >>> The compiler replaces the 'v' format with a conventional format code >>> according to the type of the expression. For my 'time_t', it happens >>> to be 'lld'. >> That's nice. Seriously, it's nice. If it were added to a future >> edition of the language, I'd likely use it (once I could count on it >> being supported, which would take a while). >> The Go language has something like that. >> You can add extensions like that to your own compiler easily >> enough. Adding them to the C standard (which requires getting all >> implementers to support them) is a lot harder. Does it work for >> both output (printf) and input (scanf)? What if the format string >> isn't a string literal; does the compiler generate code to adjust >> it, allocating space for the translated string and deallocating it >> after the call? Does it work with printf("%n", &var)? What about >> qualifiers, specifying width, base, and so forth. > > My feature was a proof of concept. The 60 lines of code used to test > it worked specifically for 'printf', and didn't attempt to parse > additional attributes like field widths (I wasn't implementing half of > printf). I understand that it's a proof of concept. My point is that all these questions would have to be answered if it were to become part of the C standard. It's great that you've done a preliminary implementation, but it doesn't do most of us any good. > It only works when the format string is a literal (but so does gcc's > checking that format codes match parameter types). Right, if a format string isn't a literal you don't get compile-time warnings (which are optional as far as the standard is concerned), but you still get exactly the ame run-time semantics. [...] > C probably introduced variadic functions just for this purpose (which > remains challenging to implement!). I believe so, yes. Early C implementations didn't explicitly have variadic functions; printf was implemented in ways that happened to work with the compiler, and later with the handful of other compilers. There used to be a a header; C89/C90 superseded it with . > (I deal with it in my languages by having Print as a statement, with > special syntax. But internally the result is a series of function > calls (print_i64 etc); ugly, sprawling code. Users will not see it, > but I do.) If it's a built-in statement, then user code can't use the same mechanism. [...] -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */