Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch 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: <20240624160941.0000646a@yahoo.com> <20240624181006.00003b94@yahoo.com> <20240625113616.000075e0@yahoo.com> <87ed8jnbmf.fsf@bsb.me.uk> <867ceadtih.fsf@linuxsc.com> 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 writes: > On 27/06/2024 21:23, Tim Rentsch wrote: > >> bart writes: >> >>> On 26/06/2024 13:15, Ben Bacarisse wrote: >>> >>>> bart 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.