Dates and Times

Meeting Location

Meeting information

Meeting Scribe: David Svoboda

Local contact information: Robert Seacord

1.1 Opening Comments (Seacord)

1.2 Introduction of Participants/Roll Call

1.3 Procedures for this Meeting (Seacord)

1.4 Required Reading

• 1.4.1 ISO Code of Ethics and Conduct
  
• 1.4.2 ISO Guidance and Process
  
• 1.4.3 IEC Code of Conduct
  
• 1.4.4 JTC 1 Summary of Key Points [N2613]
  

1.5 Approval of Previous Meeting Minutes

• Final 2025 (fall) WG14 minutes: [N3815]
  

  Moved by Davidson. Objections? None
  

• Draft Minutes February 2026: [N3814] (motion)
  

  Cranmer: I have changes that I have not sent Svoboda yet.
  Deferred until changes are resolved.
  

1.6 Review of Action Items

• Action Item: Seacord: Set up a meeting on iso.org for people to register for the Fall meeting.
  

  May or may not be done.
  

• Action Item: Seacord: Write a paper addressing Issue 1007 in N3773.
  

  Done
  

• Action Item: Colomar: Write a paper addressing Issue 1012 in N3773.
  

  Not done. Waiting on a newer draft.
  

• Action Item: Seacord: Add time to discuss the release schedule for C2y to the March agenda.
  

  Done
  

1.7 Approval of Agenda [N3826] (motion)

1.8 Identify National Bodies Sending Experts

1.9 C2y Schedule [N3827]

2.1 ISO, IEC, JTC 1, SC 22

2.2 National bodies in WG 14

2.3 WG 21

2.4 WG 23

2.5 MISRA C

2.6 Austin Group

2.7 Unicode Consortium

2.8 Other Liaison or Collaboration Activities

3.1 C Floating Point Study Group activity report (Bhakta)

3.2 C Memory Object Model Study Group activity report (Wiedijk)

3.3 C and C++ Compatibility Study Group activity report (Meneide, Nina)

3.4 Undefined Behavior Study Group activity report (Svoboda)

3.5 defer (Meneide)

3.6 Memory Safety (Uecker)

3.7 _Optional Study Group (Bazley)

3.8 Infrastructure Group (Meneide)

3.9 Create a Wording Study Group for WG14 (Gustedt) [N3822] (0.5 hours)

4.1 Future Meeting Schedule

4.2 Future Mailing Deadlines

Monday, 9 March

• Meneide, Anyfunc - A Universal Function Pointer Storage Type, r2 [N3782/N3810] (1 hours)
  

  Myers: I posted 4 questions, from my reflector message SC22WG14.35639. What is a universal function type? We want along-the-lines votes for these.
  Krause: I can see the use of a universal func_ptr_t type, and maybe even a macro. Everything else has too little motivation.
  Bazley: I like the idea of a function pointer type. The last thing I want to see is a predefined macro to say whether a pointer conversion is safe.
  Gustedt: I agree with printing things. I disagree with some of the PRI macros, this is really unnecessary invention.
  Bhakta: This paper does help with portability. If there is an alternative path, people use that.
  Meneide: Does conversion of function pointer to void* work? Yes, in 90% of servers and desktops. But on more esoteric platforms, they fail. This would allow people a more explicit way of saying they assume support for conversions.
  Ballman: This seems to be another novel way of feature testing in C. I could accept it. I am concerned about the wording, but that could be handled by a wording group. But I support the paper in general.
  Bazley: I am cynical about the ability of programmers to use these feature test macros correctly. Providing them implies a failure on the committee to specify the language more tightly.
  Ballman: We cannot just pick a direction in many of these cases, since many platforms have users and we do not want to break code.
  Bhakta: When you see a path that says "we do not support this" and error out, that prevents a lot of un-safety.
  Meneide: I will need some wording in the standard to bless what people have been doing for fifty years (i.e. pointer typecasting). These things will be conditionally supported whether we define them or not.
  Bachmann: For an unusual platform, I can not imagine development where this would not be recognized early on.
  Douglas: This would make writing Python bindings so much easier.
  Jabot: This paper would also be used by C++; we need it too. I do not mind the macros.
  Svoboda: This is a good idea. It needs a CERT rule. We already have EXP39-C, but that rule does not address function pointers. However, I have never seen vulnerable code make this mistake. I would bet the Linux kernel has wrestled with this problem, but I did not see it addressed there.
  Bhakta: We should not ignore problems that only affect 10% of code.
  Cranmer: In Rust, they decided uintptr_t and size_t are the same, and then they realized this is wrong, mainly due to CHERI, and could not change. We should avoid that. On Itanium a function pointer points to the function's descriptor. If we have an actual function pointer type, that would help systems work better.
  Meneide: We cannot.
  Straw Poll: For N3782 do we want to have something along the lines of a universal function type? 21-2-2
  Straw Poll: For N3782 do we want to have something along the lines of all the pieces about affinity and predefined macros for properties of conversions? 6-9-6 direction against
  Straw Poll: For N3782 do we want to have something along the lines of intfuncptr_t / uintfuncptr_t; 10-2-11 direction in favor
  Bachmann: I abstained because it is useful out of symmetry with other typedefs, but I do not care much about it.
  Krause: If B passes, then I can print function pointers by converting to integers.
  Bazley: If these were separate proposals, that would be the best outcome.
  Straw Poll: For N3782 do we want to have something along the lines of printf / scanf support? 11-5-6 direction in favor
  

• Krause, Named Address Space Type Qualifiers for C2y v3 [N3795] (0.5 hours)
  

  Bachmann: We should vote at least part of the named redefined address spaces.
  Cranmer: OpenCR follows these address spaces. It is not clear that GPU spaces follow this specification, if you make named address spaces be ordinary identifiers. LLVM used numbers for address spaces. I have some malicious ideas for what to do with address spaces. The stuff like sizeof should be consistent across address spaces. If you had an address space that is relative plus or minus 2GB to the current instruction pointer, this might be a plausible use case. What is the scope that you want for these address spaces?
  Krause: My proposal does not say anything about user-defined address spaces. Some implementations, including SDCC, do follow embedded CTR about how you use them..
  Łukasiewicz: I am in favor of this. We need to add something to indicate that a qualifier is an address space qualifier, a wrapper like memspace() to differentiate it from other identifiers.
  Bhakta: Does this paper address the defect in the TR?
  Krause: I do not know.
  Bhakta: Do you know of other major implementations of the TR?
  Krause: Iar and Keil have minor deviations from the TR SDCC and GCC try to follow the TR closely.
  Bazley: Can you reassure us the business of p and data pointing to generic data space?
  Krause: That is a space where Keil deviates from the TR.
  Ballman: The paper mentioned attributes as an alternative. I do not think type-based attributes is something WG14 is prepared to deal with.
  Krause: Yes, I should change that wording.
  Ballman: A named address spaces only affect how the hardware affects objects, but not which values they can have.
  Krause: An int has the same values in all address spaces, but a pointer will be different sizes in different address spaces.
  Opinion Poll: Do we want the "access qualifier" concept along the lines of N3795 in C2y? 11-4-8 direction in favor
  Decision Poll: Do we want to make the changes to the library functions using the wording from N3795 in to C2y? 4-6-10 not consensus
  Colomar: I do not understand this enough to vote in favor or against it.
  Jones: I have not studied this in enough detail.
  Bhakta: I was afraid this would change existing implementations.
  Krause: It does not change implementations, it just clarifies undefined behavior from passing a pointer to atomic like %s to printf().
  Bazley: I am not sure about the wording.
  

Tuesday, 10 March

• Karl, Designate the address of a struct/union's first member as the address of the struct/union [N3728] (0.25 hours)
  

  Seacord: ISO prefers notes rather than footnotes. Adding a note to the standard is an editorial change. You should contact Meneide.
  Uecker: It is a good idea to add a note. Would a pointer to struct be allowed to be compared to a pointer to the struct's first element?
  Karl: I do not know.
  Banham: To really improve things, we would allow direct typecasting from a pointer-to-struct to a pointer-to-first-element.
  Myers: This sounds like provenance.
  Bhakta: We had issues where people tried to do this with up-casts, it caused problems. I would oppose the use of this without casts.
  Bachmann: We could access another array by pointing to one beyond first array. Compare-equals does not imply anything else.
  Bazley: If containerof were standardized, that would be a legitimate way of up-casting in C.
  Svoboda: That paper would be dangerous. A typecast from struct to first element is good. But a cast from first element to struct is not good; it would add lots of potential mis-casts.
  Colomar: I am working on a paper to do just that.
  

• Colomar, Subdivide string API sections [N3671] (0.5 hours)
  

  Bhakta: I like organizing things. We have talked about having named sections in general. Are there any such plans?
  Myers: I do not think this is an improvement. Too many header levels makes things more confusing. It always requires more levels to classify things. We should also reorganize the Annex K functions.
  Colomar: There are ISO rules about not nesting too much. For our standard, this is normal. Annex K is not for handling strings, as we define them. As for this being confusing, the status quo is also confusing.
  Svoboda: I do not understand the "strn" category. The strncpy() function is unique because it can create a non-null-terminated byte string.
  Colomar: The "strn" category is designed to work with non-strings.
  Krause: Reorganizing things is not fully free, because of comparisons between different editions of the standard.
  Bazley: This is low-risk and low-impact. Our current taxonomy of functions is questionable. I would remove the "miscellaneous" category. It would be more effective to add non-normative notes describing our collected experience. So I would organize strings differently than you did.
  Gustedt: If we do this, we should replace "bytes" with "byte arrays" and replace "wide chars" with "wide char arrays".
  Svoboda: I too would like to see named sections. It would solve the numbering problem. Is it editorial?
  Seacord: Everyone has their own way of reorganizing things. So one organization is not particularly likely to succeed.
  

• Meneide, Improved attribute((cleanup(…))) Through defer, r4 [N3733] (0.25 hours)
  
• Meneide, defer Technical Specification (Committee Draft), r4 [N3734] (0.25 hours)
  

  Ballman: Thank you for your effort. Clang 22 shipped with an implementation of this TS, and received positive feedback. We are still open to changes from WG14, but we think this is ready to ship.
  Bhakta: Are there any differences between this TS and N3733?
  Meneide: There are a couple of typos, and some sections with the same wording. N3733 is for integrating with the IS.
  Myers: I posted a reflector message. Each of the papers has unique typos.
  Meneide: The wording in the TS said if you call an exit function, it does not run defer blocks unless the implementation indicates otherwise. This is because of existing practice.
  Gustedt: People are really excited about this. For the change with _Defer keyword, I think this is a good move.
  Bhakta: Thank you for matching existing practice.
  Seacord: N3733 is irrelevant now, because we are voting on N3734. N3733 is a source of confusion.
  Bazley: I do not see any logic behind which are ugly names and which are not.
  Meneide: The reason for providing both was to get a feel for implementations' appetites for "defer" versus "_Defer".
  Ballman: On the Clang side, the issue was that we could expose "defer" because it was a flag users could opt into. But to get into the IS, requires that there be no feature flag. And "defer" is used in the wild extensively as an identifier. Using the ugly keyword is standard practice.
  Opinion Poll: Do we want to allow implementation latitude where defer blocks run for specific exit functions in N3734? 6-13-4 direction not to allow implementation latitude
  Steenberg: Allowing implementations to not defer on exit can be very dangerous.
  Gustedt: I would not want to impose cleanup on small implementations. I would choose not to have it under any circumstances.
  Łukasiewicz: I am not a fan of giving functions special powers.
  Svoboda: Perhaps it should be implementation-defined, either exit always cleans up or it never does.
  Meneide: There is more support for vendors to not implement unwinding. It is very expensive.
  Decision Poll: Do we want to start publishing N3734 as the defer TS, modulo editorial changes and implementation latitude removed? 20-2-2 direction to make those changes and submit the specification
  

• Colomar, add a malloc(3)-based sprintf(3) variant [N3750] (0.5 hours)
  

  Bazley: I strongly support this paper. I agree that return-by-reference is really bad when not necessary.
  Jones: I appreciate the reasoning behind returning a char*. I am concerned about standardizing the less well-known allocating printf() API, especially for platforms that already have asprintf(). Also, there is no way to get the length of a string unless you use "%n", which has its own problems.
  Colomar: A compiler would reject code with an incorrect prototype. Calling strlen() later is minor since it is much faster than producing the formatted string in the first place.
  Svoboda: Why are there no other memory-allocations functions in C besides strdup()? It makes memory-safety analysis a little harder. Still, this is easier than getline().
  Colomar: GCC has a "malloc" attribute for functions that allocate memory, which helps static analysis.
  Krause: Use cases are common enough.. We should use something from the reserve name-space, like "str*" or "std*". The name does not indicate that this allocates dynamic memory.
  Colomar: I would agree with Plan 9's name: smprintf(). I would not like strprintf(); we should have consistent names. Usually libc implementations use "a" for functions that allocate memory.
  Ballman: The aprintf() and asprintf() functions having different signatures is not sufficient to solve problems that users have. You still have the cognitive burden of knowing both of these. I find 10,000 instances of "aprintf" as an identifier when searching user code.
  Bhakta: I would rather have a more general solution for beginners than adding individual functions. We should add "beginner" functions as a whole rather than piecemeal.
  Seacord: What about the sized_free() and requiring allocating functions to allocate the minimum size.
  Colomar: You are already not allowed to call sized_free() after strdup().
  Bazley: I think strdup() has already been useful.
  Opinion Poll: Do we want to adopt something along the lines of N3750 into C2y? 10-8-2 short of strong direction
  Opinion Poll: Do we want to adopt something along the lines of N3750 with better names into C2y? 14-4-3 strong consensus on direction
  

Break

• Meneide, Thread Attributes, r2 [N3690] (0.5 hours)
  

  Jabot: It is a mistake to provide that. People have tried to increase it on Linux for a long time. THRD_NAME_LEN_MAX should not be exposed.
  Gustedt: Remove _LEN from THRD_NAME_LEN_MAX.
  Bhakta: I like the general idea. But I dislike that you removed truncation. I do see a need for the THRD_NAME_LEN_MAX value.
  Opinion Poll: In n3690 do we want a THRD_NAME_MAX or THRD_NAME_SIZE_MAX macro? 6-9-7 weak direction for eliminating the name altogether
  

• Meneide, Integer Constant Expression-Initialized const Integer Declarations are Implicitly constexpr, r3 [N3693] (0.5 hours)
  

  Ballman: This is great. It would be nice to have an example that shows that a const int parameter is not valid, since it fails the last bullet point.
  Uecker: I like this paper.
  Myers: Do we want to require const declarations to satisfy the constraints for constexpr objects?
  Meneide: If you slap constexpr on a constant, the platform will start throwing more errors. Implementations have been letting tings be constants for quite some time.
  Gustedt: There is a typo in the wording: "of internal linkage" should be "or internal linkage". This could be fixed editorially.
  Meneide: I just published N3833 which fixes the editorial typos.
  Myers: I suggest we start the 30-day review process for N3833?
  Seacord: I am fine with doing the vote now.
  Decision Poll: Do we want to adopt N3693 with "of internal linkage" to "or internal linkage" into C2y? 16-3-4 strong consensus to adopt
  

• Colomar, Ignite annex I [N3756] (0.25 hours)
  

  Bhakta: I like removing things from the standard.
  Bazley: I structured the _Optional TS from the structure of the standard, and I included an analogue to Annex I. I do feel conflicted about this.
  Bhakta: If someone were willing to update Annex I, I would change my mind.
  Seacord: Removing this would blow a hole in our annex lettering scheme. Or do we leave the hole there?
  Colomar: I would prefer keeping the hole, or leaving an empty annex.
  Ballman: How certain are we that we have to collapse the annex letters?
  Seacord: We could take the last annex (M) and move it to Annex I.
  Jones: It is best to not rename or renumber the annexes.
  Colomar: I prefer keeping it empty and only fill it if we run out of letters.
  Ballman: There are lots of blog posts and other documentation that talk about annexes by name that we would have to rewrite.
  Decision Poll: Do we want to adopt N3756 into C2y and resolve the ensuing gap editorially? 13-4-6 strong consensus to adopt
  

• Uecker, Wording Improvement: Generation of Non-Value Representations [N3700] (0.25 hours)
  

  Svoboda: Is there an annex J.2 UB that corresponds to this? Perhaps UB 12 or 13 (from C23)?
  Uecker: I do not know.
  Gustedt: This wording change should not affect any UB.
  Decision Poll: Do we want to adopt N3700 into C2y as is? 20-0-1 strong consensus to adopt
  

• Uecker, Ghost: Values that do not designate an object (Updates n3701) [N3740] (0.5 hours)
  

  Myers: I posted to the reflector. Section 6.5 is a clause, not a sub-clause.
  Gustedt: I would prefer that this not only talks about objects, but also that the object must still be alive.
  Bhakta: Do you have alternative wording?
  Uecker: I had worse wording which was discussed on the reflector.
  Gustedt: Should we forward this to the wording group?
  Seacord: We agreed that we need a strong along-the-lines vote as a pre-condition to the wording group?
  Opinion Poll: Do we want to adopt something along the lines of N3740 into C2y? 19-0-2 strong direction
  Action Item: Wording Group: Please edit N3740.
  

• Douglas, Thread-safe signals handling [N3765] (0.5 hours)
  

  Cranmer: I am in favor of the idea of this paper. I want something that lets you try and catch a segfault. This lets us do it.
  Banham: Is the idea to remove asynchronous signal handling and make it synchronous? You are still relying on the definition of POSIX signals, that is where asynchronous signals have undefined behavior.
  Douglas: We coalesce asynchronous with synchronous. It does not improve that aspect. I also have a future paper that standardizes sig_wait.
  Jones: The intent is useful. But I am not comfortable with how it is designed. It seems to take a lot of effort in recovery.
  Douglas: In Windows structured exception handling is used, which looks a lot like setjmp() and longjmp().
  Krause: You introduce various identifiers, many in the reserved name-space. But some start with "thrd_". We should look into starting things with "synchronous" or "asynchronous" or things already reserved.
  Douglas: I have no trouble with renaming.
  Bazley: I am missing the motivation for the change. There are no usage examples. I ca not find a definition for type names like thread_signal_func_t. The way they are declared is weird to me.
  Colomar: Do we want a version parameter instead of separate functions?
  Douglas: Many people would point out that asynchronous items are usually from SIGINT. Why do we use the same functions for synchronous vs asynchronous signals?
  Seacord: Maybe we can refer this to the wording group?
  Myers: This straddles the ambiguity of our "along-the-lines" polls. Do we want just wording or do we need more design?
  Bhakta: I like the idea of having someone outside our group reviewing it.
  Opinion Poll: Does WG14 want something along the lines of N3765 into C2y? 15-2-4 strong direction
  Action Item: Wording Group: Please edit N3765.
  

Wednesday, 11 March

• Thomas, C2y proposal - Standard pragmas and headers [N3702] (0.25 hours)
  

  Ballman: Thanks, this seems sensible.
  

• Thomas, C2y proposal - Preferred quantum exponent [N3703] (0.25 hours)
  

  Banham: Is this providing flexibility to math library implementors?
  Bhakta: It corrects a nonsensical phrase. No implementations did this the hard way. We are not forcing people to an inefficient function implementation.
  Decision Poll: Do we want to adopt N3703 into C2y? 15-0-4 strong consensus, adopted
  

• Thomas, C2y proposal - Clean up frexp, ldexp, and scalene prototypes [N3704] (0.25 hours)
  

  Colomar: I have an alternative proposal, but I like this one better.
  Ballman: Were there other identifiers or is this just for "exp"?
  Bhakta: This was just for "exp".
  Gustedt: They would have appeared automatically in the index.
  Decision Poll: Do we want to adopt N3704 into C2y? 18-0-1 strong consensus, adopted
  

• Thomas, Proposal for C2y - Range bounds for math functions [N3731] (0.25 hours)
  

  Gustedt: I like where this is going. Here is an editorial change: this note talks about one of these functions but should apply to all functions, so the note should be moved somewhere.
  Bhakta: We discussed putting this note in all functions and dismissed that. They would get out of sync.
  Seacord: We no longer have to be as parsimonious with text as we used to be. No one prints the standard anymore.
  Banham: The underlying problem is rounding, even with the format issue. Should the standard introduce ULP (unit of least precision)?
  Bhakta: A floating-point implementation does not have to be binary. Decimal and hexadecimal floating-point implementations are possible. ULP could help in certain cases. It fits much better for values near 0, but not near π.
  Colomar: I disagree about the length of the standard. We could use a preamble for texts in printf() functions, this is similar.
  Myers: If we use a preamble, we need rewording as a whole to accommodate it.
  Bhakta: We want this paper in; we understand the problem about the note. We welcome future editorial changes.
  Bazley: I am looking at the ISO Guidelines, in particular: "The document should be usable without the notes". If removing a note makes it unusable, it should not be a note.
  Bhakta: The information is in the description; it is just more implicit. Dropping the note still leaves this text as correct; the note is there for clarity.
  Seacord: I do not want to pass this to our editor as is.
  Gustedt: If we have enough discussion, this can serve as direction for CFP to write another paper.
  Myers: We can vote with the comma added after "y/x", or we can do an along-the-lines vote.
  Decision Poll: Do we want to adopt N3731 with editorial changes into C2y? 13-0-2 strong consensus to make this change
  

• Bhakta, Floating expressions evaluated in translation [N3732] (0.25 hours)
  

  Myers: Note to the editor to please update Annex J along with this paper.
  Uecker: This "shall" was meant to be a requirement for the implementation not the user. But the "shall"s are often misunderstood.
  Banham: This is in the normative text as a semantic requirement.
  Ballman: This is clarifying that the requirement is for implementations not users. It does mean that a source environment must emulate the target environment when cross-compiling. So this is harder for compilers, but the text clarifies this.
  Decision Poll: Do we want to adopt N3732 into C2y? 14-2-1 strong consensus to adopt
  

• Thomas, Proposal for C2y - Refine the language of error reporting [N3737] (0.25 hours)
  

  Ballman: I have no concerns about the intent. But we use "occur" in the standard in many other places. So I am concerned about defining it here.
  Bhakta: It is used throughout the standard. We have verified all usages in the floating-point sections. This is only intended for the floating-point-sections. Could we limit the definition to that region?
  Ballman: That would be better but not ideal.
  Bazley: Even if you define "occur" here by italicizing it, people will not know it is a term of art elsewhere.
  Bhakta: Italicizing to define a term is a common convention in the standard (as well as other places). The idea of limiting the term to floating-point is a very large change. But I would not want to change the rest of the standard.
  Bazley: Does it actually matter that "occur" means that the error not only arises and is also reported?
  Seacord: I have never liked the convention of italicizing new terms when defining them. I do not think this change will be very impactful. I also do not like the phrasing "is said to occur". I prefer "An error occurs when…". I also like "an error is said to be reported when…". Perhaps take the word "occur" and its definition out.
  Bhakta: For this paper, I do not want to make too many changes.
  Gustedt: Italicized terms do get added to the Glossary. I would really like to have different terminology here.
  Ballman: Editorial question: Is there a LaTeX technique to distinguish our own special terms from English terms?
  Gustedt: There is a markup to make sure terms appear in the Index. We already have enough other fonts in the standard.
  Ballman: Does CFP think this problem is so worrying that it is worth the refactor?
  Bhakta: I do not think this is unclear, but I can not speak for CFP. The effort to fix this is more than the benefit we would get.
  Opinion Poll: Do we want to adopt something along the lines of N3737 with a different term than "occur" into C2y? 5-8-5
  Decision Poll: Do we want to adopt N3737 as is into C2y? 2-14-1
  Decision Poll: Do we want to adopt N3737 without the definition and italicization of "occur" into C2y? 8-1-7 strong consensus to adopt
  

• Thomas, Proposal for C2y - Preferred quantum exponent for afterburner [N3738] (0.25 hours)
  

  Decision Poll: Do we want to adopt N3738 as is into C2y? 13-0-4 strong consensus to adopt
  

Break

• Gustedt, Add type-safe minimum and maximum type-generic macros v3 [N3762] (0.5 hours)
  

  Colomar: This is a massive foot-gun. Every function and macro has a clear return type. But for this you must use auto.
  Gustedt: You must know your return type from the definition, but you do not have to use auto.
  Colomar: The type does not depend on the value, right?
  Gustedt: Right!
  Krause: This paper and Seacord's paper, if adopted, should go into stdint.h, not stdlib.h.
  Gustedt: I agree.
  Ballman: I am in favor of something along these lines. We did want the floating-point types removed. What about plain char and plain bool? I am concerned about how novel this is when working on promoted types? Please do not go with "is big enough to hold these values".
  Gustedt: You are right, that is weird, because our type system is weird. We could take this functionality and say the return type is able to hold all results, but that would force the return type to be auto. If you consider integer promotions, bool falls out.
  Colomar: It would be useful to get the min and max of two pointers, but this does not support pointers. I still prefer the usual min and max macros, where you rely on compiler diagnostics not to mix signed with unsigned.
  Gustedt: Not all pointers are comparable. In C only pointers from the same array are comparable. We can add support for pointers, but adding support for floating-point is even more subtle. These macros are not magical.
  Jones: Overall this is good. Here is one idea about the resulting type: For max type, taking the type with the larger maximum value. For min type when signed, both unsigned is larger one. That could be confusing in some case.
  Gustedt: When presented like that it could be confusing. A better way to present the idea is: For two values of same signedness, the wider type wins. For differing signedness, the signed type wins for min and unsigned type wins for max.
  Myers: I posted an editorial correction on the reflector: "of its width" should be "on its width". These operations become available for freestanding implementations if they go into stdint.h. What about enumerations?
  Gustedt: I agree with stdint.h.
  Bhakta: I would prefer these to be in stdlib.h, at least without a revision of the paper. This is because stdint.h does not claim to cover generic functions, so that requires changes to its preamble.
  Bazley: I am concerned about the following: Seacord's macros return a boolean result. Suppose you propose a new operator, would you consider adding new integer conversion rules?
  Gustedt: Yes.
  Seacord: This idea of not supporting BitInt types was built around the fact that Max(BitInt<1024>, intmax_t) produces a BitInt<1024>.
  Ballman: The fact that enough folks pointing out that this is novel means that this should go to CRFI. I am not convinced this is ready for standardization. I am currently on the fence about it.
  Douglas: If this were combined with N3776, I would love it.
  Myers: This is not suitable for CRFI. It requires language features to support the library feature.
  Gustedt: This is doable with current features of the language and library. It is a header-only implementation, which does function calls when the values are not integer constant expressions.
  Ballman: I am confused about why this is not appropriate for CRFI. This could be written without compiler magic, but needs C23. I think this is appropriate for CRFI.
  Bazley: What is the prior state of the art since there are already lots of implementations of min and max? Do they solve multiple evaluations?
  Gustedt: The prior art usually only supports same-signedness operations.
  Uecker: We can accept this paper now and a paper later that moves it to stdint.h.
  Ballman: Please do not decide to vote this in to one header file and change the header file later. Our users will hate us if that happens.
  Bazley: I think these should be operators.
  Decision Poll: Do we want to adopt N3762 as is into C2y? 5-10-5 no consensus
  Opinion Poll: Do we want to adopt something along the lines of N3762 using stdint.h into C2y? 10-3-6 strong direction in favor
  

• Seacord, Integer Comparison Macros [N3776] (0.5 hours)
  

  Svoboda: I really want the normative text to have some explanation why these are necessary. Add the example of -1 > 0u, for instance.
  Bhakta: I would not want this in stdint.h if it requires library functions for anything. (I had the same comment for the previous paper.)
  Colomar: This encourages mixing signed with unsigned types, and I do not want to encourage that.
  Ballman: I appreciate that this carves out plain char, enumerations, and bool. These are already deployed in C++.
  Seacord: Do you think these papers can operate on different sets of types?
  Ballman: I like the same carve-out on both papers.
  Bachmann: I would be opposed if this were mixed with Gustedt's paper.
  Bazley: I prioritize regularity, then type safety, then convenience. The ck_add() function does not support bool. There is a danger of creep possible here.
  Seacord: The ck_* functions could be expanded to include other types. We can extend types but not restrict them.
  Krause: That means enum types are always complicated. What would that mean for enums?
  Gustedt: An enum constant is type int, and an enum variable is of the enum type.
  Opinion Poll: Should these type generic macros from N3776 also apply to char, bool, and enum types? 6-8-7 not strong direction
  Opinion Poll: Do we want to adopt something along the lines of N3776 into C2y? 11-3-6 strong direction
  Pygott: Does that include the previous paper which is "along the lines of N3776"?
  Seacord: No. It is just the opinion poll, it does not mean anything.
  Bazley: I would be more inclined to vote if you include expected use cases.
  

• Krause, bit-precise enum [N3705] (0.5 hours)
  

  Ballman: I left BitInt out of enum types because it seems like a big foot-gun, especially in variadic situations. You can already have this with long long for enums. I am a little scared about quality-of-implementation.
  Serebrennikov: Now we have enums with fixed or non-fixed underlying types. This makes things more complex. Is the term "enumeration type" of any use?
  Colomar: I agree that the foot-gun is problematic, but it still makes sense to allow implementations to do this, so they can opt in to this.
  Decision Poll: Do we want to adopt N3705 as is into C2y? 8-5-7 not strong consensus
  Bhakta: In your extension, is this a permissible extension where you do not have to diagnose it?
  Krause: It is a constraint violation.
  Bhakta: That would change my vote.
  Decision Poll: Do we want to adopt N3705 as is into C2y? 9-4-8 strong consensus, adopted
  

• Uecker, Uecker, Clarifying Undefined Behavior for the Indirection Operator (Updates N3711) [N3741] (0.25 hours)
  

  Douglas: I did not like this although I usually like Uecker's UB papers. I do not like all this extra text. In WG21, we encourage implementations to use hardware to check that an object exists. This spelling-out of UB would constrain the hardware. For me UB causes UB San to emit a diagnostic. I find invalid pointers to make a lot of sense.
  Uecker: We have all the UB's still there, which permits hardware checking. I hope to convince you that this is not an issue of how you define what constitutes an "invalid pointer".
  Colomar: I prefer to spell out the one-past-pointer without spelling out one-past-last-element, because of zero-length arrays. You could say "not pointing to an object". I like this paper, but I am a little worried that being explicit might be redundant with other standard text.
  Uecker: I moved all other notions of invalid pointer into the footnote.
  Bhakta: There are other places where we add invalid value to a pointer we would need to add it here as well. Could this make it worse?
  Cranmer: There are other cases of invalid pointers you have not brought up, such as violating restrict rules. People might interpret your list of invalid pointers as exhaustive but it is not.
  Uecker: The list was intended as exhaustive. The list was motivated by the Provenance TS. A pointer from an integer is implementation-defined.
  Serebrennikov: In C++ we say single-variables like int is a 1-element array. Then at the end, we say, "shall point to location in the address space with sufficient space". We also say, "It shall be correctly aligned for the type".
  Opinion Poll: Do we want to adopt something along the lines of N3741 into C2y? 11-1-9 clear direction
  

Thursday, 12 March

• Svoboda, How to Slay Earthly Demons and UB#90: Invalid #include directives [N3710] (0.25 hours)
  

  Gustedt: We should have UB#90 as an extension point. Whether it can be implementation-defined is another question. This issue is similar for the #embed directive. In that, implementations add other attributes to the directive without having UB. It is important to leave the extension space. Implementation-defined could be something like "if other syntaxes are allowed is implementation defined".
  Serebrennikov: Can you expand on option 2? Why do you conclude a constraint violation is not an extension point?
  Svoboda: A constraint violation means it is a fatal diagnostic. That is, No object file is produced. So you could not extend it.
  Serebrennikov: Where does the standard require stopping translation?
  Svoboda: It is in section 5.
  Serebrennikov: If my implementation has a vector type, I want the multiplication operator. The constraints say the operand for multiplication must be an arithmetic type. That means it must be diagnosed and cease compiling. Multiplying two matrices would not be arithmetic types.
  Svoboda: It depends on what the standard says about arithmetic types. You can extend the standard to allow matrix multiplication.
  Serebrennikov: Why can you do that there, but not for #include constraints?
  Svoboda: That is outside my knowledge. Right now it is not a constraint violation. I was talking about making it one.
  Serebrennikov: An array of ints is not an arithmetic type.
  Seacord: Stopping translation is not a requirement.
  Ballman: A constraint violation does not require stopping translation. The compiler just has to emit a diagnostic. Implementation-defined just means that we do not have to have a diagnostic. I am fine with making this a constraint violation.
  Bazley: The example given in the paper is not illustrating what is said in the paper. Once the errors are fixed, GCC and Clang compile the code.
  Svoboda: I agree.
  Bazley: I agree with Ballman. Why is this in UB? I would expect a failure to parse the file.
  Ballman: My understanding is that this allows an implementation to allow different forms of macro expansion within an #include directive. The end point was "" or <> after expansions. I took this as a restriction on the implementation and not the user. I have not found any implementation where this is used.
  Jabot: C++ made the effort to remove UB during phase 1-6 of translation. What does it mean for the preprocessor to be undefined? It is a constraint violation in C++. No one uses it so why not remove it?
  Gustedt: It should be an extension point. The #embed command has the exactly the same wording and we need the extension point.
  Bazley: This question means should we keep UB?
  Svoboda: I want the question as is.
  Serebrennikov: If you vote No in the poll, how are you going to disallow extensions?
  Svoboda: I would make it a diagnostic.
  Opinion Poll: Does WG14 believe UB 90 (from C23) should be an extension point? 2-9-6 strong direction against
  

• Svoboda, Busting Another Ghost: UB#11: Value of auto Object [N3714] (0.25 hours)
  

  Ballman: I thought we added this explicitly to make it clear that reading an indeterminate representation is UB.
  Svoboda: I do not know.
  Seacord: I cannot remember.
  Uecker: There is no normative text. It is just leftover text.
  Ballman: This came in N2861 by Uecker.
  Decision Poll: Does WG14 wish to remove UB#11 from C23 as specified in N3714 in C2y? 10-0-7 strong consensus, adopted
  

• Uecker, Earthly Demon: Conversion of Pointers to Integers of Insufficient Size [N3712] (0.25 hours)
  

  Ballman: This should not be a constraint; we accept this with a warning diagnostic. An explicit cast can represent programmer intent. I have found 15,000 instances of people disabling this warning.
  Bhakta: I see a lot of use of this extension point. It is used, using a pointer's bottom bits for alignment.
  Myers: I mentioned a typo here on the reflector, but there are other issues.
  Uecker: The wording was adapted from the previous wording.
  Cranmer: Even with weirder address spaces, converting pointer to undersized integers is truncation in some sense.
  Łukasiewicz: Regarding usability, there was a snippet converting 32-bit pointers to 16-bit ints. There is use in casting wider pointers to narrower ints. I am not sure it should be a constraint violation.
  Uecker: You could get UB converting to a large integer and then a smaller signed integer. But we could remove UB for the unsigned case.
  Colomar: We could restrict it to do two levels of casts, using intptr_t as an intermediate type.
  

• Uecker, Uecker, Type Compatibility: Ghosts, Readability, and A Missing Rule for Atomic (Updates n3713) [N3742] (0.25 hours)
  

  Myers: I sent comments to the reflector as [SC22WG14.35405]. I think option 1b does not work and option 1a might have problems. We need various additional statements about qualified and atomic types and campatability.
  Uecker: This might be something for the Wording Group.
  Gustedt: It is definitely for the Wording Group.
  Opinion Poll: Do we want to adopt something along the lines of N3742 into C2y? 17-0-0 strong direction to proceed
  Action Item: Wording Group: Please edit N3742.
  

• Múgica, Generic replacement, v. 2 [N3722] (0.5 hours)
  

  Myers: This is a reasonable change.
  Bhakta: I know it is prohibited elsewhere. It would make more sense to have balanced parentheses.
  Colomar: This would make the rules about parentheses inconsistent. Why should we remove them in this case?
  Gustedt: We have removal of other parentheses.
  Ballman: Given the wording questions, I would like these papers to be combined. But we could vote this one in first.
  Gustedt: We could vote this in but not the older paper. I suggest that we vote it in indirectly, or we could do an along-the-lines vote and pass to the Wording Group.
  Ballman: What exactly are we voting in?
  Uecker: We could vote for the first change, and can discuss the second change.
  Bhakta: The surrounding parentheses are new, the braces are not.
  Decision Poll: Do we want to adopt the "Main" proposal from N3722 with editorial fixes into C2y? 10-3-4 strong consensus to adopt
  Decision Poll: Do we want to adopt the "Immediate Constant" proposal from N3722 as is into C2y? 9-4-5 strong consensus to adopt
  

• Múgica, What are the operands of Generic, v. 2 [N3721] (0.5 hours)
  

  Ballman: This breaks existing code, that is why I oppose it.
  Colomar: I would like to see this against the draft from the new text of N3722 before voting on this.
  Ballman: I found N3721 to be impossible to discern what the edits are doing. This paper could be voted in, but I also want the rebase before voting.
  

• Múgica, Discarded, V [N3724] (0.5 hours)
  

  Myers: I had reflector comments at [SC22WG14.34195].
  Ballman: I am not comfortable with this. This paper has more interactions with the papers we just adopted. I am also unsure which standards the author was writing against. He should rebase this against the latest C2y draft.
  Gustedt: This would be suitable for the Wording Group.
  Uecker: Would you want to see this again in a WG14 meeting?
  Seacord: It would be suitable for online approval if we get an along-the-lines poll.
  Serebrennikov: Why can you not see that everything discarded was also discarded?
  Colomar: If you have a VLA, you evaluate the operand, but the operand might not be evaluated perhaps because everything is in a sizeof(). This language improves that a lot.
  Opinion Poll: Do we want to adopt something along the lines of N3724 into C2y? 12-2-5 strong direction,
  Action Item: Wording Group: Please edit N3724.
  

Break

• Colomar, The Elvis operator ?: [N3804] (0.5 hours)
  

  Krause: The implementation experience is excellent. But I am not convinced that the use cases warrant standardizing this. How much is it actually used, and what is the advantage over the classic ?: operation?
  Colomar: It is worth it for calling realloc() safely.
  Uecker: This is simple. I use it a lot.
  Seacord: I have a bunch of editorial comments.
  Colomar: I would like to reject those editorial comments. I prefer "is not evaluated twice" over "is evaluated exactly once", because this might be inside sizeof. We say the second operand, but I have the sentence that says the first operand also becomes the second.
  Ballman: The design is good, but this does need some wording tweaks.
  Opinion Poll: Do we want to adopt something along the lines of N3804 into C2y? 15-1-3 strong direction to proceed.
  Action Item: Wording Group: Please edit N3804.
  

• Colomar, Add operators _Minof and _Maxof [N3748] (0.5 hours)
  

  Krause: This does not seem important enough to add to the language. How does it work on floats? This could be done with macros.
  Colomar: This only works for discrete integer types. Macros do not scale for BitInt.
  Myers: I posted comments to the reflector at [SC22WG14.34865].
  Ballman: I agree with Krause, I do not see motivation for this. There are more operators that would cover this functionality. The bar for new language features is very high.
  Seacord: Should this work on expressions? I do not like the inconsistency with sizeof.
  Jones: This comes up inside libc functions, such as strtol(). You need to know what the max and min values are. You need to use macros or template the function for this to be necessary inside of libc. We also implemented this, but we did it the C++ way.
  Colomar: For what it is worth, glibc, nolib, and every libc I have looked at implements this.
  Krause: If you are saying that lots of C libraries already have this, that is sufficient motivation for me. If this is a language operator, extending to expressions seems less intuitive to me than sizeof.
  Colomar: We were more careful to make it available only for types, and not standardized for values.
  Meneide: We can avoid supporting expressions until we figure out what to do with bit-fields. I would be more in favor of this paper if we had widthof.
  Colomar: I split the paper because I still have an unanswered question: What type should widthof return? Also, widthof is still very useful, but most useful implementations of widthof are for min and max.
  Gustedt: I disagree that this is simple for BitInts, particularly for signed types.
  Cranmer: If you have widthof, you can compute min and max directly.
  Seacord: Should this apply to chars and bools? A recent opinion poll was evenly divided on the issue. We should keep the types consistent with other papers.
  Colomar: This should apply to enumerations and char. I am not sure about bool. In the end, we accepted bool.
  Opinion Poll: Do we want to send N3748 with updates to the Wording Group? 6-10-4 direction not to forward.
  

• Uecker, Dependent Structure Types [N3745] (0.5 hours)
  

  Myers: I posted comments at [SC22WG14.34543]
  Bazley: I strongly support this proposal, based on the experience of a colleague. He had written a struct with a void pointer. This would have made that code type-safe and convenient. This is syntactic sugar.
  Krause: We have two changes; you need both for everything you want. But Change 2 is much more expensive than Change 1 and Change 1 also has more implementation experience. How useful would Change 1 be in isolation?
  Uecker: I am asking for this as a GCC contributor, not just a user. For a compiler without variably-modified types, Change 1 is more expensive. But from the language perspective, Change 2 is more inclusive.
  Cranmer: In the example on page 2, does the vector initialization have UB?
  Uecker: Perhaps. I should fix that.
  Opinion Poll: Do we want to adopt something along the lines of N3745 into C2y? 11-7-4 weak direction
  Ballman: I could change my "no" vote. I am not convinced that it is a good design direction to push users to more variably-modified types. This simplifies stuff but only for the people who already know the feature well. More deployment experience could persuade me.
  Bhakta: I also want to see more implementation experience.
  Uecker: GCC has just the syntax change.
  Colomar: Change 2 has no implementation experience. This is a very old extension.
  Meneide: My objection is similar to what Ballman said. I work with people who built C compilers, and their biggest trouble was along VLAs and variably-modified types.
  

Friday, 13 March

• Douglas, C Lingua Franca Results [N3766] (0.5 hours)
  

  Seacord: I am concerned about the schedule. We plan to be feature-complete by April 2027. We would need papers for the features that this depends on.
  Douglas: This will not ship for 2027. I expect it will probably be done in the 2030's. It spent 7 years in WG21, and Rust and COBOL standards committees will have their own opinions.
  Bhakta: The author is OK with waiting. There is no need to rush this.
  Celeste: This seems like something that lives and dies based on adoption by other languages.
  Douglas: The Python people never got back to me. The Rust people should love this.
  Bhakta: I like the idea of this as a reference implementation for standard C. I also like the idea of a CRFI process for this.
  Łukasiewicz: As a prototype, this is good. As a final product, most of this should be hidden by the compiler. People will not want to type it out by themselves.
  Seacord: When I hear "boilerplate", I associate it with AI. Could an AI reliably generate this for you?
  Douglas: AI's understand reference implementations very well.
  Uecker: How changeable is the design of names? I prefer much shorter names.
  Douglas: Agreed. I thought the C names should replicate the names from the C++ library.
  Colomar: I have not seen anything similar in code-bases I have looked at. Our charter says, "Uphold the character of the language". This should first go into a library and go in the standard only if it gets widely used.
  Douglas: If this gets popular, people will not want to change it then. It is a chicken-and-egg problem.
  Bhakta: Implementation experience is the key for anything along these lines.
  Łukasiewicz: (via chat) Regarding generating boilerplate with AI: there is no need for clankers. Any half decent code editor has functionality for snippets and macros. The problem is in having all that code blow up the size of final source code.
  Douglas: It is interesting how little assembly code is churned out by old source code. Will the C edition be as optimize-able as the C++ edition? I do not know.
  Seacord: It bothers me that the returns are not explicit.
  Douglas: We need a try operator. But it is hard to propose in WG21. It is easier to get existing practice in place and standardize that.
  Seacord: It is worth trying. WG14 tends to like proposals that were rejected by WG21.
  Serebrennikov: You mentioned three main compilers. But you can not extrapolate Clang & GCC behaviors to smaller compilers and optimizers.
  Douglas: We support Swede bindings generator, which is very old-fashioned, it almost supports C89.
  Opinion Poll: Are the ergonomics presented in N3766 acceptable? 6-3-14
  Seacord: I mostly like it. I interpret from this vote that many people have minor gripes with it.
  Colomar: So many abstentions might be considered something negative.
  Seacord: This is a weak "yes". When I see a high number of abstentions, I try to find out why.
  Adams: The danger of abstaining is that I might not use it, but it may be forced on me.
  Svoboda: I thought for decision polls, the yes votes must be 50% of attendees, as well as being more than twice the no votes.
  Seacord: In Brno, there was no math about the number of abstentions. I will find out what was actually written down.
  Bhakta: Abstains should not be counted at all, otherwise it is up to the convener's discretion.
  

• Celeste, Allow arrays of incomplete element type [N3777] (0.5 hours)
  

  Gustedt: I like the paper. The semantics are clear, so the Wording Group could handle this.
  Seacord: We adopted a model where this goes to the Wording Group and then to an online vote.
  Myers: I do not see anything in the new document that addresses my concerns about interactions with debuggers. There is something reasonable here. We need an analysis of the impact on debuggers.
  Celeste: Arrays of functions are only there because I figured they were harmless. I can remove them again. Arrays of void are the things that I actually want. There are examples of how this can be handled.
  Seacord: Getting rid of array of functions is beyond a wording change. I do not know if the Wording Group could handle that.
  Colomar: As maintainer of a documentation project, I already use this as part of documentation. It would also be great for tooling that does static analysis.
  Opinion Poll: Does anyone object to removing "arrays of functions" from N3777? 0-13-4 people want to remove "arrays of functions"
  Ballman: I agree with Myers, there are technical issues with the paper, so it is not ready for the Wording Group.
  Opinion Poll: Do we want to adopt something along the lines of N3777 into C2y? 13-7-2
  Jabot: I am concerned because this affects C++. WG21 would want to look at this paper.
  Ballman: My "no" vote is because I see this as having risks. Why was this restricted in the first place?
  Na: My concern is about the new info on array of incomplete types. You do not know what the size of n void objects. This will confuse tools that do bounds checking analysis.
  

• Gustedt, C semantics for contracts, v2 [N3789] (0.5 hours)
  

  Colomar: Every similar feature added to standard C, which are static array parameters, restrict, were bad. It would have been better if they were about diagnostics and constraint violations, not optimization. This should be about guarantees and constraints to make the language safer.
  Bhakta: I like the idea. There are lots of details to be resolved. We also need implementation experience.
  Berne: I have done a lot with C++. Contracts say two things, assertions say only one. Contracts enable optimizers to use them. You have cases where people use contracts, add a bug, and then they get UB with unpredictable results. They then reject contracts. This proposal needs to be aware of that. We need to allow people to adopt contacts safely and correctly.
  Gustedt: If contracts are verified, then semantics should always be the same (regardless of compiler options). We also should not abuse the language to add debugging interfaces to callbacks or do instrumentation. The assert macro is in a section by itself. We should not mix up tests or features with contracts.
  Bazley: I like the syntax. I hope C gets something like contracts. C already has existing contracts like "static" in array bounds.
  Gustedt: The reason the old interfaces are bad is that they are not consistently applied between callee and caller.
  Kleynhans: You will have to look wider than C because C becomes a universal interface. We need implementation experience.
  Krause: Attributes are the right way to introduce contracts because they can be ignored. This looks like a huge implementation effort.
  Gustedt: I do not think it is a large effort.
  Berne: I want to push back that contracts are not a diagnostic tool. They are simply a way of encoding something you expect to be true. It can fuel a diagnostic rule or optimization, static analysis, etc. Contracts in C++26 succeeded because everyone can use them for these things, whatever they needed. This goes on function declarations, not just function bodies.
  Gustedt: If we have contracts, we should also have function annotations and debugging. For multi-language support, there is no ABI change.
  Colomar: Should side effects should be allowed in contracts? No, they should be constraint violations.
  Gustedt: People want to do functions calls, so that is impossible.
  Tarditi: I like this proposal. It is important to be compatible with C++ contracts. Apple has experience with bounds checking, I would be happy to discuss our experience. Contract failure should not turn into UB. How do you want to proceed?
  Gustedt: A study group is too formal for now, but an informal group would be good. We could start with a mailing list.
  

If time (be prepared to discuss)

• Colomar, Add operator _Typeas [N3634] (0.5 hours)
  
• Colomar, Add _Assert(), not depending on NDEBUG [N3760] (0.5 hours)
  
• Steenberg, Add N3607 to the list of papers that should be applied to previous standards [N3778] (0.5 hours)
  
• Thomas, Proposal for C2y - Annex F floating-point environment updates [N3779] (0.5 hours)
  
• Meneide, Expression Evaluation and Access in _Generic, r0 [N3785] (0.5 hours)
  

Scheduled for online vote:

• Colomar, Adopt qualifier conversion rules from C++ [N3749] (0.5 hours)
  

Not yet scheduled:

• Meneide, embed Synchronization, r3 [N3811] (0.5 hours)
  
• Múgica, Array constant expressions [N3787]
  
• Szewczyk, Variadic-argument introspection: VA_COUNT and VA_SLICE [N3792]
  
• Colomar, add strchrcnt(), strchrscnt(), wcschrcnt(), wcschrscnt() [N3664] (0.5 hours)
  
• Múgica, array ICE subscript out of bounds [N3791] (0.5 hours)
  
• Almkainzi, Namespacing with prefixes [N3794] (0.5 hours)
  
• Colomar, disallow function parameters of function type [N3798] (0.5 hours)
  
• Colomar, incompatible array parameter [N3799] (0.5 hours)
  
• Colomar, [static n] should not access more than n elements [N3800] (0.5 hours)
  
• Colomar, [static n] == nonnull [n] [N3801] (0.5 hours)
  
• Colomar, array parameters of 0 elements [N3802] (0.5 hours)
  
• Colomar, [static] without array length expression [N3803] (0.5 hours)
  
• Colomar, named arguments after varying arguments in macros [N3805] (0.5 hours)
  
• Almkainzi, Unselected _Generic branches should be ignored [N3809] (0.5 hours)
  
• Munger, Memory allocation with size feedback [N3813] (0.5 hours)
  
• Łukasiewicz, Clarify terminology for obsolete features, v2 [N3818 ] (0.5 hours)
  
• Ornato, Function contracts [N3825] (0.5 hours)
  
• Coates, Slaying Some Earthly Demons - remove UB 28, 29 [N3772]
  
• Coates, Slaying Some Earthly Demons - remove UB 30 [N3771]
  

Removed/deferred by request of author:

• Múgica, Array notation for vectorization, v. 2/ [N3717] (0.5 hours)
  
• Na, Dependent attributes, v2 (updates n3656) [N3796] (0.5 hours)
  
• Meneide, Transparent Aliases, r6 [N3689] (0.5 hours)
  
• Colomar, Liquidate Annex L [N3757] (0.25 hours)
  
• Colomar, C source files are text files [N3633] (0.5 hours)
  
• Grüninger, Add min, max for integers to C [N3160]
  

8.1 Review of Decisions Reached

8.2 Review of Action Items

8.3 Re-approve Agenda