tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Is anyone on the C standards committee?


From: JeanHeyd Meneide
Subject: Re: [Tinycc-devel] Is anyone on the C standards committee?
Date: Wed, 25 Jan 2023 19:08:50 -0500

     Thanks for this feedback, it's pretty useful to hear it from a different perspective. You'll be happy to know that you're absolutely not the only one with that perspective, especially on the Committee. Albeit, I'm not sure how to feel from the notion that "things being grueling to get through, while difficult, is a feature". Of course, I know that it's not the way it's intended; I would just rather we throw ideas that we don't think are good out wholesale and as soon as humanly possible, so people don't spend too much time on it!

     While a decent portion of what is going in feels very new to C (especially nullptr and constexpr), I feel like there's still a significant degree of catching up the standard has to do for implementations in general. typeof is a pretty big example of this, something that was talked about before I was born! The BSDs have been using asm labels for 26+ years to prevent ABI problems to great effect and TCC itself uses assembly labels to alias things like "memcpy" to "__builtin_memcpy". Statement expressions would make macros a lot more palatable and many compilers -- including small ones like TCC -- already have it baked in!

     For me the focus for the next standard is going to be tackling a lot of the existing practice and extensions that compilers like TCC bring to the table and put them with sensible semantics in the standard. A lot of that is going to be looping back to the community and positing questions about their implementations -- not just GCC and Clang but TCC, MikroC, 8cc, klokwork, Cuik, and others -- so we can stabilize on features beyond C89 + extensions that people have been asking for/implementing for some decades now.

     I can only apologize as I'm new at this and am bound to mess up from time to time. BUT, I am eager to do my best to bring all of your concerns to the forefront and make sure even the smallest implementations have a seat at the table. I even honored my promise to write an NB Comment to remove nullptr from the C standard, and presented it this week to WG14; community feedback is important, because C can only get farther -- in my opinion -- if we do it with respect for the vast experience that all implementations have brought to the table.

     Just make sure to ping me every now and then if you see something that would make your life harder. And, really, that goes for most people on the list. I can't say I'll get to it immediately, and I will always be bound by ISO Process and Procedural constraints, but I will do my best to make sure you're heard and, where possible, listened to seriously.

Best Wishes,
JeanHeyd
    

On Wed, Jan 25, 2023 at 6:20 PM Charles Lohr <lohr85@gmail.com> wrote:
Sorry for replying to the wrong thread.  I meant to reply here.  But my reply is a little different.

My concern is more that in order for compilers "like" TCC (commercial in-house compilers, and other specialty compilers) to remain compliant and be able to continue to use libraries that are undergoing development -- and to prevent these libraries from targeting old C standards, as most currently do.  It's just scary to see some of the proposals floating around. It's good to hear that there are One-Person-Compiler Teams on the standards committee.  There are just *a lot* of them in the wild.  And in the firmware industry it's just scary to see things move at all. 

JeanHeyd, really appreciate the visibility you have provided into what is opaque to me and so many of my colleagues.  Even your activity in replying here.  Your twitter posts and articles like this https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu have given that visibility into a world that has long since seemed dominated by whatever a couple engineers at Google and GNU decide on while the repercussions rain down on us.  (Though most of that fear is from the C++ spec) even though a lot of those concerns leak down through what people like David Koch said in the other email thread.

One of the reasons I have felt the need to reach out here and explore actually was spurred on by some of your views. Or, more specifically, fears of views like yours.  For us, if it weren't the "endless feedback loops" and "individual burnout and low return on investment" (to quote you) halting the progress of ISO groups, our jobs and lives would be much harder.  We have long since relied on those "features" of the ISO - that only serious brokenness is addressed. **But** for those really broken items it is admittedly nice when they are addressed.

I mostly wanted to just start a conversation on this list to make sure someone from this corner of the world had input to help add care to what is effectively our "Rabbinic Tradition" of ISO.  I do not have particular interest in trying to join myself as I have not yet written my own compiler but instead leverage others.  I was mostly just curious.

Charles

On Wed, Jan 25, 2023 at 12:56 PM JeanHeyd Meneide <phdofthehouse@gmail.com> wrote:
(As a small addendum to my previous e-mail, I should note: we have a number of tiny vendors on the Committee already, including one that is a One-Person-Compiler team, and one that brings input from a similar one-person-implementer team but from open source compiler SDCC. I myself am also a one person force of nature, but I don't have a released compiler to my name (yet!). This is not discouragement; more participation from involved stakeholders would be great.)

On Wed, Jan 25, 2023 at 3:53 PM JeanHeyd Meneide <phdofthehouse@gmail.com> wrote:
Hi Charles,

     My name is JeanHeyd Meneide, and I'm on ISO/IEC JTC1 SC22 WG14 - the C Standards Committee. I write about it in a personal capacity and not-very-frequently here - https://thephd.dev/

     So far, what I've heard about so far is the standardization of GCC/Clang and other's __auto_type extension seemed to cause a lot worry for folks, and that "nullptr" might not be hard to implement but unsavory.

     After that, things like compatible type improvements, enumeration fixes and improvements, required two's complement behavior, #embed, __VA_OPT__ for macros, and more all came in to solve longstanding undefined behavior or implementation-defined behavior issues, code portability issues, and *so far* received pretty broad support from the communities we've been in contact with.

     (The above are all language-based features; there's library features too such as the new stdbit.h header, improved time bases in time.h, the new stdckdint.h header for overflow/underflow-checked arithmetic, and more.)

     I'd like to know what things you find to be unpalatable or unsavory in the direction of C! This can help us make decisions and inform us over the next 15 years.

Best Wishes,
JeanHeyd

On Wed, Jan 25, 2023 at 1:55 PM Charles Lohr <lohr85@gmail.com> wrote:
I was just wondering if anyone from TCC on the standards committee?  I just really hope for a compiler as popular as TCC, there's someone there defending the interests of all the not-GCC, not-clang compilers, where difficulty of feature addition is a paramount concern.  I use TCC as my daily driver, and I have been increasingly anxious about some of the proposals and things that are being added to the C standard.

Charles
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]