This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Implement C11 annex K?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]