On Fri, Jan 13, 2023 at 09:40:20PM +0530, Jerin Jacob wrote: > On Fri, Jan 13, 2023 at 7:49 PM Ben Magistro <konce...@gmail.com> wrote: > > > > As a user/developer I'll put a vote on Morten's side here. There are other > > libraries we utilize that have stated x.y.z is the last version that will > > support w, beginning on version l.m.n it will be standard o. I personally > > don't think a project asking for C11 support at a minimum would be > > unreasonable or overly burdensome. > > +1 > > > Instead of polluting new DPDK code for legacy applications(If some > reason they want absolutely want to move latest and greatest DPDK), I > think it should be possible for legacy application selectivity turning > on/of like "#pragma GCC diagnostic warning "-std=c++11" > or worst case move DPDK function in wrapper(which is already case in > most of the applications) in their app and compile the wrapper only > with C11
so just a caution that this mail thread isn't proposing any bump in C standard requirement, it's about introducing an atomics abstraction though it's really easy to start talking about standard C i understand. let's move discussion about dpdk minimum standard C to the thread Bruce posted yesterday to avoid distraction about atomics abstraction integration. Bruce's thread addressing setting the minimum standard is here. http://mails.dpdk.org/archives/dev/2023-January/258925.html thanks!
