This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Implement C11 annex K?
- From: Rich Felker <dalias at libc dot org>
- To: libc-alpha at sourceware dot org
- Date: Tue, 12 Aug 2014 00:23:24 -0400
- Subject: Re: Implement C11 annex K?
- Authentication-results: sourceware.org; auth=none
- References: <E1XGDcM-0004tT-8P at rmm6prod02 dot runbox dot com> <53E724B6 dot 3000608 at suse dot com> <53E789C0 dot 4000109 at linux dot vnet dot ibm dot com>
On Sun, Aug 10, 2014 at 12:03:28PM -0300, Adhemerval Zanella wrote:
> On 10-08-2014 04:52, Andreas Jaeger wrote:
> > On 08/09/2014 10:51 PM, David A. Wheeler wrote:
> >> I may have someone who'd be willing to develop and submit at
> >> least a portion of ISO C11 annex K. The glibc front page says
> >> that glibc "follows all relevant standards including ISO C11 and
> >> POSIX.1-2008". Should I presume that such a submission would be
> >> considered, and accepted if high enough quality? Or would annex K
> >> (strcpy_s and friends) be automatically rejected, even though
> >> it's in the standard? If implementing the standard would be
> >> automatically rejected, then I don't want to waste this person's
> >> time.
> >>
> >> I think annex K *should* be supported by glibc.
> >
> > Please see the archives of this mailing list for previous discussions
> > about these functions. This is something we rejected previously but I
> > don't recall the details,
> >
> > Andreas
>
> Last iteration to add C11 annex K in GLIBC was from Ulrich Bayer [1] and it
> got stalled not because GLIBC maintainers decided this is not worth of adding,
> but because the proposer didn't send any more updates based on comments.
>
> So you can take this initial approach as base for your work or if you are willing
> start a new thread/implementation. However, keep in mind that since GLIBC is
> community driven project, it will probably require a lot of iterations of
> submission and revisions.
My view is that Annex K was a big mistake -- the latest iteration of
the committee falling for the antics of a "sponsor" that has no
interest in actually implementing the standard and who has done
nothing but try to undermine the C language for the past 20+ years --
and the only good thing about it is that it's optional. As such, I
think support for it should be omitted unless/until there is serious
demand for it in the form of applications that cannot be built without
it. And that's not going to happen unless glibc implements it.
Rich