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: Implementation of C11 Bounds-checking interfaces


On Wed, Oct 31, 2012 at 11:26:42AM -0400, Carlos O'Donell wrote:
> > Of course, we welcome your feedback.
> 
> Thank you for the great work!
> 
> What was the reason given for not wanting to integrate this work with glibc?

While this doesn't answer the question of the original reason, one
good reason I can think of is that, from what I can tell, all of these
functions should be possible to implement as pure library functions in
a portable way, without any knowledge of the internals of the
underlying C library. As such, having them separate allows them to be
used on any system, not just systems based on glibc; having them
integrated into the glibc source tree would make it a lot more work to
factor them out as a separate library for use on other systems.

> Do you have a reference to the public discussion?
> 
> My personal inclination is to attempt to include this functionality in
> glibc, but I don't have that much experience with the functions in
> Annex K.
> 
> Perhaps others will comment.

I think the general consensus about these functions is that they were
added (as optional interfaces, rather than the originally-proposed
mandatory set of interfaces) at the insistence of folks from
Microsoft, with objection or grudgingly tacit acceptance from
everybody else. Nobody likes these functions, and the only reason to
have them around is that they might make porting some Windows software
easier. On the other hand, I've heard reports (unverified) that some
of the semantics were actually changed in standardization from the MS
behavior, so it's possible that they're useless even for that purpose.

Please don't misconstrue this post as claiming the work to implement
them is useless. I think there's a value in having a working, portable
implementation of these functions in case any software comes to use
them. But I think it's worthwhile to discourage their use by having
them in a separate library, especially when making it a separate
library also gives the advantages I described above.

Rich


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