Re: Suggested method for returning a string from a C program?

On 24/03/2025 16:10, Michael S wrote:

On Mon, 24 Mar 2025 15:32:32 +0100
David Brown <david.brown@hesbynett.no> wrote:
 

On 24/03/2025 15:07, bart wrote:

On 24/03/2025 11:51, David Brown wrote:

On 23/03/2025 02:34, bart wrote:
 

It's strange: in one part of the computing world, the speed of
building software is a very big deal. All sorts of efforts are
going on to deal with it. Compilation speed for developers is
always an issue. There is a general movement away from LLVM-based
backends / because/ it is so slow.
>
And yet in another part (namely comp.lang.c) it appears to be a
total non-issue!
 

>
You find it strange that different parts of the computing world
(or, more appropriately, software development world) have
different priorities, needs and focuses for their tools?  I find
it very strange that anyone would find that strange!
>
 

>
What was strange was that that one view was shared by pretty much
everyone in comp.lang.c.

>
Do you know what the people in comp.lang.c have in common?
>
We program in C.
>
Do you know /why/ people program in C?
>
There can be many reasons, but a very common one is that they want
fast resulting binaries.  Most serious programmers are familiar with
more than one language, and pretty much all other languages are
higher level, easier, and have higher developer productivity than C -
but the resulting binaries are almost always slower.
>

 I disagree.
35-36 years ago I forgot about Pascal after few months of exposure to C.
It didn't happen because of speed of resulting binaries, but due to my
own improved productivity.
Ada and Rust are two other exampled of languages that lag behinds C in
productivity.
And in all three cases above I still did not leave the realm of
relatively good languages. Unfortunately, I have to use at least one
bad language as well - tcl.
 

I said "most", not "all" :-)
And I meant this all in a general sense - people want different things from their languages and their tools, and will have different trade-offs.  When I want fast, efficient code, I use C - when I want quick and easy development, I use Python.  It does not surprise me that most people in comp.lang.c are not bothered about compile times for C - but it /would/ surprise me if they were not bothered about the run times for compiled C.  When they /do/ have irritating compile times, they make sure they use good build tools and parallel builds to reduce the time. Similarly, people in comp.lang.python would no doubt complain if the .py to .pyc byte-compiling took any noticeable time at all, but understand fine that the run-time of Python is inefficient - and use "tricks" such numpy or pypy when that becomes an issue.
Other things people might be happy to trade for build times include static analysis for error checking, or compact binaries.  And equally they might be happy to trade run-time for dynamic error checking.
Only a fool thinks that /one/ single aspect of software development should be overriding, especially when that aspect is rarely an issue in practice and easily solvable by using a computer that is not decades old.
(I am sure that Rust and Ada developers consider their languages to be a lot more productive than C - especially when viewed as the time to produce fully debugged and working code.  But I am not going to start an argument about that!)