[llvm-dev] A libc in LLVM

[Szabolcs Nagy via llvm-dev]

* 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.