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

• Draft Minutes August 2025 [N3684] (motion)
  

1.6 Review of Action Items

• Action Item: Seacord: Submit TS 25007 to SC22 for balloting.
  
• Action Item: Ballman: Apply N3532 to the obsolete versions of the standard.
  

  Ballman: Done
  

• Action Item: Seacord: Work with Simonsen to update the WG14 reflector.
  
• Action Item: Celeste: Contact Bhakta about the Canada (Fall 2026) meeting.
  
• Action Item: Douglas: Check with POSIX for direction for issue 1004 in N3609.
  

  Douglas: I have now reached out to POSIX about this issue, so my action item is now completed.
  

• Action Item: Bhakta: CFP to submit a paper as per reflector message 30480.
  

1.7 Approval of Agenda [N3812] (motion)

1.8 Identify National Bodies Sending Experts

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 New Study Group proposal (if applicable)

4.1 Future Meeting Schedule

4.2 Future Mailing Deadlines

Monday, 2 February

• Gustedt, Clean up atomics, non-normative changes, v7 []N3788] (5 min, poll only)
  

  Decision Poll: Do we want to adopt N3788 into the working draft for C2y? 20-0-3 strong consensus
  

• Celeste, Remove the imaginary I, v3 [N3786] (5 min, poll only)
  

  Bhakta: I object to just voting. We did not get to discuss this. For the list of changes, I see two changes. Is that the complete list of changes? Or are there future changes?
  Celeste: No, this is all the changes we planned.
  Decision Poll: Do we want to adopt N3786 into the working draft for C2y? 23-1-1 strong consensus
  Bhakta: I would like to hear the reason why there was a vote against.
  Myers: There was incompatibility for writing code for C99 inwards.
  Bhakta: Our vote was purely on the wording so we accepted this.
  

Break

• Belov, Considering expressions based on restrict pointers as pure rvalue expressions [N3659] (0.5 hours)
  

  Bazley: "restrict" is so wrong that it is unfixable. Your proposal does not adequately fix them. I recommend deprecating the "restrict" qualifier and replacing it with an attribute. I have a proposal for enhancing type variance. The idea that restrict is a qualifier falls apart when you add type variance.
  Serebrennikov: What is missing here is feedback from implementers. I would like to see this kind of discussion, and I also want feedback from compiler developers.
  Gustedt: Thanks for this talk. We have had several issues with "restricted" over the years, such as it is not part of a function's interface. I also think "restrict" is unfixable, and should be replaced by a qualifier (not an attribute).
  Cranmer: I have always interpreted this as: as long as you can trace back to the original pointer definition, you cannot say a restricted pointer is "based on" a function call. Rust developers have worked with stack borrows and tree borrows; I can link to that paper. They have operational semantics for "restrict" that is a lot better than what we have now.
  Ballman: In Clang/LLVM we have a hard time rolling out support for "restrict". Strengthening "restrict" breaks too much real-world code to be practical. I also agree "restrict" is broken. But I do not think WG14 should invent a response; I would prefer that "restrict" be deprecated.
  Celeste: For middle & back-end feedback, it is possible to come up with a simplified rule set with better semantics. We can clamp it down.
  Colomar: It turns several instances into UB. We should add diagnostics. But yes, "restrict" is broken.
  Cranmer: We have a new WG for formal semantics; we will talk about restrict patches. The WG should discuss this.
  Tarditi: We need more than just middle and back-end people on this, we need more on the semantic side, before we deprecate it.
  Belov: I suggest that we limit the semantics of "restrict". It would be great to deprecate "restrict".
  Seacord: It sounds like we would like to see a paper that deprecates "restrict" from C2y. We want implementation experience for a replacement.
  

• Celeste, `auto` as a placeholder type specifier, v3 [N3579] (0.5 hours)
  

  Krause: There is a lack of motivation here. This would bring us more in line with C++. But what benefit does this provide to users?
  Celeste: Users like being able to write "auto* ptr = …". This was suggested by compiler authors.
  Banham: What are the ramifications of "auto" as a storage class?
  Celeste: It did not do anything; it was always implicit in local variables.
  Bhakta: With regard to the change to define under-specified declarations, do you know any implementations that would break or do something else?
  Celeste: The only implementations I know are GCC and Clang.
  Ballman: Thanks for this paper. It allows us to better modify the standard in the future. Making "auto" a type specifier makes it easier to read.
  Bazley: I also support this. This is very in-line with the design of C syntax.
  Seacord: If we have final wording by the end of this week, we could vote on this in the March meeting.
  Gustedt: I would really like more explicit wording. I can help if you like, Celeste.
  

• Meneide, Functions with Data: Closures in C, r1 [N3694] (1 hours)
  

  Bazley: Perhaps we should have a "lambda" study group, given how many proposals there are in this area?
  Bhakta: I suggest that we not continue on after the official meeting is over, even though the presentation is not done.
  Ballman: If we do polls, polls should be about the same discussion as the paper.
  Uecker: I think we should poll after discussing the other "lambda" papers.
  Opinion Poll: Would WG14 like to see something along the lines of N3694 adopted? 16-7-4 not strong consensus
  Seacord: Would anyone who voted "No" clarify their vote?
  Bhakta: My "No" is because I want to see all the proposals.
  Bazley: I feel bad about voting "No". I have misgivings. Markus said the true strength of C is its simple syntax.
  Ballman: My abstention could become a "Yes". I would like to see all the papers, but nothing is on fire here. I like this the most of all the "lambda" proposals. I do not think we will solve this in the next couple of years.
  Adams: This proposal is not ready. Could it be merged with Uecker's proposal? To solve my problem I must write a lot of code using local functions.
  Seacord: The vote count has changed, it is now: 16-5-3.
  

Tuesday, 3 February

• Adams, Local functions [N3678] (0.5 hours) and Literal functions [N3679] (0.5 hours)
  

  Bazley: I love this; it wins over closure proposals due to discover-ability. I have a misgiving about whether the "static" storage class specification should be used for function literals, because this diverges from the design of nested functions. I am not concerned about leaking the addresses of these functions.
  Celeste: I support this as is. I do not think these need to be set in opposition to capturing closures. Bring it in without the specifier for now.
  Gustedt: It is valuable to have these two proposals. We need to make progress on this for C2y. It is also good to not restrict GCC-nested functions.
  Jones: My perspective is from libc. Are we planning to add additional C functions for support, a la qsort()?
  Seacord: There are no proposals to add these functions. But someone could bring one forward.
  Adams: We cannot declare thread-local inside these functions.
  Bhakta: This gives you basic C syntax that works throughout the language. With regard to static and auto, these things can be decided later.
  Liber: This is useful on its own. Why cannot an optimizer merge the two functions with static variables?
  Gustedt: The as-if rule. You can observe function pointers.
  Bazley: The actual benefit of "static" is: It is good because it does not trample on what GCC already does.
  Serebrennikov: I am optimistic that we can have this today, and captures in the future. I am hearing too much optimism about adding captures.
  Adams: This proposal could be extended by allowing capture but disallowing conversion to function pointer.
  Opinion Poll: Does WG14 think a proposal along the lines of N3678 and N3679 without captures is useful? 16-5-7
  

• Uecker, Accessing the Context of Nested Functions [N3654] (0.5 hours)
  

  Bazley: You are mixing a few ideas here, which is confusing. Closure is used to indicate which parameter provides data.
  Uecker: It would be better to use a different keyword.
  Celeste: I am not a fan of implicit lifetime extension. This is a C++-ism I would prefer not to bring in.
  Uecker: I did not propose implicit lifetime extension. You have to go: memcpy() then a closure to extend it.
  Cranmer: The room seems to think that we can go with simple stuff for now and add closures later. It is not clear that the simple stuff will continue to support the closure space. Theoretically, we can use wide pointers for closures. We have to support compatibility.
  Bhakta: I like the idea of keeping backwards compatibility with GCC-nested functions. This proposal gets different from normal C; it seems more complicated.
  Adams: In my opinion, proposals using capture have some examples where they are easy to use. For the same amount of code but without new concepts for manual capture. I do not see a solution yet.
  Bazley: Is this proposal dealing with capture by reference or capture by value? There is no syntax to differentiate from Meneide's proposal.
  Uecker: In my opinion, we should always capture by reference, the semantics are easy to understand. You need to work out lifetimes of things you wish to access.
  Ballman: This is all doing capture by reference, right? I am concerned for LLVM IR being able to do this; it is value-based. I am not sure LLVM IR has facilities for doing this.
  Celeste: There is a critical difference between C++ capture-by-reference and this, right?
  Cranmer: I have done middle development. You want to have access to the outer stack frame, using that supported by the code API. I worry that people might have API expectations.
  Tarditi: I implemented an optional language with closures for my PhD thesis. My concern is that it would make our security issues worse. C lacks expressivity with regard to lifetimes. And anything encouraging void pointers is problematic. Closures are a form of an existential type. I would want to see the security issues with more complicated lifetimes.
  Uecker: The lifetime issues here are not more complicated than taking the address of a function.
  Tarditi: Function pointers are more difficult to reason about, and require a higher level of abstraction.
  

Break

• Thomas, Clarification of range error condition for atan2v [N3646] (0.25 hours)
  

  Seacord: I do not see the need for this change. If the word "end" is ambiguous, how far do we need to go to reduce ambiguity? But I am OK with this change.
  Decision: Any objections to adopting N3646 by unanimous consent? None
  

• Thomas, Semantic rules for constant evaluation [N3647] (0.25 hours)
  

  Decision: Any objections to adopting N3647 by unanimous consent? None
  

• Thomas, Improved language for return type vs. return value [N3648] (0.25 hours)
  

  Bazley: Do these need to be brought to the committee?
  Seacord: These do not, they may be editorial. But this could justify a Wording Study Group.
  Gustedt: The later paper has a certain amount of text changes.
  Decision: Any objections to adopting N3648 by unanimous consent? None
  

• Uecker, Earthly Demon: Accessing a Member of an Atomic Structure or Union (Updates n3624) [N3653] (0.25 hours)
  

  Ballman: I am in favor of this paper. It might be helpful to add an example to show we considered the other qualifiers. But we can add that later.
  Bhakta: I do not think we should be adding examples in the meeting; they should be proposed in papers.
  Seacord: Over time, examples tend to get removed from the standard.
  Celeste: This encodes a MISRA rule as a constraint, so MISRA blesses this.
  Decision: Any objections to adopting N3653 by unanimous consent? None
  

• Łukasiewicz, Clarify terminology for obsolete features [N3642] (0.25 hours)
  

  Ballman: Improving the terms is reasonable, but I do not like this direction. I do not like a feature being phased out of active use. I prefer "this feature will be replaced by that feature" or "this feature will be removed in the standard".
  Bhakta: Did anyone look through the standard to make sure these terms are used correctly?
  Łukasiewicz: Yes, I did look through them.
  Myers: We should not be adding orphan definitions, and we are not using the terms "obsolete" or "deprecated". If we want to add new terms, we need to add places where they are used.
  Łukasiewicz: "Obsolete" would be used in the introduction. "Obsolescent" is already used.
  Seacord: I would prefer to see wording that some feature is "obsolete".
  Celeste: I asked for this when discussing the octal thing. People only care about these terms because of the threat of removal.
  Johnson: Here is what Fortran does: it has both "obsolete" and "deprecated". "Deprecated" means the feature gets removed in the next edition. "Obsolete" is for things that are still there, but a conforming implementation need not support them and you should not use them.
  Bazley: There will be people who read the standard who disagree with these definitions. I sense a pipeline from "obsolete" to "obsolescent" to "deprecated" to "removed". I suspect "obsolescent" should come before "obsolete". I am not sure we can really use these terms.
  Bhakta: I disagree with Celeste; I think there is a point to having a non-threatening term. We have lots of customers with old code they never want to touch. They would be scared by the threat of removal.
  Ballman: If you have no threat, nobody moves on it. I think we need to determine what we want. The current situation is confusing.
  Seacord: The word "deprecated" is problematic because we have a deprecated attribute. We do not have any official deprecated features, and any such uses of the term "deprecated" are overwhelmed by the attribute.
  Bazley: I now think we need only "deprecated". All the rest is wishy-washy.
  Gustedt: I think "deprecated" is the wrong word.
  Seacord: We have used "obsolescent" in the past. Perhaps we should just define "obsolescent" to mean "feature planned for removal".
  Bazley: The only word we have used in my products is "deprecated". It also aligns with the dictionary definition. The fact that users can use the attribute means that it is the right word.
  Ballman: K&R C function definitions have been obsolescent since I was born, and was eventually removed. And the term "deprecated" is widely used in industry.
  Banham: The reason for "obsolescent feature" is to indicate what the Committee considers modern programming.
  Opinion Poll: Do we want to see any changes along the lines of N3642? 3-10-12 strong consensus against
  

• Banham, Make implicit undefined behavior in mtx_destroy() explicit [N3655] (0.25 hours)
  

  Seacord: When we added this to C11, there were a lot of UB's in concurrency. This vagueness was considered intentional, in order to get concurrency added. I like making UB explicit here, but this will not be the end of this sort of thing.
  Banham: I added this paper last summer, we have two papers from Gustedt that start to deal with this iceberg.
  Bhakta: I am not sure what it means to violate a "shall" that can only be determined at run time. So I think the first option does not work well. The second option is better. So I would recommend option 2 over option 1.
  Jones: There are more UB's lurking in C11 threads.
  Gustedt: There is more vagueness; what does "attempting to lock" mean? I also prefer the 2nd option. But 1st option is OK, "shall" here implies UB. My proposal does not compete with this one; we could accept both this proposal and N3763.
  Bazley: I thought option 1 was adequate. But I am not sure option 1 contains the same meaning, what about threads that obtain the mutex and have not released it?
  Banham: I think option 2 more directly conveys the race condition.
  Krause: I tend to prefer the short alternative. Most readers do not think of destroying a mutex while it is held. The 2nd option seems to be too much. Option 1 is a clear improvement, but I cannot understand the case of the thread already holding the mutex.
  Ballman: WG21 has a study group for this kind of problem…have they seen this paper? I can put you in touch with the SG chair.
  Banham: Not to my knowledge.
  Opinion Poll: Would WG14 have a preference for option 1 over option 2 in N3655? 3-18-4 clear preference for option 2
  Decision Poll: Would WG14 like to adopt option 2 of N3655 into C2y? 17-0-7 strong consensus to adopt
  

• Gustedt, Properly specify the interaction of library calls for mutexes v3 [N3763] (0.5 hours)
  

  Bhakta: I agree with this in principle. But in paragraph 1, you have "after writing the lock-entry". "Writing" is a term I do not understand.
  Gustedt: It is used for atomics: writing and reading them.
  Bhakta: In paragraph 4, why do you disallow multiple mutex_init operations? Are you disallowing more than one mutex_init?
  Gustedt: Yes, it does not say that explicitly. Multiple simultaneous mutex_inits is implicitly UB.
  Bazley: My comments are about punctuation, so we can discuss them offline.
  Seacord: Could you handle the writing by saying "the following function calls are considered writing"?
  Gustedt: No, because it is not just the function calls, it is more complex.
  Seacord: Perhaps this should be brought before WG21.
  Gustedt: Hans Boehm has seen them. I would like to show WG21 something that WG14 agrees on.
  Ballman: If you call mtx_destroy on an uninitialized mutex object, it should be UB, but this next text seems to allow it. Must it be a pointer type?
  Gustedt: No, the rest of the phrase forbids that.
  

Wednesday, 4 February

• Gustedt, Properly specify the interaction of library calls for condition variables v3 [N3764] (0.5 hours)
  

  Bhakta: I have the same issue here as with as N3763.
  Seacord: Do we need to include various wake-ups in the description?
  Bhakta: Do you want the change where mtx_init() cannot be called multiple times on the same mutex?
  Gustedt: I am interested in technical feedback for implementations that need one or the other. I do not have enough feedback to decide on that.
  Ballman: What is the harm in allowing a mutex to be initialized multiple times?
  Gustedt: Resource leakage
  Banham: If you re-initialize a mutex already in play, you may be resetting its state when another thread was locked on it. What do we mean by multiple initializations of a mutex?
  Gustedt: Yes, that was one of the reasons I forbade multiple initializations.
  Bazley: Bhakta, why do you want multiple initializations to be valid?
  Bhakta: I am not suggesting that we have to do this. But I have seen user code with an initialization function that initializes a bunch of mutexes, and sometimes customers initialize duplicate mutexes.
  Jones: I think LLVM will be fine with multiple initializations.
  Gustedt: You still need to know that no one is locked on the mutex.
  Krause: The new wording just makes it UB to re-initialize a mutex. UB is a safe way to handle that, unless we have a way to define it.
  Bhakta: I am fine with leaving it as UB. I am just wondering if this is a common thing; then we may want to make it well-defined.
  Bazley: I do not think resource leakage is the only consideration. I have had linked lists of mutexes. The effects could be much worse than resource leakage.
  Ballman: I worry when I hear "it is UB but you can use it as an extension point".
  Svoboda: I have a paper in the backlog proposing "extensible UB".
  Opinion Poll: Would WG14 like to adopt something along the lines of N3763 into C2y? 17-0-5 direction to see this again
  Opinion Poll: Would WG14 like to adopt something along the lines of N3764 into C2y? 17-0-5 direction to see this again
  

• Lenga, cleaner c/c++ headers boilerplate with ‘extern’ blocks [N3458] (0.5 hours)
  

  Bhakta: I like the idea. I do not know of any implementation experience on C. We are supposed to only standardize features with existing implementation. Do any C compilers do this?
  Lenga: From my reading, Clang & GCC share front ends, so the work is relatively small.
  Celeste: I do not see how this could be a problem. This is not likely to get pickup for awhile. People would start asking if they can put something besides "C" in the quotes, such as for handling external C++ or Rust code. This also begs for a Wording Study Group, that could help you with wording if we decide to move forward.
  Serebrennikov: This would be helpful 20 years from now. I do not see how this would be picked up in the next decade. It does not interact with the rest of the language.
  Jones: This is useful, but we won't be able to drop #ifdef's until we drop support for C23 in our public headers.
  Łukasiewicz: This is best solved by a library.
  Bazley: I am against this. C++ syntax is semantic nonsense. That is not what "extern" means. I do not want people to write C headers like this. Putting "extern C" before every C functions would wreck the C language. An automatic code formatter would also get screwed up by this. This could be a slippery slope, shoving bits of other languages into C. You could also solve this using the preprocessor.
  Meneide: I have practice with an "extern JVM" blocks recently. It is something people do.
  Ballman: If we go with this, I would want full language linkage, but not the way C++ does it. C++ links it as part of the type system. I did not find any user requests for a feature like this in Clang's issue database. I did find "extern Fortran" in OSS projects, but it is very rare.
  Celeste: Language linkage is part of the type system. I remembered a piece of backwards implementation experience. But name-mangling will only happen over my dead body.
  Ballman: I was not advocating for a definition of what "extern C++" does in C, we would only specify a language linkage for C; others can add other languages if they want to.
  Opinion Poll: Would WG14 like to adopt something along the lines of N3458 into C2y? 6-7-10 no direction to proceed
  

• Svoboda, WG14's C indentation and brace styles [N3650] (0.5 hours)
  

  Łukasiewicz: I emailed about one true brace style. Example in the paper is not OTB style but Java style. OTB style does not omit braces where this is a single block.
  Svoboda: I took the indentation conventions from Wikipedia. I can take them from somewhere more authoritative, such as the Jargon file.
  Seacord: Here is something controversial, I propose taking this to the next step. I would like to see WG14 publish a coding style because I work in automotive and the standard we follow says we must follow a coding style. There is confusion among auto people about the difference between a coding style and a coding standard. My opinion is that a coding style is a rule that does not affect the generated executable. If it does require you to change the source code and the meaning of the source code then it is not a style rule. Today, on this very day, I was forced to write a style guide for Woven by Toyota. I do not want to decide. I would prefer to defer to an authority such as WG14. If WG14 were to publish a coding style then that would solve a pretty big problem. I do not care what's done in the standard; that is a secondary concern. The standard could choose not to apply the official style. It would be useful to have an official ISO C coding style document.
  Meneide: As editor, I was going to install a tool that would format every code block in the standard using Clang format. I did not want to think about it, I just wanted to enforce a style. If we decide to do nothing then that saves me effort. If we decide to do something then I'll just run clang-format. I was going to format everything with the tool because I don't want to spend too much time on it.
  Krause: I do not want the editor to make changes. That was not one of the offered options. It is good to have some variety. I do not want to encourage the editor to make changes. I do not think WG14 should publish a coding style. We should not have that authority. It would start enforcing a coding style. In SDCC I have to follow a coding style even though it is not what I prefer. I do not think we should use the authority of the Committee to enforce a particular one.
  Svoboda: Options 3 or 4 do include what Krause wants. It sounds like Krause wants option 3.
  Bhakta: I think that Krause's idea is different from option 3. Options 3 and 4 allow the editor to put whatever coding style they want. Krause is suggesting that the editor does not get the option to do that.
  Seacord: That would mean that the committee would squabble about the formatting of examples.
  Bhakta: We do not do that now.
  Seacord: At the moment we follow option 3.
  Meneide: The only time I change the formatting of code is if the code goes outside an hbox. Otherwise it goes in as you give it to me.
  Bhakta: Let us suppose Meneide changes his mind or another editor comes in.
  Seacord: The proposal determines style. We should add an option 5: Enforce no style, and forbid the editor from modifying the style of any new code that gets added.
  Celeste: I agree with Krause. The C standard should be value-neutral and should not try to have a policy. Here is a technical reason: "missing braces and inconsistent white-space are valid"/have no meaning. I do not like the idea of doing anything other than demonstrating a wide variety in the examples.
  Bhakta: I agree with Celeste and Krause. Our editor should only edit a code example to fit in its box. A style guide is another bad idea. We do have some form of authority, like it or not. We should not be picking winners, even if it is a separate document, coming from WG14/ISO does have meaning, especially for large corporate clients.
  Gustedt: I want to go with option 5. I do not want a special document. It would take too much time. We should not go into that discussion and should not waste our time with it.
  Pygott: If there is a style guide, MISRA will not be falling on it and demanding it. We are completely agnostic so far as style goes. I do not like the idea of option 5 (use whatever style the proposal includes). If the proposal is presented in a way that is somehow offensively laid out then the editor should be allowed to change that.
  Seacord: I want to make another case for a style guide: Many styles exist. We have some authority. There is too much freedom of independent thought and freedom is dangerous. People in the community have wasted thousands of hours of labor time arguing. We can all agree that time was wasted. Without an official thing to point at, that waste will continue. I also have an immediate problem: I need to have one now, so it is zero effort for me. We could stop the religious arguments. It would provide some value to the community.
  Serebrennikov: To discover which is closer to the reality on the ground, how many people use Clang-format without changing the default style? Those people would be well-served by a style guide from the committee. Weigh that against the people who pick Clang-format and write a long list of rules. They probably do not want the standard style. That would be an interesting data point.
  Bhakta: I disagree with a lot of the ideas of the style and some of the assertions there. If we do not follow our own style guide in the standard then that makes us look worse. In the field, despite what was asserted, there is not a problem with different styles in the real world. It does not need to be settled one way. Religious arguments will continue either way. We're not getting benefits with a style guide, only detriments. There is no real benefit to having a WG14 style guide. In terms of the comment that Seacord made, that's great, but that doesn't need to be.
  Bazley: Sorry, this is all my fault because I saw a style in a UBSG document that was so strange to me that I just assumed it was a mistake and "fixed" it. That style was simply an opening brace of a function body on the same line as a declarator. Seacord doesn't need to wear Woven and WG14 hats at the same time. Maybe he underestimates the time needed for the really difficult task, which would be getting WG14 to agree to the new style guide. Most organizations have a house style. ISO/WG14 not having one for the C standard risks looking incompetent. The idea of WG14 adopting a house style is attractive because it is likely to be one that I can accept, but it is also dangerous because it might be one that I hate. I recently switched to working on GCC and I was shocked by their code style because I had never seen it before. I thought that no one could have invented a worse style if they tried. I still do not like it, but since I installed Clang-format and a plug-in for VS Code, I do not care anymore. I think the only defensible choice is K&R style because they invented the language and understood their design choices. Whether or not their style is error-prone or unclear is a red herring because as Celeste said, the standard should show that strangely-formatted code still works. That is a very different question from what style an organization should use.
  Opinion Poll: Does WG14 want the code examples in the standard to comply with any particular indentation style? 3-16-6 we do not want to enforce anything
  Svoboda: I would be OK with a WG14 style guide as long as (1) it is confined to a SG and (2) ISO C need not comply with it.
  Opinion Poll: Should WG14 publish a style guide outside of the standard? 6-16-3 direction against
  

Break

• Svoboda, Educational Undefined Behavior [N3534] (0.5 hours)
  

  Gustedt: I like this. I recommend saying "Unconditional UB" rather than "Static UB". Static suggests it can be detected by the compiler. It should be more precise about the terminology.
  Svoboda: One of us made up the term 'Static UB'. I personally am fine with that change.
  Cranmer: Who is the intended audience? Some of the ways that you define stuff is not helpful for people who have just started programming in C.
  Svoboda: The audience is C programmers, not implementers.
  Bhakta: The WG14 charter is a bit heavy-handed about "eliminating UB".
  Bhakta: There was a thing about adding to the charter. I know we do not really follow the charter, it's just a guideline document, but it should be limited to removing harmful UB.
  Svoboda: The charter says UB should be "eliminated or reduced". Eliminating them is an impossible dream. We try to reduce them.
  Bhakta: What about UB that is an extension point? Without context, the charter implies that all UB is a bad thing.
  Seacord: If you want to be in the editorial group then email Svoboda. Eventually this will come to WG14 and we'll decide using our usual convention of strong consensus if we want to publish this. I suggest an along-the-lines vote for now.
  Svoboda: I assume the editorial group is separate from the UBSG? Does it need a separate mailing list?
  Seacord: Do whatever you want, whatever is convenient.
  Bazley: I do not think we should have a new study group.
  Seacord: It wouldn't be a study group, just an editorial group. We had one for Annex K. An editorial group would do whatever is necessary to finalize the document.
  Liber: I agree with Bazley. My goal is to make sure that nothing contradicts the standard. The document should say that the standard is the source of normative truth.
  Seacord: I had some issues with the first draft; it was scary: "If you want safety and security in C then F-U". I see the author has changed. If there is no author then this is just a product of WG14. It means it would have more status in the community. If it comes from one person then it is just that guy's opinion. Something from WG14 has more gravitas.
  Svoboda: This should not be a UBSG document. It should be a WG14 document at the end.
  Seacord: I was misled by the byline.
  Opinion Poll: Should WG14 publish something along the lines of N3534 as a white paper? 23-0-3 strong consensus to publish
  

• Svoboda, Examples of Undefined Behavior [N3677] (0.5 hours)
  

  Seacord: Every time I see this document, it looks like an annex. I always think why is this a separate white paper and not an annex or appendix to the educational white paper?
  Svoboda: When I originally conceived this, I thought code examples could be added to Annex J.2. But that would make it bigger than everything else. That is why I'm pushing for this to be a separate white paper.
  Seacord: The examples are quite educational. Having examples in an educational document would be quite helpful. As a standalone paper I do not see this so much. You mentioned putting this into Annex J.2. One of the things we could do with C2y is that we could take any amount of the standard and make it an attachment or separate file, so it would only be part of the downloadable content.
  Svoboda: How is that different from an annex?
  Seacord: It would be part of the standard but not part of the document. I believe that ISO prices the document based on the number of pages. In an extreme case, we could just have a cover sheet and the remainder of the standard would be these downloadable files. Price would go from hundreds to pennies. That's the extreme case. We could do something in-between like only the annexes published like that, or only the annexes and the library.
  Bhakta: The last time that we looked at this paper, we talked about having the code examples be runnable. Has anyone done any work on that?
  Svoboda: We have a script that extracts them into files, many compile. I do not think we have actually tried to run them.
  Bhakta: Can we have these extraction scripts as part of the paper or is it not meant to be public?
  Svoboda: It is Python code.
  Bhakta: Can you publish the links to the Python code?
  Svoboda: OK
  Seacord: One question that comes up is why target C23? We know what it is. It is unfortunate that UBSG only hit its pace after the publication of C23. Consequently, the state of UB in C23 is a bit of an embarrassment. It is much better thought out now. In C2y we will have addressed "ghost" UB's. We have also addressed UB's that should have been implementation-defined. We have really cleaned things up which is a testament to the UB study group. A white paper is a document to communicate something with users and we are not showing our best face.
  Svoboda: It is an accident of happenstance. C23 is still the best face we have so far. I acknowledge that work will be needed to update the document for C2y.
  Johnson: I recommend Carnegie Mellon's secure-coding site for UB information. From a committee perspective, I get the value of the document here, and it is a good document. I am just wondering if there is a way we could promote or integrate this into other widely-used and widely-accepted sources of stuff.
  Svoboda: If you want this to be integrated or mapped into the CERT C Coding Standard then you should talk to me.
  Johnson: How do we tie these two together so that we have something from the C standard committee and it's also prominently available on CERT's Secure Coding site?
  Seacord: This doesn't really stand up as a standalone publication.
  Svoboda: I am asking for different things. The educational document is a one-time thing, whereas I do hope this document will evolve as C evolves.
  Seacord: You want to publish this as a what then?
  Svoboda: A technical report or a technical specification, but today we will just publish this as a white paper.
  Seacord: We are not going to vote on the future edition of this because we do not know what it looks like and we cannot bind a future WG14 committee. If this were an annex to the educational document then in the future you could publish an update. After you release it, I would be surprised if people didn't point out problems and there will be things you want to evolve.
  Ballman: In WG21, they are doing exactly the same thing but it is going straight into an annex. How is this going to be versioned? Is there going to be a date? If it is published as a white paper and I cannot discover updates to it then that is a problem.
  Seacord: I am not aware of any versioning mechanism for white papers. I am not aware of anywhere they are published. If you Google for ISO white papers then you find them in different places associated with the different groups that publish them.
  Svoboda: When we started working on this, I wasn't thinking of a white paper, but instead of a TS or TR (because TS has a lot of pain associated with publishing one). Likewise, people will wonder if you have examples of UB, then do you have examples of implementation-defined behavior, and other behaviors listed in Annex J?
  Bhakta: Is there any plan for publishing a list of UB's that are extension points?
  Gustedt: In the standard, we have a list of common extensions.
  Svoboda: I am receptive to that, it is just more work.
  Seacord: I do not see this as a white paper. I would vote against that. I see this as an annex to the C standard, but being updated for C2y.
  Svoboda: I think Seacord means that the paper we are discussing becomes part of the Educational UB document, and later an annex for C2y.
  Opinion Poll: Should WG14 publish something along the lines of N3677 as a white paper? 5-8-10 direction against
  Opinion Poll: Should WG14 publish something along the lines of N3677 as an annex to the Educational UB white paper? 11-6-6 direction we want to go
  Opinion Poll: Should WG14 publish something along the lines of N3677 but updated to C2y, as a new annex to the standard? 16-1-6 strong consensus
  

• Bazley, Alternative syntax for forward declaration of parameters (v2) [N3681] (0.5 hours)
  

  Bhakta: I sympathize with the more general solution. We have removed functionality that C used to have for 10+ years now.
  Gustedt: I never liked this syntax, but we need a solution here and now.
  Ballman: We voted against this proposal before, and this new proposal brings no new information. This paper missed one of the four things that happened: GCC developers went with an approach Apple proposed at our last meeting. This feels like vote-shopping.
  Bazley: That info did not exist at the time that I wrote this.
  Myers: There are still various wording issues, this is not ready to integrate as is.
  Na: There is an alternative proposal that uses attributes.
  Banham: Is that a submitted paper?
  Seacord: We had a paper (N3796 and N3656) from Apple in Brno.
  Na: Yes, and we have updated that paper; it is ongoing. We addressed comments on what expressions can be used inside attribute. We are also adding concrete attribute.
  Bazley: I had misgivings about the first version. At what point are the invariants exposed by these attributes expected to hold true? I prefer something like contracts.
  Na: Contracts is an orthogonal feature to attributes themselves.
  Celeste: I am not convinced that these exclude each other. Is there time pressure to finish this?
  Serebrennikov: In Brno, we had two papers, foreign declarations and attributes, which we discussed together. I do not think it is correct for this paper to be discussed without the other. Perhaps we should postpone this paper until March and discuss both together.
  Gustedt: I do not think we should postpone, because these papers are not contradictory. We have seen these papers many times.
  Serebrennikov: In Brno, we decided these papers have an intersection. There is an overlap in motivation.
  Bazley: In my opinion attributes are ignorable, not part of the type system, and so not a language feature.
  Seacord: These are different approaches to solve the same problem.
  Krause: I do not think we can change the parameter syntax to be closer to the K&R one.
  Decision Poll: Would WG14 like to adopt N3681 into C2y? 9-15-4 consensus against
  

Thursday, 5 February

• Jabot, Preserving LC_CTYPE at program start for UTF-8 locales [N3539] (0.5 hours)
  

  Ballman: This will not impact existing code, right?
  Jabot: It only changes the locale.
  Bhakta: I disagree with this paper, there are many programs that use the existing default. There is no benefit to this that they cannot do right now if they want to. This provides cost but no benefit. If you system has a non-C UTF-8 as a locale, it changes if you change to C.UTF-8, your program will break silently. The default locale for C programs is "C".
  Jabot: If your locale is not UTF-8, this proposal should have no effect.
  Myers: What does the POSIX liaison think about this paper?
  Jabot: I do not know.
  Jones: We are not planning on this in LLVM, but this would be handy for us.
  Gustedt: Any implementation is allowed to have UTF-8 for their locale, right? So this does not change much, it just forces C locales to be UTF-8 if the platform supports it, right?
  Bachmann: I like this, it has prior art in MUSL. We should wait for a response from POSIX.
  Bhakta: I feel the opposite, I do not like forcing the implementations to have a certain default if it is available.
  Jabot: I do not think this forces anything.
  Gustedt: It forces only on really specific circumstances.
  Jabot: If I have an EBCDIC platform, it will not be forced to switch to UTF-8, that would be very bad.
  Bazley: Implementers could have the local "C" denote UTF-8 if they want to. It is strange that some locale is selected automatically at program start.
  Jabot: That is the issue, we already change the locale in a way that breaks code in the presence of UTF-8.
  Colomar: This should be discussed in email between Bhakta and Jabot.
  Bazley: At least one person here has confused LOCALE with a macro.
  Krause: At program startup the locale is overwritten with "C". With this paper, perhaps this becomes "C.UTF-8". I see the problem, but I do not see how this paper changes that problem.
  Jones: It seems this does not change anything unless the system is already in UTF-8 mode.
  Bhakta: My concern was not about EBCDIC; it was about users who do not expect the locale to change. My concern has been partially addressed. The issue is still there, it is just smaller. My concern is that users who do want "C.UTF-8" could set it themselves today. If they do not set it, they do not want it.
  Seacord: I understand that with this paper, you might lose the locale without having a solution to address that.
  Bazley: Maybe everyone uses UTF-8 now, but that was not always true and may not be true in the future. To me, why prefer UTF-8? Without it, users would have a choice of automatically setting the locale to "C" or to the empty string. This seems strict and too tied to UTF-8.
  Jones: This will make some types of programs a lot more understandable. If you try to print a wide string using glibc, you get nothing if you do not set the locale to the empty string, because the C locale does not have a proper conversion from wide strings to multibyte. This paper would fix that.
  Bhakta: Jabot believes customers are surprised by seeing a "C" locale in their programs.
  Opinion Poll: Would WG14 like to adopt something along the lines of N3539 into C2y? 13-7-6 weak direction
  

• Colomar, add stpspn(), stpcspn(), wcpspn(), wcpcspn() [N3663] (0.5 hours)
  

  Krause: Saving the programmer the extra step of doing pointer arithmetic does not justify adding these to the standard library.
  Bhakta: In the wording you say "offset", but it should reference the text that the original functions do, and that says "length". You should be doing that rather than saying "offset".
  Celeste: The ergonomics of this are nice. But I am not comfortable with an explosion of utility functions.
  Colomar: By that argument, the string library, except for a few functions like memcpy(), is all a lot of wrappers around simple for loops.
  Liber: The only motivation so far is your one project. This needs wide usage.
  Colomar: People write their own wrappers and everyone's wrappers are different.
  Jones: I disagree that the standard library should only provide functions that cannot be provided elsewhere. There are a lot of string functions. If these are really that useful, we would have seen them as a BSD extension or GNU extension.
  Bazley: I am not keen on the name, but I am inclined to support this. The standard library is not adequate as an OS abstraction layer. I do trust Colomar's judgment; he writes a lot of string-heavy code.
  Seacord: I joined C 25 years ago to make it more secure, and string library functions are one of the sources of in-security. I tend to vote against these functions as making the matter worse. We do have a mechanism for functions that do not need compiler support; they can go into a Boost-like library. I had to find a library of algorithms shortly after starting to use C, and this is still a problem after 40 years.
  Steenberg: I think we look at the standard library slightly wrong. It is a list of popular functions. But C has evolved into many different implementations. If we tried to document how something is supposed to work, and asked all the standard library developers to implement them, we have lots of experience with that. So the things we should add are things that compilers can use intrinsically and optimize, and cannot be added by users. There has never been a Boost for C, and that is because of the psychology of C programmers; they have a "not invented here" mindset.
  Meneide: I do not think that having these functions is a bad thing, but I need to see instances of these functions in the wild. How much have other people encountered the problem. The C library is Spartan and not well-designed. I would like to see more research into how widespread the need for these functions are.
  Colomar: I did not add this code to shadow-utils; I was just finding patterns in code with for loops. Also Oracle has this as a string library function: strrspn().
  Opinion Poll: Would WG14 like to see something along the lines of N3663 into C2y? 4-17-5 strong direction against
  

• Gerasimov, Mandatory diagnostic message on missing return statements [N3483] (0.5 hours)
  

  Celeste: This looks like C++-style wording. We initially had concerns about data analysis on this, but those may not be valid anymore. This is a reasonable thing to demand in modern compilers.
  Gustedt: I agree. "Unreachable" is not a problem; you can add it to statements or control flows.
  Myers: I noted issues on the reflector. The issue is not just simple control flow: What happens if you have a loop? Does a statement cover all possible values of a type? What if you have a goto? We would have to define a standard version of "control flow".
  Svoboda: I like this, since it replaces UB with a constraint violation. This seems to be permitted for main().
  Gustedt: There is explicit wording for main().
  Svoboda: Then this document should explain how the new wording interacts with main().
  Bhakta: Not every compiler can do a lot of control flow analysis. To accept this, we need to add to the standard some form of control flow analysis, and Myers has explained some of the problems with that.
  Ballman: Control flow analysis is an issue because of compile-time overhead. We had to downgrade a Clang diagnostic to a warning. People write wrapper functions that we cannot always analyze correctly. Sometimes people use assertions, and then do not handle those cases.
  Opinion Poll: Would WG14 like to see something along the lines of N3483 into C2y? 9-9-6 neutral
  Bhakta: We have had multiple implementers say that this is a problem to implement. Why do people vote in favor of it?
  Bazley: I voted yes to "along the lines" because this is worth pursuing, and getting input from compiler vendors.
  Gustedt: I agree. I do not think false positive diagnostics are harmful here.
  Uecker: It can be implemented at the front end.
  Svoboda: The problem can be solved partially, perhaps we need more research or wisdom on what is possible.
  Seacord: Apparently people have different interpretations of what an "along-the-lines-of" poll means.
  

Break

• García, typeof(return) [N3454] (0.5 hours)
  

  Gustedt: I like the idea. But I do not think we should abuse the return keyword for this. I would prefer to have a symbolic object variable.
  García: I forgot about the reasoning behind using return inside typeof instead of defining a new keyword. I am not keen on particular syntax, but return inside typeof seemed like a good idea.
  Liber: If we have proposals with automatic return deduction, that will interfere. I cannot declare this type of function.
  García: Yes, you are right.
  Colomar: There are other proposals like function literals. I would like those to settle before deciding on this. This does not have a strong use case now.
  Opinion Poll: Would WG14 like to see something along the lines of N3454 into C2y? 9-9-6 no direction
  Banham: I voted "no" because the motivation was not clearly set out, it is entirely about doing very obscure things.
  Douglas: I have an enormous use case. I maintain Boost-outcome and have a try macro. In C++, we do not know in the try macro what a function will return. If I could determine what the function type is, that would be very useful to our use case. The big problem is how to implement this. I would prefer if you could ask the compiler for the return type of a function.
  Jones: I voted "no" mostly on the anonymous structs point. How useful would this be without structs?
  Cranmer: I think the motivation of this paper is too weak. It is not clear how this would work with other proposals.
  Uecker: I voted "no" because it is a special case in how the keyword is used. I would want the return type of any function, not just the function I am in.
  Meneide: You could subsume this functionality by having a translation-time inspection of function types. There is a ton of motivation of being able to programmatically determine a function's type info.
  Seacord: This was a nice first paper. Please continue to participate in the committee.
  

• Bachmann, Make pointer type casting useful without negatively impacting performance - updates n2484 [N2658]
  

  Cranmer: Most people should understand how optimizers do alias analysis. In practice, your use cases will actually work, even if they are UB. I am reluctant to approve this because defining what constitutes the obvious cases turns out to be tricky. Rather than allowing the cast operator to violate strict aliasing rules, we need a fundamental primitive.
  Bachmann: Sequence points already have a meaning now. A new language construct would not break old code, and we have that with the proposal that introduces the byte type. I would like this poll: To achieve the goal in N2658, is it necessary to do something not already covered by N3254?
  Gustedt: The problem with that poll is that we haven't read N3254, so you will not get a valid answer from that question.
  Uecker: The byte arrays allow you to do some things, but you could already do that before.
  Cranmer: Is the question you are asking, do you think this new way of opting out of strict aliasing rules is useful?
  Opinion Poll: Does WG14 want to make type-punning in local context via pointer casts well-defined? 7-6-8 no direction
  Bachmann: That response means my 2nd question is obsolete.
  Cranmer: This might be an interesting question: Do you want to add a feature to permit violating strict aliasing?
  Colomar: We already have features for violating strict aliasing.
  Opinion Poll: Do you want to add another feature to permit violating strict aliasing? 13-3-3 strong direction in favor
  

• Colomar, Rename s/strpbrk/strchrs/ [N3670] (0.5 hours)
  

  Celeste: I am OK with this. We can just have the entry for one function say "this function also has an alternative name".
  Ballman: I am not excited about this, I think it will create more confusion in practice. It opens up questions I do not want to deal with.
  Opinion Poll: Would WG14 like to see something along the lines of N3670 into C2y? 4-15-4 clear direction not to proceed
  

• Colomar, Refactor syntax of preprocessing directives [N3751] (0.5 hours)
  

  Ballman: If we go down this route, I'd want to do the same on the C++ side.
  Colomar: I have presented something in the Github of C++.
  Banham: Is this proposal just tidying up the wording and makes no changes?
  Colomar: The wording is not changed, just re-organized.
  Decision Poll: Would WG14 like to adopt N3751 into C2y? 11-1-11 strong consensus to adopt
  Ballman: I voted "no" because it is all risk and no reward.
  Colomar: It is about writing new proposals on top.
  Seacord: We should notify WG21 that this has been adopted, and they may wish to adopt it as well.
  

• Myers, C23 issue log, r3 [N3773] (1 hour)
  
  • Issue 1000: Structure type compatibility with flexible array members: Review
    

    Are there any objections to the proposal correction to Issue 1000? None
    

  • Issue 1001: Qualified rvalues from structure or union members: Open
    

    There are two suggestions.
    Celeste: I prefer the option where we preserve the type completely with qualifiers. That is option 1.
    Colomar: Myers, which option do you prefer and why?
    Myers: I am inclined to option 2, not to have any qualified items at all.
    Decision Poll: Do we prefer option 1 over option 2 for Issue 1001 in N3773? 2-7-9 strong preference for option 2
    Decision Poll: Do we want to move the correction in option 2 for Issue 1001 in N3773 to review state? 13-0-4 strong consensus to move to review state
    

  • Issue 1002: Type qualifiers in [*] in abstract declarators: Review
    

    Gustedt: The next meeting we discuss this is the March or August meeting?
    Myers: We do not have issues on the March meeting agenda, so the answer is "August".
    Are there any objections to the proposal correction to Issue 1002? None
    

  • Issue 1003: Linkage between library functions: Review
    

    Are there any objections to the proposal correction to Issue 1003? None
    

  • Issue 1004: Classification of scanf failures: Open
    

    Jones: This changes the scanf() functions to match the printf() functions. So this seems like a good change.
    Are there any objections to moving the correction for Issue 1004 in N3773 to review state? None
    

  • Issue 1005: Annex D refers to option removed from UAX#31 in revision 39: Review
    

    Are there any objections to the proposal correction to Issue 1005? None
    

  • Issue 1006: atomic_fetch operations and "address types": Open
    

    Myers: I think 1006 has been obsolesced by the atomic suggestions we adopted. We can close this issue.
    Banham: Do we need a corrigenda for C23?
    Myers: That is unnecessary. Fixes to C2y will apply to C23 as well.
    Gustedt: We should mention the paper that closed the issue.
    Are there any objections to closing Issue 1006 with the comment that this was resolved by N3788? None
    

  • Issue 1007: Implicitly unsigned bit-fields ambiguity: Open
    

    Myers: Our conclusion was that signedness for bit-fields is the same as signedness outside of bit fields.
    Seacord: Maybe we should have a paper on this for C2y. I will write one.
    Action Item: Seacord: Write a paper addressing Issue 1007 in N3773.
    

  • Issue 1008: Bad constraint on attributes with tags: Review
    

    Are there any objections to the proposal correction to Issue 1008? None
    

  • Issue 1009: extern thread_local should not be an external definition: Review
    

    Are there any objections to the proposal correction to Issue 1009? None
    

  • Issue 1010: Termination of the execution with threads: Open
    

    Gustedt: We should leave this open and move on.
    

  • Issue 1012: Error returns from specific width length modifiers: Open
    

    Colomar was going to write a paper to address this issue.
    Action Item: Colomar: Write a paper addressing Issue 1012 in N3773.
    

Friday, 6 February

• Myers, C23 issue log, r3 [N3773] (1 hour), cont.
  
  • Issue 1011: powr(negative, qNaN): Review
    

    Are there any objections to the proposal correction to Issue 1011? None
    

  • Issue 1013: Ambiguity of "same type": Open
    

    Bachmann: Something related: ternary operator is type-combining. If one type is reproducible but the other is not, that could lead to an error b/c reproducible transfers to a pointer not prepared for it.
    Uecker: I propose to split these questions up, and defer deciding on this until we have seen those papers. Attributes should be part of the type.
    Ballman: I agree. Let us split the attribute out into its own topic. I originally intended that type attributes should be part of the type. This would go towards fixing it, but it is contentious in the committee.
    Colomar: Please do not vote this. Attributes are more dangerous than they seem.
    Bazley: I am wary of saying attributes are part of the "same type".
    Gustedt: We should distinguish between "attributes are part of the type" and "we want attributes to be part of the type".
    Ballman: Attributes are not broken by design.
    Bazley: I agree. But they are used in different, confusing ways by different people.
    Svoboda: Attributes are complex, rejected by WG14 in 2010, then accepted by WG14 in 2020, added to C++. I would like to see a paper outlining the design of attributes.
    Ballman: See my original paper on attributes.
    Bazley: The mailing list discussion suggests that reproducible attribute is not ignorable.
    

  • Issue 1015: Imprecise wording for cnd_t functions
    

    This was fixed in C2Y
    

  • Issue 1016: Are digit separators allowed in LINE?: Review
    

    Colomar: I think this language is not good.
    Decision Poll: Do we want to adopt the correction to issue 1016 in N3773 into C2y? 18-3-0 strong consensus to adopt
    

  • Issue 1017: Unspecified timing and synchronization for cnd_t functions: Open
    

    Myers: We can skip 1017 because we have N3764.
    

  • Issue 1019: String functions and trailing null inclusion: Open
    

    Gustedt: This is a lot of changes for an issue list. I would prefer to see this as a separate paper.
    Seacord: These are two variations of the same phrase, applied to many locations.
    Bhakta: I agree with Gustedt. This could break implementations, so it should be a paper.
    Colomar: I am good with the changes.
    

  • Issue 1020: Definition of address constant: Open
    

    Myers: Is this sufficiently clear that the integer constant added…
    Are there any objections to moving the correction for Issue 1020 in N3773 to review state? None
    

  • Issue 1021: Integer promotions for enumerations: Open
    

    Gustedt: We should add something like this to the usual arithmetic conversions.
    Uecker: We should make the enum work as if it were the underlying type. I wonder what C++ does?
    Banham: Related problem: What does it mean for an enum type to hold an underlying integer value that is not one of the enum members?
    Myers: In C, all values in underlying type can be the enum. In C++ only the declared values are valid.
    Gustedt: LLVM has different possibilities for attributing enum types with what kind of integer it can have.
    Celeste: You asked about a user perspective. It is a common idiom in C++.
    Opinion Poll: Does the committee think the conversions to an enum's underlying type should occur in all cases discussed in Issue 1021 from N3773? 15-0-5 strong direction
    

• Myers, Floating-point TS 18661 (C23 version, 2025) issue log, r2 [N3719] (0.5 hours)
  
  • Issue 1014: Error handling in <reduc.h> and <augarith.h>
    

    Seacord: I recommend we close this.
    Meneide: There are several nuances to closing this for us to address.
    Seacord: I recommend we integrate this into C2y with this proposed correction.
    Bhakta: I recommend that we close this as "accepted".
    Any objections to adopting the correction to issue 1014 from N3719 into TS 18661-4? None
    

• Bazley, Enhanced type variance (v2) [N3674] (0.5 hours)
  

  Colomar: Libc implementers are interested in this paper.
  Myers: The conditional expression is not entirely ready because it does not specify how you indicate a composite type.
  Banham: Can you please clarify the situation for "volatile"?
  Bazley: Suppose a function has a parameter that is a volatile int*. This promises callers that it will always reread the value of the referenced object. You could use that for a function that does not extend the promise.
  Gustedt: I like this formulation. This should go into C2y.
  Jones: I think the phrasing means that the code works.
  Krause: Something should be done in this direction, but I am against the paper as it is now. It breaks most qualifiers. It might work for const and volatile, but I am not sure about restrict. However, there are other implementation-specific qualifiers that would break. Instead of saying "do this for all qualifiers", you should list the qualifiers for which this may be done. So this is a problem for platforms with other qualifiers. Perhaps cross-check with my name address space paper (N3723).
  Bazley: I never intended to cause worry for other implementers. Maybe a new term like "access qualifiers" would suffice?
  Colomar: You should split comparable types and substitutable types into different clauses. I would like to split the paper among these different types.
  Uecker: Do you also intend this for qualifiers for struct members?
  Bazley: I have thought about it. I decided it might be a can of worms.
  Svoboda: I second Krause's concern. CERT rule EXP32-C forbids using a non-volatile ref to access volatile, because accessing a volatile byte via a non-volatile reference is UB. This would make that UB more likely.
  Bazley: That is not how type variance works. You can make any access volatile, but you are not allowed to access a volatile object without volatile.
  Adams: Do you have any implementation? Also, what is the feeling among developers?
  Bazley: Yes, and I am trying to persuade my bosses to release it, but no luck so far.
  Colomar: Half of this paper is already in C++. While we do not have experience with functions, we have it with pointers.
  Bhakta: Bazley, thank you for this approach.
  Opinion Poll: Would WG14 like to adopt something along the lines of N3674 into C2y? 19-0-8 strong direction
  

• Meneide, printf string size specifiers (and general precision length modifiers), r3 [N3691] (0.5 hours)
  

  Jones: I do not think this is useful for developers. For this to matter, the user needs to be printing a string, but the string's maximum size is unknown, and might be larger than INT_MAX. Also the string cannot be at the end, you could use precision to limit the string. For every other case, if the user is using printf() and strlen() for precision, it does not help them. From an implementer perspective, having length modifiers in two positions makes parsing harder. Finally, length modifiers are heavy, because there are smaller types, short, size_t, significantly more complicated than precision. I would prefer this to just focus on size_t. It would also be nice if SIZE_MAX meant "undefined".
  Colomar: Most of the string library is "mem" or "str" functions. We have strncpy() and strncat(), which are monsters. Those were meant to handle utmp buffers where you store chars and pad with null bytes at the end. This is another "monster", similar to strncat(). We clearly said that we do not want new string API's. This is also over-engineered, because no one will use short as a length modifier. It is sneakily introducing a new string operation.
  Bhakta: At the wording changes, it would be good to have some examples.
  Gustedt: I disagree with Jones. Yes, I could cast string lengths to int, but this is really annoying. I do not want to have casts in my code just to do printf(). size_t is really needed.
  Bazley: Syntax is not the most important thing about this. I agree more with Gustedt than Jones. The temptation to use a function that returns something other than int is very strong. I prefer an orthogonal solution over one that is minimalist. Overall I support this.
  Jones: From a user perspective, this does not make life much easier. I usually get reminded by compiler warnings to add length modifiers.
  Meneide: One of the primary motivations for this paper is high-quality implementations, I will get a negative return value from printf(). Right now, if you cast to int, the implementation does not know that you silently truncated your string. I wanted feedback if the string being printed is too large.
  Colomar: Why can you not use strncpy()?
  Meneide: I do not think the functionality of printf() is just for printing out a simple string.
  Ballman: Question: Are Jones' concerns specific to the LLVM libc? Do other implementers have experience or concerns? I do like the idea of having less casts.
  Meneide: I have not asked them.
  Bazley: We have a bug in C: the language is simple, but the library does not have to be simple. The only mechanism we have for secure programming is good interfaces. Making the interface safer is a worthwhile investment.
  Opinion Poll: Would WG14 like to adopt something along the lines of N3691 into C2y? 8-8-9 no direction
  

Break

• Colomar, Add strsep(), wcssep() [N3667] (0.5 hours)
  

  Krause: It was 29 years ago (London 1997) when we voted against this idea. Does anyone remember why? This is more complicated than adding an offset to a pointer.
  Jones: I am OK with this from an implementer's perspective.
  Celeste: You do not need to request a poll if you do not want this.
  Bachmann: More string functions are not helpful.
  Opinion Poll: Would WG14 like to adopt something along the lines of N3667 into C2y? 5-5-14 no direction
  Colomar: I will not bring this paper again. I do not care much about this paper, the function is already in every system I care about.
  

If time (be prepared to discuss)

• Krause, Named Address Space Type Qualifiers for C2y v2 [N3723] (0.5 hours)
  
• Meneide, \Any\func\* - A Universal Function Pointer Storage Type, r2 [N3692] (1 hours)
  

Not yet scheduled:

• 2. Colomar, Subdivide string API sections [N3671] (0.5 hours)
  
• 3. Grüninger, Add min, max for integers to C [N3160]
  
• 4. Johnson, Namespaces Without Name Mangling [N3491] (0.5 hours)
  
• 5. Johnson, Generic Data Structures Without Name Mangling [N3520] (0.5 hours)
  
• 6. Colomar, add strchrcnt(), strchrscnt(), wcschrcnt(), wcschrscnt() [N3664] (0.5 hours)
  
• 7. Meneide, Transparent Aliases, r6 [N3689] (0.5 hours)
  
• 8. Meneide, Thread Attributes, r2 [N3690] (0.5 hours)
  
• 9. Meneide, Integer Constant Expression-Initialized const Integer Declarations are Implicitly constexpr, r3/ [N3693] (0.5 hours)
  
• 10. Meneide, embed Synchronization, r2/ [N3696] (0.5 hours)
  
• 11. Uecker, Wording Improvement: Generation of Non-Value Representations/ [N3700] (0.5 hours)
  
• 12. Uecker, Ghost: Lvalues that do not designate an object/ [N3701] (0.5 hours)
  
• 13. Thomas, C2y proposal - Standard pragmas and headers/ [N3702] (0.5 hours)
  
• 14. Thomas, C2y proposal - Preferred quantum exponent/ [N3703] (0.5 hours)
  
• 15. Thomas, C2y proposal - Clean up frexp, ldexp, and scalbn prototypes/ [N3704] (0.5 hours)
  
• 16. Krause, bit-precise enum/ [N3705] (0.5 hours)
  
• 17. Gustedt, Add type-safe minimum and maximum type-generic macros v3/ [N3762] (0.5 hours)
  
• 18. Svoboda, Earthly Demon Slaying Technique and UB 6: Extended Punctuation Characters/ [N3710] (0.5 hours)
  
• 19. Uecker, Clarifying Undefined Behavior for the Indirection Operator/ [N3711] (0.5 hours)
  
• 20. Uecker, Earthly Demon: Conversion of Pointers to Integers of Insufficient Size/ [N3712] (0.5 hours)
  
• 21. Uecker, Type Compatibility: Ghosts, Readability, and A Missing Rule for Atomic/ [N3713] (0.5 hours)
  
• 22. Svoboda, Busting Another Ghost: UB#11: Value of auto Object/ [N3714] (0.5 hours)
  
• 23. Múgica, Array notation for vectorization, v. 2/ [N3717] (0.5 hours)
  
• 24. Múgica, What are the operands of Generic, v. 2/ [N3721] (0.5 hours)
  
• 25. Múgica, Generic replacement, v. 2/ [N3722] (0.5 hours)
  
• 26. Múgica, Discarded, V/ [N3724] (0.5 hours)
  
• 27. Karl, Designate the address of a struct/union's first member as the address of the struct/union/ [N3728] (0.5 hours)
  
• 28. Thomas, Proposal for C2y - Range bounds for math functions/ [N3731] (0.5 hours)
  
• 29. Bhakta, Floating expressions evaluated in translation/ [N3732] (0.5 hours)
  
• 30. Meneide, Improved \\attribute\\/((cleanup(…))) Through defer, r4 [N3733] (0.5 hours)
  
• 31. Meneide, defer Technical Specification (Committee Draft), r4 [N3734] (0.5 hours)
  
• 32. Thomas, Proposal for C2y - Refine the language of error reporting [N3737] (0.5 hours)
  
• 33. Thomas, Proposal for C2y - Preferred quantum exponent for nextafterN [N3738] (0.5 hours)
  
• 34. Gustedt, C semantics for contracts [N3739] (0.5 hours)
  
• 35. Uecker, Dependent Structure Types [N3745] (0.5 hours)
  
• 36. Colomar, Add operators \_Minof and \_Maxof [N3748] (0.5 hours)
  
• 37. Colomar, Adopt qualifier conversion rules from C++ [N3749] (0.5 hours)
  
• 38. Colomar, add a malloc(3)-based sprintf(3) variant [N3750] (0.5 hours)
  
• 39. Colomar, The Elvis operator ?: [N3753] (0.5 hours)
  
• 40. Colomar, Ignite annex I [N3756] (0.5 hours)
  
• 41. Colomar, Liquidate Annex L [N3757] (0.5 hours)
  
• 42. Colomar, C source files are text files [N3633] (0.5 hours)
  
• 43. Colomar, Add operator \_Typeas [N3634] (0.5 hours)
  
• 44. Colomar, add \_Assert(), not depending on NDEBUG [N3760] (0.5 hours)
  
• 45. Gustedt, Add type-safe minimum and maximum type-generic macros v3 [N3762] (0.5 hours)
  
• 46. Gustedt, Properly specify the interaction of library calls for mutexes v3 [N3763] (0.5 hours)
  
• 47. Gustedt, Properly specify the interaction of library calls for condition variables v3 [N3764] (0.5 hours)
  
• 48. Douglas, Thread-safe signals handling [N3765] (0.5 hours)
  
• 49. Douglas, C Lingua Franca Results [N3766] (0.5 hours)
  
• 50. Celeste, Allow arrays of incomplete element type [N3777]
  

Removed (by request of author):

• Colomar, add st*rspn(), st*rcspn(), wc*rspn(), wc*rcspn() [N3665] (0.5 hours)
  
• Ornato, Declaration-level static assertions [N3641]
  

8.1 Review of Decisions Reached

8.2 Review of Action Items

8.4 Reapprove Brno Minutes

8.3 Reapprove Current Meeting Agenda