Path: csiph.com!news.fcku.it!peer04.fr7!futter-mich.highwinds-media.com!news.highwinds-media.com!fx07.am4.POSTED!not-for-mail Newsgroups: comp.lang.c X-Mozilla-News-Host: news://news.virginmedia.com:119 From: bartc Subject: Dropping C User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Lines: 59 Message-ID: X-Complaints-To: http://netreport.virginmedia.com NNTP-Posting-Date: Sat, 17 Mar 2018 16:07:10 UTC Organization: virginmedia.com Date: Sat, 17 Mar 2018 16:07:26 +0000 X-Received-Bytes: 2919 X-Received-Body-CRC: 3461847617 Xref: csiph.com comp.lang.c:127943 On 16/03/2018 01:36, bartc wrote: [Linking to my C compiler project] > Creating a one file C source is proving troublesome As well as abandoning support for one-file C sources, I've decided for now to also drop support for generating any C source at all. I've only just realised that's making life more difficult rather than simpler: * My IDE supports 11 combinations of C compilers [including 32/64-bit variations], which all work a little differently. Generating C that will keep all happy is rare * They all have different criteria for what constitute errors and warnings * Generating code for a large project that is free of warnings is difficult (and there will always be someone who will ramp it up further). On some compilers, impossible. * Working on my C compiler has drawn me in to a world of horrendous looking configure scripts, makefiles, system header files, and source files full of conditional code and dense macros. (For debugging certain apps, I've resorted to working with preprocessed code, so that everything is just there, rather than traipsing all over the source directory and having to keep looking up macro.) * There's also the risk that any code I write might be assumed to be undefined behaviour, and turned into something else by a compiler. * There's the problem with struct packing, where I need to know /exactly/ how a C compiler might deal with it. * And I can't use some original source features I want because C, or some compilers, will have difficult. Removing the intermediate C stage cuts right through all these problems. (The cost: having to provide my own support for some targets. Not benefiting by passing code through an optimising C compiler.) > I'll put some docs on Github (https://github.com/bartg/langs) when I > have time (it doesn't say much at the moment). The C compiler project remains as a curiosity. It can compile my C dialect with no problem, for new code, or for generated code (now no longer used), but it can have a hard time if thrown an arbitrary open source app. Maintaining it seriously is a huge effort. Anyway, it is still there as a binary, but I don't know how buildable source can be made available. -- bartc