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] |
Rich Felker wrote:
I don't recall any such consensus,
Well, to be fair I didn't call it a consensus, only a "most favored suggestion". I agree it didn't have consensus.
there's a huge difference in adding an interface that conflicts with he requriements of Annex K (even if glibc doesn't want to support Annex K now or for the forseeable future), and adding one which simply does not support all the 'features' specified in Annex K but matches the semantics for the features it does support.
That goes only so far. Suppose the spec for plain traditional strcpy were in Annex K, and glibc supplied a strcpy implementation that mostly worked, except it failed to copy the trailing null byte. I doubt whether users would be satisfied with the justification "well, this doesn't *conflict* with the spec, and it's *partial* support for the standard". Similarly for a memset_s that fails to throw an exception if you invoke it with invalid arguments.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |