On Mon, Jul 15, 2019 at 2:43 PM Siva Chandra <sivachandra at google.com> wrote:> > > On 7/15/19 1:22 PM, Aaron Ballman via llvm-dev wrote: > > > On Mon, Jul 15, 2019 at 1:02 PM Siva Chandra <sivachandra at google.com> wrote: > > >> On Fri, Jul 12, 2019 at 8:32 AM Aaron Ballman <aaron at aaronballman.com> wrote: > > >>>> llvm-libc is an implementation of the C standard library targeting C11 > > >>>> and above. > > >>> Any particular reason for C11 as opposed to C17? > > >> Two reasons: > > >> 1. The C++17 standard refers to the C11 standard. > > > This is somewhat confusing to me. That's a reason to support *at > > > least* C11. It doesn't seem like a reason to not support the latest C > > > standard. > > I think there is some misunderstanding here. My first message said > llvm-libc will target C11 __and above__. Which is to imply that the > lower bound of supported standards is C11. > > > On Mon, Jul 15, 2019 at 11:31 AM Finkel, Hal J. <hfinkel at anl.gov> wrote: > > +1. Aiming for C17 seems better than aiming for only C11. > > I interpreted Aaron Ballman's first question as, "why is the lower > bound C11 and not C17?" I answered that by saying C++17 standard still > refers to C11 standard, so we need to keep C11 as a lower bound. > > Unless there is some technicality of the language and/or standards > which I am not aware of, I did not intend to convey that we do not > intend to support latest C standards. > > Are you saying that the lower bound of standards llvm-libc should > support ought to be C17?Yes, I'm sorry if I was unclear. I think that there's not much purpose to supporting C11 as the lower bound given that C17's standard library is C11's standard library, but with bug fixes. There were no new features added during C17. ~Aaron
On Mon, Jul 15, 2019 at 11:47 AM Aaron Ballman <aaron at aaronballman.com> wrote:> > On Mon, Jul 15, 2019 at 2:43 PM Siva Chandra <sivachandra at google.com> wrote: > > > > > On 7/15/19 1:22 PM, Aaron Ballman via llvm-dev wrote: > > > > On Mon, Jul 15, 2019 at 1:02 PM Siva Chandra <sivachandra at google.com> wrote: > > > >> On Fri, Jul 12, 2019 at 8:32 AM Aaron Ballman <aaron at aaronballman.com> wrote: > > > >>>> llvm-libc is an implementation of the C standard library targeting C11 > > > >>>> and above. > > > >>> Any particular reason for C11 as opposed to C17? > > > >> Two reasons: > > > >> 1. The C++17 standard refers to the C11 standard. > > > > This is somewhat confusing to me. That's a reason to support *at > > > > least* C11. It doesn't seem like a reason to not support the latest C > > > > standard. > > > > I think there is some misunderstanding here. My first message said > > llvm-libc will target C11 __and above__. Which is to imply that the > > lower bound of supported standards is C11. > > > > > > On Mon, Jul 15, 2019 at 11:31 AM Finkel, Hal J. <hfinkel at anl.gov> wrote: > > > +1. Aiming for C17 seems better than aiming for only C11. > > > > I interpreted Aaron Ballman's first question as, "why is the lower > > bound C11 and not C17?" I answered that by saying C++17 standard still > > refers to C11 standard, so we need to keep C11 as a lower bound. > > > > Unless there is some technicality of the language and/or standards > > which I am not aware of, I did not intend to convey that we do not > > intend to support latest C standards. > > > > Are you saying that the lower bound of standards llvm-libc should > > support ought to be C17? > > Yes, I'm sorry if I was unclear. I think that there's not much purpose > to supporting C11 as the lower bound given that C17's standard library > is C11's standard library, but with bug fixes. There were no new > features added during C17.OK, point taken. We might have to say something like this in the charter, "llvm-libc ... targetting C17 (which essentially C11 + bug fixes) and above."
* Siva Chandra via llvm-dev <llvm-dev at lists.llvm.org> [2019-07-15 11:55:32 -0700]:> On Mon, Jul 15, 2019 at 11:47 AM Aaron Ballman <aaron at aaronballman.com> wrote: > > > > On Mon, Jul 15, 2019 at 2:43 PM Siva Chandra <sivachandra at google.com> wrote: > > > > > > > On 7/15/19 1:22 PM, Aaron Ballman via llvm-dev wrote: > > > > > On Mon, Jul 15, 2019 at 1:02 PM Siva Chandra <sivachandra at google.com> wrote: > > > > >> On Fri, Jul 12, 2019 at 8:32 AM Aaron Ballman <aaron at aaronballman.com> wrote: > > > > >>>> llvm-libc is an implementation of the C standard library targeting C11 > > > > >>>> and above. > > > > >>> Any particular reason for C11 as opposed to C17? > > > > >> Two reasons: > > > > >> 1. The C++17 standard refers to the C11 standard. > > > > > This is somewhat confusing to me. That's a reason to support *at > > > > > least* C11. It doesn't seem like a reason to not support the latest C > > > > > standard. > > > > > > I think there is some misunderstanding here. My first message said > > > llvm-libc will target C11 __and above__. Which is to imply that the > > > lower bound of supported standards is C11. > > > > > > > > > On Mon, Jul 15, 2019 at 11:31 AM Finkel, Hal J. <hfinkel at anl.gov> wrote: > > > > +1. Aiming for C17 seems better than aiming for only C11. > > > > > > I interpreted Aaron Ballman's first question as, "why is the lower > > > bound C11 and not C17?" I answered that by saying C++17 standard still > > > refers to C11 standard, so we need to keep C11 as a lower bound. > > > > > > Unless there is some technicality of the language and/or standards > > > which I am not aware of, I did not intend to convey that we do not > > > intend to support latest C standards. > > > > > > Are you saying that the lower bound of standards llvm-libc should > > > support ought to be C17? > > > > Yes, I'm sorry if I was unclear. I think that there's not much purpose > > to supporting C11 as the lower bound given that C17's standard library > > is C11's standard library, but with bug fixes. There were no new > > features added during C17. > > OK, point taken. We might have to say something like this in the > charter, "llvm-libc ... targetting C17 (which essentially C11 + bug > fixes) and above."when you start a new libc project c11 vs c17 really should not be the priority (in fact with minor extra code/work you can support all of c99/c11/c17 and you can decide this later). otoh there are fundamental questions you need to answer early: is it for safety critical systems, is it for linux server applications, is it for tiny embedded systems, is it for research etc. and there are fundamental design decisions that's worth discussing early: threading and tls design, dynamic linking support, abi/api stability guarantees, level of compatibility with legacy code and extensions, failure handling quality guarantees, resource usage vs performance tradeoff goals, realtime guarantees, level of locale support, stdio design goals, malloc design goals, math library quality guarantees, supported os/platform/abi configurations, etc. of course design discussions are moot if we don't even know the goals or the development process of the libc. note that posix compatibility is way more important in practice for a libc than c++ compatibility: the c++ runtime is mostly independent from c, but posix apis must be designed and implemented as part of libc. posix is defined in terms of c99. lot of c and c++ code relies on posix apis (including the c++ runtime). what do you achieve by not supporting c99? you can drop gets? really? have you checked the prevalence of c99 or cc -std=c99 in existing build scripts? all of such compilation will fail on c11 only standard headers.