At 2025-09-30T10:39:34+0300, Oğuz wrote: > On Tuesday, September 30, 2025, Martin D Kealey <[email protected]> > wrote: > > Attached is one possible resolution. > > What does it achieve other than silencing a spurious warning? ISO C > clowns define rsize_t as size_t so even if malloc/realloc were changed > to take rsize_t instead that code wouldn't cause any problems.
I spent a while following WG14 closely during the last year or so of the
ISO C23 standardization process, and formed the opinion that its members
aren't "clowns", but engineers, like us.
That said, some "engineers" (firms) are bigger than others, and we may
be seeing evidence of that here.
`rsize_t` is an aspect of Annex K, which seems to have been a Microsoft
Visual C ("Studio"?) vendor extension dumped bodily into the WG14
committee's lap, perhaps on a take-it-or-leave-it basis. As a
supplement ("annex") to the C standard, it arrived in C11.
Martin Sebor (formerly of Cisco) and Carlos O'Donnell (Red Hat, GNU)
submitted a paper studying uptake of Annex K interfaces as of 2015,
reflecting field experience before and after its incorporation into the
standard. I quote their conclusions.
"Despite more than a decade since the original proposal and nearly ten
years since the ratification of ISO/IEC TR 24731-1:2007, and almost five
years since the introduction of the Bounds checking interfaces into the
C standard, no viable conforming implementations has emerged. The APIs
continue to be controversial and requests for implementation continue to
be rejected by implementers.
The design of the Bounds checking interfaces, though well-intentioned,
suffers from far too many problems to correct. Using the APIs has been
seen to lead to worse quality, less secure software than relying on
established approaches or modern technologies. More effective and less
intrusive approaches have become commonplace and are often preferred by
users and security experts alike.
Therefore, we propose that Annex K be either removed from the next
revision of the C standard, or deprecated and then removed."[1]
I suggest that the solution to "clownery" in this instance is for
working engineers to get involved with WG14, resurrect this proposal,
and add weight counterbalancing Microsoft.
It's also possible--perhaps even likely now that another 10 years have
passed--that the PE/fellow/director/whatever at Microsoft who threw so
many company resources at shaping the ISO C standard in this respect has
since moved on to other roles, and Annex K is no longer useful to this
person as a mechanism for personal career advancement.
There thus may be less resistance than one expects.
I observe that OfficeOpen XML, the "standard" Microsoft ginned up and
rammed through ISO[2] to prevent standardization of LibreOffice's
OpenDocument/ODF format, has gone neglected since 2016,[3]
and Microsoft Office 365 has quietly--or perhaps grumblingly--been
revised to update new revisions of ODF as recently as 2022.[4]
Regards,
Branden
[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm
[2]
https://arstechnica.com/uncategorized/2007/03/microsoft-office-xml-gets-fast-tracked-to-iso-standard/
[3] https://en.wikipedia.org/wiki/Office_Open_XML
[4]
https://learn.microsoft.com/en-us/openspecs/office_standards/ms-oodf13/cef24f17-3e5e-4a13-9e16-aa1ebff5e1dc
signature.asc
Description: PGP signature
