Path: csiph.com!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: bart cc32n.c Date: Tue, 30 Jan 2024 22:56:05 -0800 Organization: A noiseless patient Spider Lines: 56 Message-ID: <86a5omat4q.fsf@linuxsc.com> References: <86v87bbqke.fsf@linuxsc.com> <86mssnbadi.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="fb4244b8d2c04d3d864a981f3fa61ba0"; logging-data="1501461"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+AVR+JClRBi485yPrnwllcut2NM+WYLio=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:Qbis58m284gcF2DK4QdhnaAA4Lw= sha1:+BdkcNkJWrTeE8JaXL19oM/L4Ys= Xref: csiph.com comp.lang.c:381311 bart writes: > On 30/01/2024 06:31, Tim Rentsch wrote: [...] >> I'm not telling anyone how to compile their programs. All I'm >> doing is giving a way of checking whether a program is C code or >> is written in a language that may look like C but isn't. Knowing >> how to do that is something I could have benefited from - many >> years ago I wrote some code that I thought was being written in >> C, but later I discovered that it wasn't. I started programming >> in C long before there was a C standard, and didn't realize the >> degree to which different compilers had different ideas of what >> "C" was. As of this year we are celebrating the 35th anniversary >> of the original C standard, and the 25th anniversary of C99, so I >> think it's reasonable to expect that people participating in the >> newsgroup here at least know how to tell if some code they are >> working on is written in C or it isn't. > > This program was machine generated. The way that is done now is a > little different (for example it doesn't use standard C headers). > > If I apply -std=c11 -pedantic-errors, it fails on only 3 kinds of > error: > > * String literals longer than 4095 characters > > * Initialising a void* value with the address of function > > * Casting an object pointer to a function pointer If the .c file is program generated, it should be easy to fix. So fix it. (1) Presumably the generator knows which pointers are function pointers and which are not. Use a generic function type for storing function pointers rather than trying to force everything through void*. (2) Rather than use long string literals, store and initialize the variables involved (it looks like there are only two) as character arrays. It looks ugly but hey it's program generated code anyway. I tried writing a simple convertor using awk and it took maybe 10 or 15 minutes. Speaking of program generated source, C code that is program generated is definitely a second class citizen as far as the newsgroup is concerned. It's like saying a .o file is written in assembly. It isn't. Generated C source may clear the hurdle of being compilable but they can't usefully be worked on in that form and are generally incomprehensible to humans. It's fair game to ask about how to make generated source be legal C, but describing programs like this as "written in C" is hokum. Such programs are useless as C code in any practical sense of the term and thus are not suitable for discussion in comp.lang.c.