Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Wed, 11 Dec 2024 16:03:35 +0100
Organization: A noiseless patient Spider
Lines: 125
Message-ID: <vjc9k8$1jcad$1@dont-email.me>
References: <vi54e9$3ie0o$1@dont-email.me>
 <87frnbt9jn.fsf@nosuchdomain.example.com> <viaqh0$nm7q$1@dont-email.me>
 <877c8nt255.fsf@nosuchdomain.example.com> <viasv4$nm7q$2@dont-email.me>
 <vibr1l$vvjf$1@dont-email.me> <vic73f$1205f$1@dont-email.me>
 <20241129142810.00007920@yahoo.com> <vicfra$13nl4$1@dont-email.me>
 <20241129161517.000010b8@yahoo.com> <vicque$15ium$2@dont-email.me>
 <vid110$16hte$1@dont-email.me> <vifcll$1q9rj$1@dont-email.me>
 <vifiib$1s07p$1@dont-email.me> <viht27$2hgg1$3@dont-email.me>
 <vjb8e9$1973q$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 11 Dec 2024 16:03:39 +0100 (CET)
Injection-Info: dont-email.me; posting-host="2219d0e81fc8abda50710a06e8939fe0";
	logging-data="1683789"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX189fZnWOVxE5KCtLh//SDu+hYXSQUSnfQQ="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:fnpiG2cuVSUAMBb/wC0eiQu4u6c=
In-Reply-To: <vjb8e9$1973q$1@paganini.bofh.team>
Content-Language: en-GB
Bytes: 7325

On 11/12/2024 06:37, Waldek Hebisch wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 30/11/2024 18:38, Bart wrote:
>>> It will at least work with more compiles.
>>>
>>
>> And why would that matter?  No actual developer would care if their code
>> can be compiled by your little toy compiler, or even more complete
>> little tools like tcc.  Code needs to work on the compilers that are
>> suitable for the job - compatibility with anything else would just be a
>> waste of effort and missing out on useful features that makes the code
>> better.
> 
> You are exagerating and that does not help communication.

That is probably a fair comment.

But in this case, I don't think it is much of an exaggeration.  Most 
programmers of any language do the work primarily because they are paid 
to do so.  I find it highly implausible that someone would pay a 
professional programmer to write code with a view to compatibility with 
tools that are not realistically useful for the task in hand, or the 
foreseeable future.  And for people programming for fun, learning or 
hobby, I can't imagine many pay much attention to supporting rare and 
unusual tools.

Some people aim to make their code highly portable, even beyond the 
tools they normally use.  But that is generally either a matter of 
sticking tightly to a particular C standard or an additional standard 
(such as POSIX).  And some types of code can be made to support multiple 
embedded compilers, which can mean using hooks, macros or similar tricks 
to conveniently support compiler-specific extensions (such as for 
"packing" structs, or inline assembly).

Who, however, is going to write C code and put effort into making sure 
it is /specifically/ portable to tools like tcc?  People interested in 
benchmarking or otherwise testing C compilers might.  There are probably 
a few people who use tcc as their main C compiler (presumably on 
Windows, since *nix users will need good reason to use something other 
than their system compiler, and that typically implies switching to 
something better than their system compiler).

People write code to work with the tools they use, and tools they expect 
to be used with the code.  They don't go out of their way to check 
compatibility with tools.  Thus C code written for Linux systems often 
won't compile with MSVC, and C code written for MSVC often won't compile 
with gcc or clang.

(Of course plenty of code will coincidentally work fine with tcc - it 
doesn't keep up with modern C standards, but it still tries to be quite 
conforming and it supports a number of gcc extensions.  So if you write 
a C library and stick to C99, for example, then it will likely work fine 
with tcc.)


Some code generators, including transpilers, support tcc.  If the tool 
is intended to be used on Windows then that makes sense since there is 
no default compiler there, and it makes installation easier.


>  In this
> group there were at least one serious poster claiming to write code
> depending only on features from older C standard.  

Would that be the person who thinks that after armageddon we will all go 
back to using C90 on mainframes?  I'm not sure that individual can be 
taken seriously.

But certainly there are people who, for good reasons or bad, stick to 
older C standards.  If that is of interest to you, then you would want 
to use "gcc -std=c90 -Wpedantic", or similar, to help spot deviations 
from that.

> People like this
> presumably would care if some "toy" compiler discoverd non-compliance.

Yes, but such compilers are not good tools for that purpose.  tcc does 
not in any way attempt to spot deviations from any standard.  As far as 
I can tell from its documentation, it supports C89/C90, "many features 
of the new C standard: ISO C99", some gcc extensions, and some of its 
own TinyCC extensions.  And there is no flags for controlling these or 
setting "conforming" modes.

> Concerning tcc, they have explicit endorsment from gawk developer:
> he likes compile speed and says that gawk compiles fine using tcc.

Is that so that you can say I am wrong to claim "no one" cares about tcc 
support, because you have found 1 person who has used it?  I admit it - 
"no one" was an exaggeration.

> 
> In may coding I use gcc extentions when I feel that there is
> substantial gain.  But for significant part of my code I prefer
> to portablility, 

Sure - I think most of us do that.

> and that may include avoiding features not
> supported by lesser compilers.  

I think very few care about that bit.  I'll use a gcc extension if it 
makes a noticeable improvement to the code - making the source code 
nicer in some way, improving static error checking, or improving the 
efficiency of the object code.  But I certainly won't avoid a standard C 
feature just because some lesser compilers might not support it!

> I the past tcc was not able
> to compile code which I consider rather ordinary C, and due
> to this and lack of support for my main target I did not use
> tcc.  But tcc improved, ATM I do not know if it is good enough
> for me, but it passed initial tests, so I have no reason to
> disregard it.
> 
> BTW: IME "exotic" tools and targets help with finding bugs.
> So even if you do not normally need to compile with some
> compiler it makes sense to check if it works.
> 

Using similar quality or better tools can be an aid.  Maybe if you are 
not sure about something, you check with both gcc and clang instead of 
just one of them.  When using weaker tools (for specific embedded 
targets), I have used gcc as a static error checker in parallel with the 
actual compiler.