Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Thu, 27 Jun 2024 18:08:03 -0700
Organization: A noiseless patient Spider
Lines: 100
Message-ID: <86y16pdgcs.fsf@linuxsc.com>
References: <v494f9$von8$1@dont-email.me> <v53lf7$34huc$1@dont-email.me> <v53vh6$368vf$1@dont-email.me> <v54se1$3bqsk$1@dont-email.me> <20240624160941.0000646a@yahoo.com> <v5bu5r$va3a$1@dont-email.me> <20240624181006.00003b94@yahoo.com> <v5c86d$11ac7$1@dont-email.me> <JEheO.108086$ED9b.74955@fx11.iad> <v5cblg$11q0j$1@dont-email.me> <gEieO.108089$ED9b.25598@fx11.iad> <20240625113616.000075e0@yahoo.com> <mUzeO.141609$Cqra.55051@fx10.iad> <v5elql$1jmii$1@dont-email.me> <m3BeO.24907$Gurd.16179@fx34.iad> <v5empd$1jndv$2@dont-email.me> <v5eph4$1k6a9$1@dont-email.me> <87ed8jnbmf.fsf@bsb.me.uk> <v5jhls$2m7np$1@dont-email.me> <867ceadtih.fsf@linuxsc.com> <v5krsp$2v9va$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Fri, 28 Jun 2024 03:08:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3676fcdb950143c607d286a4991a0048";
	logging-data="3146619"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19dSKT4TT5wtc+TU2ZwVh56NFu0Co4EEZQ="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:4iwljj7ix/ti/vItgzg6gZkwoV4=
	sha1:4p1AUq5exKm4ZT3YAGO35T4nmAQ=
Bytes: 5840

bart <bc@freeuk.com> writes:

> On 27/06/2024 21:23, Tim Rentsch wrote:
>
>> bart <bc@freeuk.com> writes:
>>
>>> On 26/06/2024 13:15, Ben Bacarisse wrote:
>>>
>>>> bart <bc@freeuk.com> writes:
>>>>
>>>>> On 25/06/2024 16:12, David Brown wrote:
>>>>
>>>> ...
>>>>
>>>>>> I /do/ use Python.  I use it when it is an appropriate language to use,
>>>>>>   which is very different circumstances from when I use C (or
>>>>>> C++).  Different tools for different tasks.
>>>>>
>>>>> And yet neither of you are interested in answering my question, which was
>>>>> why its simplistic bytecode compiler is acceptable in this scenario, but
>>>>> would be considered useless if applied to C code.
>>>>
>>>> You throw out a lot of these sorts of question, by which I mean
>>>> questions that you either /do/ know the answers to or which you /should/
>>>> know the answers to.
>>>>
>>>> If a software engineering student asked me this sort of "challenge"
>>>> question it would immediately become homework:  come up with at least two
>>>> scenarios in which a simplistic C bytecode compiler would be an
>>>> unacceptable tool to use, and two in which Python with a trivial
>>>> bytecode compiler would be an acceptable tool to use.  In each case
>>>> explain why.  Anyone who could not would get marked down on the course.
>>>
>>> I'm not sure what you're implying here.
>>>
>>> Some here are consistently saying that any compiler whose internal
>>> processes are not at the scale or depth that you find in
>>> professional', 'industrial scale' products like gcc, clang, icc, is
>>> not worth bothering with and is basically a useless toy.
>>
>> After reading the above I decided to try tcc.  I used tcc for
>> the first time earlier today.
>>
>> First I tried using tcc for my most recent project.  That
>> didn't go anywhere, because that project relies on C11,
>> and tcc doesn't support C11.
>>
>> Next I tried using tcc on a small part of my larger current
>> project.  That test involves compiling one .c file to produce a
>> .o file, and linking with several other .o files to produce an
>> executable, and running the executable.  The .c file being
>> compiled uses C99 and doesn't need C11.
>>
>> The first thing that came up is tcc doesn't support all of
>> C99.  There are some C99 features that tcc just doesn't
>> understand.
>
> Which ones?  I thought its C99 support was far more complete than
> mine.

I didn't post to have a conversation about tcc.  I just thought
people might be interested to hear about the trial.

>> In this case the infringements were minor so I
>> edited the source to work around the missing features.
>>
>> The second thing to come up is some language incompatibilities.
>> There are language features that tcc understands, sort of,
>> but implements them in a way that didn't work with my source
>> code.  To be fair, a case could be made that what tcc does
>> conforms to the C standard.  However, the code I had before
>> works fine with gcc
>
> People develop sofware using compilers like gcc, and will naturally do
> whatever it takes to make them work with that tool.  They might
> inadvertently use extensions.

I routinely use -pedantic-errors for my compiles, and am totally
intolerant of any warning or error messages.  I very much doubt
my builds use any extensions.

>> After doing a trial run with the produced executable, I looked at
>> the tcc man page.  As best I can tell, tcc simply silently
>> ignores the -fPIC option.
>
> I think that it tries to be a drop-in replacement for gcc, so supports
> some of its options, even if they don't do anything.  Like -O3.

I would say tcc accepts the -fPIC option but does not support it.

> Position-independent code seems to be a recent thing with gcc
> tools.  My tools didn't support it either, until a year ago when I
> found out about ASLR.
>
> For most, PIC isn't a necessity.  But tcc supports shared libraries,
> and some kinds of relocation, if not full PIC, are necessary.

Support for -fPIC is a must-have for that project.  I'm not going
to spend time investigating possible partial solutions when I
already have other options available that are known to work.