Dates and Times

Meeting Location

Meeting information

Meeting Scribe: David Svoboda

Local contact information: Alex Celeste

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 2026 (spring) [N3856]
  

  Moved by Celeste. Seconded by Ballman. Any objections? None
  

• Online Poll:
  

  Gustedt, Add type-safe minimum and maximum type-generic macros, v4 [N3868]
  Straw poll closed: May 29, 2026: 10-3-2 Consensus
  Action Item: Editor to integrate N3868 poll results with C2Y working draft
  

1.6 Review of Action Items

1.7 Approval of Agenda [N3938]

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 and C++ Compatibility Study Group activity report (Schultke, Doumler)

3.3 Undefined Behavior Study Group activity report (Svoboda)

3.4 defer (Meneide)

3.5 Memory Safety (Uecker)

3.6 Nullability Type Qualifier (Bazley)

3.7 New Study Group proposal (if applicable)

4.1 Future Meeting Schedule

4.2 Future Mailing Deadlines

Monday, 17 August

• Uecker, Slaying an Aqueous Demon: Writable String Literals [N3860] (0.25 hours)
  

  Celeste: This exists in MISRA's shadow type system. We know if a type came from a string literal.
  Bhakta: That is an argument for not having this go through. It is easy to implement in compilers.
  Ballman: -Wwritable-strings changes the type in GCC, which is a terrifying precedent. We are late in the C2y cycle, and this will cause problems. I prefer to wait until after C2y.
  Myers: There is one case in the standard that this would break.
  Gustedt: There are valid use cases of having string literals not being const-qualified. I am in favor of this. If not now, then when?
  Serebrennikov: If we want to get rid of this, it does not make sense to deprecate it in the standard.
  Bhakta: It is relying on the extension point.
  Bazley: I support this, but I fear this breaks more things than we realize
  Straw Poll: Do we want to adopt something along the lines of N3860 into C2y? 3-0-2+13-2-6=16-2-8 direction for
  

Morning break

• Uecker, Compatibility of Structures and Unions Without Tag [N3744] (0.5 hours)
  

  Celeste: This seems similar to a C++ requirement.
  Myers: This also undoes various fixes we made in 2022.
  Bhakta: Is this a drawback to the record proposal?
  Uecker: That does not make the language more consistent
  Bazley: I prefer Uecker's solution (sorry, Meneide). Have you thought about the converse?
  Uecker: People can use #define instead of typedefs.
  Ballman: This code is already a constraint; you already get a diagnostic. Is there any implementation experience where the diagnostic gets demoted to a warning?
  Uecker: It was part of my original technical implementation.
  Ballman: I am worried about deployment experience building on top of that.
  Almkainzi: What happens if the mangled name matches a keyword?
  Uecker: A future version would change that.
  Serebrennikov: I have seen bug reports for this problem.
  Celeste: I have a strong preference for not standardizing name-mangling schemes. We should follow C++'s precedence, leaving it implementation-defined.
  

• Celeste, Strong typedefs, v2 [N3587]
  

  Bhakta: I request more examples in a future paper. That would help resolve attribute vs keyword.
  Banham: PC-Lint has been doing this for several decades now. You need hierarchical definitions of the types to support dimensions.
  Celeste: That is up to the committee regarding how much we want dimensions.
  Myers: We should make different types that are not compatible.
  Bazley: I like this but I never liked attribute syntax. It does almost exactly the opposite of my use cases. The main advantage is if it allowed one to constrain the values that can be assigned to such a type. I want something like an enum that turns back into a value. I do not want to turn a number into a reference or bitmap that may not exist. You can do this in a type-safe way, that is, unbox a value without casts. This should have nothing to do with attributes.
  Celeste: If we introduced a keyword, I would like some sort of direction flag. I sense that we want a keyword.
  Ballman: WG21 has tried to add this several times. They all failed, because they cannot achieve consensus on how strong "strong" should actually be. I am hearing traces of that in this conversation. We should be careful about focusing on units libraries; this is useful outside of units as well.
  Liber: This needs to be its own type, not just an attribute.
  Seacord: I am concerned with different settings for type strength.
  Celeste: That was just declarations, not the language setting.
  Ballman: Since this is likely to show up in shared header files, we should see what conversations WG21 had.
  Straw Poll: Would WG14 like to see a rewrite of N3587 that uses a keyword that introduces new types, rather than an attribute? 1-0-2+9-6-5=10-6-7 not strong direction
  Ballman: I voted no because I think Celeste will get overloaded with work, particularly for C2y.
  

• Uecker, Slay Some Earthly Demon: Storage-Class Specifiers with Compound Literals [N3871] (0.25 hours)
  

  Decision Poll: Would WG14 like to accept N3871 as is into C2y? 3-0-0+11-0-5=14-0-5 strong consensus to adopt
  

• Uecker, Wording for "Ghost: Lvalues that do not designate an object" [N3882] (0.5 hours)
  

  Ballman: I see section 6.9.2p9 with definitions of lvalues. Do we need more changes because of that? Maybe we should vote this paper in and welcome a paper that updates section 6.9.2p9?
  Action Item: Uecker: Write a paper that updates subclause 6.9.2p9 in accordance with N3882.
  Decision Poll: Would WG14 like to accept N3882 as is into C2y? 2-0-0+15-0-2=17-0-2 strong consensus to adopt
  

• Steenberg, Add N3607 To the list of papers that should be applied to previous standards [N3778] (0.25 hours)
  

  Ballman: C++ did not adopt this as a defect report. This would make a confusing situation worse rather than better. We encourage implementations to follow this, but we impose no constraints.
  Gustedt: I doubt anyone would implement "consume" for C11.
  Seacord: Are C11 & C17 ever different implementations on some platform?
  Ballman: The macro versions are different.
  Celeste: Does the same apply to the 4 versions (corrigenda) of C99?
  Seacord: No one uses C99 without all the corrigenda.
  Decision Poll: Would WG14 like to add N3607 to the list of papers that should be applied to previous standards? 4-0-0+12-2-3=16-2-3 consensus to update the list
  

• Gustedt, Wording for "Type Compatibility: Ghosts, Readability, and A Missing Rule for Atomic" [N3881] (0.5 hours)
  

  Ballman: The pointer stuff mentions "non-atomic". I expect two pointer types are compatible if they point to compatible types. I wasn't expecting to see us call out unqualified atomic pointer types.
  Myers: To avoid verbosity we need an algebraic notation so we can talk about compatibility of pointer types.
  Decision Poll: Would WG14 like to add N3881 as is into C2y? 1-0-1+15-0-1=16-0-2 strong consensus to adopt
  

• Múgica, Array constant expressions [N3787] (0.5 hours)
  

  Ballman: Clang does not support storage class specifiers on compound literals. What implementation experience do we have?
  Gustedt: This is a chicken-and-egg problem.
  Celeste: I implemented it but no one is using my implementation.
  Ballman: I ask because Clang's approach to compound literals in C is weird.
  Bhakta: I am concerned about the lack of implementation experience.
  Decision Poll: Would WG14 like to add N3787 as is into C2y? 2-0-1+8-2-6=10-2-7 strong consensus to adopt
  Bhakta: I abstained because of lack of implementation experience.
  

Lunch Break

• Meneide, Expression Evaluation and Access in _Generic, r2 [N3915] (0.5 hours)
  

  Bazley: I like this, but have some misgivings. It might be good to take design ideas from other committee members. I am concerned that programmers must invent an identifier for each generic association. I also want to have this compose with other language features.
  Myers: There are various counter-intuitive effects regarding lvalues.
  Bazley: Making the scope more explicit would be good. I wonder if we could have more choices of possible syntax?
  Meneide: We put two syntax forms in the paper.
  Ballman: Are you planning on talking to implementors so we can get this into the standard?
  Meneide: We are happy to push this out.
  Bazley: How serious is the scope? One answer is: do not require an identifier to be declared at all. Do we even have to use _Generic or would it be better to have something with an extra parameter?
  Meneide: The suggestion with braces: It was awkward to have a scope that begins with a type name and ends with a comma; that is not how scope works in C.
  Banham: I am finding this use of colon (inside _Generic) to be obscure from a C point of view.. Can we find a different syntax?
  Meneide: Yes!
  Gustedt: Scope is related to block, and block is not necessarily done with curly braces.
  Straw Poll: Does WG14 like the brace-less _Generic declaration name as specified in N3915, option 2? 0-0-2+7-2-6=7-2-8 strong direction
  Straw Poll: Do we want to preserve lvalue and rvalue-ness for the identifier of the generic association as specified in N3915? 0-3-2+2-2-8=2-5-10
  Straw Poll: Would WG14 like to add something along the lines of N3915 into C2y? 2-0-3+6-2-6=8-2-9
  

• Meneide, embed Synchronization, r4 [N3912] (0.5 hours)
  

  Seacord: I find these papers boring. We already want something along the lines of this, but we do not have finalized text. Do we want to send this to the Wording Group to finalize the wording?
  Ballman: I support trying to do this, but I am frustrated. We should not diverge the wording of the preprocessor, but this is r4, with a lot of divergence already. I do not know how to vote on this.
  Seacord: Don't WG14 & WG21 have different conventions for wording?
  Meneide: We did bring this to the Compatibility SG twice. They recommended to make the wording the same, and I did that to the best of my ability.
  Ballman: In WG21 the core wording group gives mandates not suggestions. In WG14, we give suggestions, not mandates.
  Gustedt: This paper is too complex to vote in. We should wait until it cools down in WG21, and then translate WG21's results for WG14.
  Seacord: Which committee proposed this first?
  Meneide: WG21 has finished with this. So I could just work with their result.
  Gustedt: There will be no NB comments then?
  Meneide: No, not for C++.
  Seacord: WG21's text is done and we know what it looks like. We can make spelling changes, so we should be able to finish this process.
  Bachmann: Could we say the same things for C as C++?
  Serebrennikov: I remember, the embed parameter; you can say __offset, it will be stripped away as 'offset'.
  Seacord: If C++ defines this as UB, then clang can define this for C, right?
  Ballman: Right!
  Serebrennikov: If this committee is going to adopt a translated C++ wording, we need a different paper.
  Meneide: I would like to poll over sending this to the Wording Group.
  Seacord: You do not need a poll, you can just send it.
  

Afternoon break

• Liber, Removing strncpy [N3935]
  

  Krause: This is not gets(). A rather niche use case, because strncpy() is safe if used correctly.
  Liber: If you control the input, then gets() can also be used safely.
  Gustedt: I am against removing it. This is a valid function with a wrong name. Linux removed the interface but not the function body. I would be in favor of deprecating it, perhaps taking the Linux kernel's function name.
  Myers: I am dubious of removing this. Adding an alternative name would be reasonable. This paper says nothing about wcsncpy(), which has the same issues.
  Liber: I agree.
  Bazley: I do use strncpy(). There are very few unsafe functions. It is strange that this paper wants to remove strncpy() but not strcpy().
  Bhakta: I also have use cases for strncpy(). I do not see an issue with deprecation.
  Celeste: We are underselling the strength of deprecation. Many groups treat deprecation as removal.
  Jones: The Google code base has 30,000 instances of strncpy(). So we cannot remove it.
  Svoboda: wcsncpy() should also be removed or deprecated, but this can be done separately. gets() was deprecated and removed two years later.
  De Abreu: Section 3.5 of the paper lists Linux alternatives. There is also strlcpy().
  Straw Poll: Would WG14 like to deprecate strncpy() and wcsncpy() and add these functions under new names in C2y? 5-1-0+4-5-5=9-6-5
  Straw Poll: Would WG14 like to deprecate strncpy() and wcsncpy() and add these functions under new names, and add a new function with a better API to C2y? 4-0-1+6-7-3=10-7-4
  

• Douglas, Thread safe signals handling rev 4 [N3924] (0.5 hours)
  

  Jones: My main concern is that this standardizes Windows signals with the POSIX API. It feels like we are trying to slide something under the POSIX API and will probably cause compatibility issues.
  Douglas: We ran this by POSIX several years ago and their reception was warm. This implementation installs a signal handler.
  Myers: A lot of wording problems are more conceptual. This does not tie down exactly what the state is with signal handling. How would it interact with other concepts such as POSIX signal masks, whether signals are caught, can they be queued up, etc? Given these complexities, I think it is premature to add this to C2y.
  Douglas: The design has not changed at all. What has changed is 3 design changes. One is atomic_signal_fence from the Wording Group.
  Bhakta: This is for all implementations, but I just heard Windows and Linux mentioned.
  Douglas: I comprise a plan for implementation on IBM ZenOS. I have a port running on the SP32.
  Cranmer: I am worried about how does this new signal-handling interface work with the old one?
  Douglas: For more implementation experience, I would do more hardening. I haven't implemented safety, I have been going for correctness first.
  Jones: Until you call siginstall(), everything acts like the old API. This seems like a dangerous foot-gun.
  Bazley: You say this is mature and deployed. Given that, is it worthwhile to discuss design issues? Some bits seem over-engineered, such as returning an enum of error values.
  Banham: Does any of this address which thread gets to handle the signal?
  Douglas: We have a synchronous set of signals. If you install a thread-local signal handler, and a synchronous signal gets raised, it is handled by the particular thread. We do not have anything like POSIX signal masks.
  Bhakta: How much is your deployed implementation being used?
  Douglas: That is hard to answer with any accuracy. There is a longstanding reference implementation for file I/O for C++. That has been shipping for years, and is very popular. The C++ signal-handling had suffered some bit rot; a newer version of glibc will not work with it. I only know when people use it when I get bug reports, and I do get bug reports for other software.
  Jones: You talked to professional libc developers about getting experience. I would definitely be interested in a llvm-libc implementation. I suspect it might break things at Google, but only time will tell.
  

• Douglas, Update POSIX to 2024 [N3936] (0.25 hours)
  

  Bhakta: Are there any changes from 1993 to 2026 in POSIX that are not forwards-compatible?
  Douglas: You could write a book about that question. Some years ago POSIX decided to defer many things to the C standard. Yes, POSIX has deprecated and removed some functions.
  Decision Poll: Would WG14 like to adopt N3936 as is into C2y? 5-0-1+14-0-1=19-0-2 strong consensus, adopted.
  

• Gustedt, Program termination in the presence of multiple threads [N3917]
  

  Douglas: The proposed wording has some problems, but the fundamental thrust is necessary. For example abort() does not need to be thread-safe. What happens with thread-local storage outside of main()? How do you write useful portable code when you do not know these things?
  Krause: This paper leaves out volatile sig_atomic_t.
  Banham: You have to be careful with signals that default to termination.
  Gustedt: We are saying that threads continue for an unknown time. The important thing is that they are stopped before control is handed to the system.
  Straw Poll: Would WG14 like to adopt something along the lines of N3917 into C2y? 4-0-0+14-0-2=18-0-2 strong direction
  

Tuesday, 18 August

• Gustedt, Gustedt, C semantics for contracts v. 4 [N3929] (0.5 hours)
  

  Krause: How does this work in C++? INF is not actually a keyword.
  Gustedt: INF is not in C++; they only have pre and post. They have context-sensitive things here. The preprocessor behaves differently.
  Seacord: This termination is implementation-defined. Is there no user override?
  Gustedt: I took out the whole thing that deals with that. Termination is described by this macro, like if you want assert(), but it is not conditional.
  Bhakta: I like this. I prefer a TS if we move forward. For std::terminate(), can it be made into not requiring a diagnostic for freestanding environments?
  Gustedt: I did not think about freestanding. This is a good idea.
  Ballman: Part of why C++ contracts have ignore semantics is for these kinds of situations. You need to know that things will not suddenly terminate underneath you. If the goal is to guarantee no undefined behavior, there are too many things you can't write contracts for.
  Gustedt: I can test everything that can be expressed with some evaluation formula.
  Ballman: You are not allowing attributes on the return path.
  Gustedt: The syntax does not allow that. C++ lets you specify the name of the return value and attributes.
  Ballman: So the people who need that in shared header files have no way to express it.
  Grant: They would use runtime C++ contracts. It has to be validated at runtime, and may call that handler which terminates. There is a risk of unexpected program behaviors. Whole logic is suited to compile-time validation, rather than runtime. Have you looked into that?
  Gustedt: Anything that can be checked at compile time should be. With a good optimizer, many of these pre- and post-conditions are canceled out by optimization. You can also track how good your optimizer is.
  Banham: The choice to support existing compiler features is what has limited the expression syntax.
  Myers: Is it valid to call function with contracts in signal handlers? If this goes in, we need implementation coordination about what the ABI's should be. This is simpler than the ABI issues with things like _Atomic.
  Gustedt: It is easy to have function calls as before. A simple ABI would be a naming convention. Parts of this can be left to the implementation.
  Columnar: This is not necessary, as we can write contracts in a macro that wraps a function. That is useful unless you use function pointers. I would specify that side effects should be a constraint violation rather than undefined behavior.
  Gustedt: You can do tests either pre or post in a macro, but you lose the ability to say that a pre-condition holds in the function. Side effects should be a constraint where possible. Unsequenced or reproducible functions can be called in preconditions.
  Steenberg: This should only describe constraints and not what you do with it. If we start defining when this is useful, we run into complications. At runtime, this should be easier to implement, but I don't think you want it. I often would want to put it into code that is performance-critical.
  Gustedt: This is the minimum default behavior that I would expect.
  

• Grant, compile_assert – optimization-enforced conditions at compile time [N3846] (0.5 hours)
  

  Cranmer: This is trying to have the optimizer emit diagnostics, but it is not set up to do that. There is no correlation between the optimizer's rearranged code and source code.
  Columnar: This is a high-level feature based on a lower-level feature that drops the program. The compiler could diagnose that. We should aim for the smallest feature that can be used.
  Bhakta: You cannot count on results from the assert being checked or found.
  Bazley: There is something similar in the Linux kernel. I want to support this but I have misgivings. As a programmer, I do not want the mental overhead of different types of assertions. Do I understand that if the invariant cannot be proven, the contract fails?
  Grant: I would prefer it to fail but we could reduce it to a compiler warning.
  Bazley: That is problematic, because C has a plurality of compilers. If you want to check things, the best way to do it is via the type system.
  Krause: This could compile with one compiler but not the other.
  Celeste: The optimizer and flow-analysis engine are using the same tools, but are opposite in what they achieve. This is exactly what other tools issue warnings about.
  Uecker: I like this feature, despite it being compiler-dependent. It is something people are already doing; they use the optimizer to prove other things that used to require dedicated static analysis tools. This would be useful to prove complex safety properties; but it is too complex to put into the type system. It violates a layering but that can be done in a clean way, perhaps with a built-in.
  Ballman: Not all optimizers behave in a deterministic way. A SAT solver might be based on a platform's memory limits. It is worrying to take something for contract-like checking and tie it to something nondeterministic in practice. It is hard to pass info down to the optimizer in a way that doesn't cause other problems. We should have implementation experience for this sort of thing.
  Bazley: I was asked to implement a check in GCC last year about uninitialized data. I got feedback that the source code location wasn't precise enough, and I responded that that info does not exist in GCC. Some people think a diagnostic is sufficient without precise source code location information.
  Straw Poll: Would WG14 like to see something along the lines of N3846 into C2y? 0-0-4+3-8-8=3-8-12 strongly opposed
  

• Colomar, Refactor non-directives [N3934] (0.25 hours)
  

  Ballman: This adds a new term of art, so it diverges the preprocessor from C++. It is odd to say this is a directive of any form. I recommend sending this to the C/C++ Compatibility Study Group.
  Gustedt: I also recommend sending this to the Compatibility Study Group.
  Meneide: After the C++26 ballot is over, the C++ Compatibility Study Group would be happy to address this. They do not want a pull request, but they would be happy with the paper.
  Celeste: Can we have a poll to generate an action item to see this again once C++ approves it?
  Seacord: This is editorial so we never have to see it.
  Straw Poll: Would WG14 like to see something along the lines of N3934 into C2y? 1-0-1+13-0-8=14-0-9 very strong direction
  

• Colomar, Define macro-parameter-list (editorial) [N3908] (0.25 hours)
  

  Myers: The correction in this paper defines what it means for things to be identical.
  Celeste: This is not an objection, but if you read this sentence with implementer-brain, you will see the ellipsis as a parameter.
  Bhakta: I am concerned that we are adding a new grimmer term to indicate something we already get right.
  Ballman: Are we going to submit this to the Compatibility Study Group?
  Columnar: No.
  Decision Poll: Would WG14 like to adopt N3908 as is into C2y? 3-0-1+10-3-5=13-3-6 strong consensus to adopt.
  

Morning break

• Banham, Improve the allocator free functions to accept const qualified heap object pointers [N3894] (0.5 hours)
  

  Krause: These are functions that modify the memory of where these pointers point to. You could cast away const.
  Banham: There is a special circumstance, in that free() is not any ordinary function. Once you have passed a pointer to free(), the object lifetime ends.
  Gustedt: I strongly support this paper; anything that helps const contracts. But I have difficulty with realloc() (the last change).
  Bhakta: We have talked about breakage being minimal but it is an issue. There is a cost, but that does not mean we should not do it. The benefit seems minimal while the cost seems significant.
  Bazley: I think free() is one of the most common functions to have its address taken. It is not really acceptable to change the type of standard library functions.The problem with casts is that what you are casting may not even be a pointer.
  Myers: The issue of compatibility of function pointers is tricky. In this case, if you change a function pointer type to const, you break compatibility with older libraries that do not have the const. To be compatible with older C you would need wrappers. We should wait until we have Bazley's contra-variance. So I view no to all these versions until that paper is accepted.
  Banham: Where are we with that paper?
  Bazley: Most of my time has been on the Optional TS.
  Banham: You could change the prototype declaration for free() without changing the library.
  Ballman: I found 7,000 uses of the address of free() being stored. This also impacts C++, so it should also go to the Compatibility Study Group. Just changing one type definition will not solve problems…the problem does tend to snowball.
  Banham: free() is a leaf function.
  Ballman: You are changing the type definition of free(), and that will require some cascading changes.
  Seacord: Use-after-free is a security problem, and so we wanted to have a pointer-to-pointer, to nullify a pointer used to free an object. The committee wants a new version of realloc() to have the C99 semantics. We could design new versions of these functions.
  Cranmer: How would you express in a pointer that you do not have privileges to free?.
  Celeste: You would not. That was a motive to add qualifiers, it is tied to a program's semantics.
  Steenberg: It is easy to wrap free() to regain the old behavior if that is what you want. So the resulting breakage is easy to repair.
  Columnar: Microsoft has successfully tested the proposed realloc in their own OS, and there is no breakage.
  Bazley: free() is just one of many functions with similar semantics. Many programs have their own memory management system.
  Jones: This paper warns when you pass a const pointer to free(). It seems easier to have a compiler attribute; that seems like a simpler solution.
  Ballman: I do not think our memory allocation functions can be implemented using standard C even though that is our goal. That said, we can attach attributes to functions in Clang that are not defined with them.
  Decision Poll: Would WG14 like to adopt the change proposed by N3894 to the function type for free(), free_sized(), and free_aligned_sized() in to C2y? 0-0-5+5-13-2=5-13-7 fails
  Straw Poll: Would WG14 like to see a paper along the lines of N3894 that proposes an alternative free() function that accepts const qualified object pointers? 2-0-3+2-9-7=4-9-10 fails
  

• Almkainzi, Namespacing with prefixes r1 [N3848] (0.5 hours)
  

  Celeste: This is similar to something I wanted several years ago. This is for things that go into header files. The limits of C++'s namespaces are overstated. Name-mangling is relevant to namespaces.
  Almkainzi: C++'s approach is not easy to add to C. Their name-mangling is not specified by the standard.
  Bhakta: I like that this works without name-mangling, but do not like the idea of new keywords. That lengthens the learning curve.
  Jones: If C will add namespaces, it should be compatible with C++.
  Almkainzi: Would it be better to have different syntax from C++?
  Jones: That would be less concerning to me.
  Gustedt: I do not like this feature submitted to C++. There are many libraries that use prefixes and composing names. We could go into a direction like that.
  Ballman: We strongly prefer this to be compatible with C++. We have some precedence with ::. It is not quite a namespace. N3744 on tag type compatibility also introduces a form of name-mangling. We can dance around the name-mangling issue, and we should not standardize any kind of name-mangling. So I think we should bite the bullet on mangling.
  Bazley: I think name-mangling gets worse press than it deserves. I am more concerned about usability.
  Straw Poll: Would WG14 like to see something along the lines of N3848? 1-0-4+1-13-7=2-13-11
  Celeste: Everyone seems to want namespaces, but everyone wants something slightly different. Perhaps there should be a Namespace Study Group?
  

• Celeste, Strict order of expression evaluation, v2 [N3585] (0.5 hours)
  

  Columnar: I am concerned that a C lib function might want to reverse the order to that they can use array notation, use a macro call to reorder the parameters, and that would change the order of evaluation.
  Celeste: Yes, you can do that.
  Bhakta: I did not see prior art that has real experience in C compilers, so we need that. This does reduce the flexibility that compilers have.
  Celeste: My driving motivation is to herd everyone into a single direction, so it's not going to happen.
  Cranmer: You noted that the C++ committee walked back the decision to force ordering. Do you have any idea why?
  Celeste: I do not know.
  Jabot: We should specify that functions arguments should be either left-to-right or right-to-left.
  Celeste: That is still well-defined.
  Uecker: I would prefer left-to-right. In the library I would like to put it in future language directions.
  Ballman: Calling conventions is the problem, those are the platform's ABI.
  Meneide: I want this very badly. I have seen student code where the behavior changes due to function call argument order. Having to tell users not to rely on evaluation order is negative.
  Celeste: The machines at the time needed to push to the stack, hence they had to evaluate from left to right. But this is not necessary nowadays.
  Jones: I would want to check that this doe not break things or ruin performance. Is there a way to test for this?
  Celeste: I could coordinate on that.
  Ballman: WG14 does not own the platform ABI's. We cannot mandate it without having behavior change. Deployment experience will be extraordinarily important.
  Steenberg: I wonder about people depending on this. This is scary with regard to portability. We do not know how quickly compilers will implement this. There is a good argument to say it should not be done this way.
  Celeste: The two positions seem irreconcilable. I do want to see it fixed.
  Straw Poll: Would WG14 like to see something along the lines of N3585 but with suggested modifications, especially function argument evaluation order? 3-0-1+9-3-7=12-3-8 strong direction in favor
  Bazley: Macros can reorder arguments; that affected my vote.
  

Lunch Break

• Celeste, The `void`-which-binds, v3: typesafe parametric polymorphism, v2 [N3586] (0.5 hours)
  

  Bachmann: Since attributes are ignorable, they cannot manage constraints
  Celeste: The paper says "If the implementation does support the attribute then constraints apply."
  Banham: Do type hierarchies have a bearing on this? That would be easier than working with attributes. You could not do it with typedefs which are just aliases, but a better type system makes it possible.
  Celeste: Maybe.
  Myers: We have a clear place for implicit conversions. We have a place to define what is allowed. Are these things deduced within a single expression?
  Gustedt: I would like to keep it close to the attribute itself. We can convert back and forth to void*. Once people start using these attributes as defined here, they are playing a different game; they want more diagnostics.
  Bhakta: Can you give an example where "spooky action at a distance" is a problem?
  Myers: There is a very unclear basic question whether these things are deduced in a single expression or the global namespace.
  Ballman: Our intent with type attributes was that they would impact the type system, but we never went there. I think that if it impacts the type system, it should be a keyword rather than an attribute.
  Seacord: Could you do both?
  Celeste: I would just like direction from the committee.
  Ballman: Attributes should be design with all specifications in the attribute. If it needs things far away (in the standard) then it should not be an attribute.
  Colomar: I like making the functions type-safe. If this is only for qsort() and functions that cannot be changed, maybe this should be implementation-defined by compilers.
  Seacord: Could we send this to the Wording Group?
  Gustedt: That would not solve the attribute vs. typedef problem.
  Ballman: WG21 has conditionally-supported features; we could have something similar. This would get attribute-like behavior.
  Uecker: Are there implementations where void* are represented differently than other types of pointers?
  Douglas: NPRC24 that has a single instruction less for function pointer than data pointers.
  Ballman: There are still esoteric platforms, particularly GPUs.
  

• Veldmeijer, Switch on Strings: Pointer-to-Character as Controlling Expression [N3895] (0.5 hours)
  

  Coates: Clearly there could be undefined behavior on control statements, such as if the char* is not null-terminated. Java strings carry its length and has a hash value, whereas C strings store neither. The C charter tells us to pay attention to performance. The switch looks time-b ound, would labels have to be hashed at compile-time? Under the hood, you would need to call strcmp(). The compiler would have to emit the same hashing algorithm. This looks simple on the surface, but might it be going against the grain of minimal abstractions.
  Celeste: C's cousin language Zed did this back in 1979. This uses strings to represent integer keys. I am wary of defining this in any way that involves strcmp().
  Liber: C++ is trying to solve this using pattern-matching. Are there any Unicode issues? We know switch statements can be optimized; but that will not be guaranteed for strings.
  Ballman: I also share performance concerns. C2y added case range syntax.
  Bachmann: Until recently, we could not switch on longs or long longs, only on plain integers.
  Myers: I am dubious of expecting hashing functionality to be integrated into the compiler. I am also dubious of performance.
  Bazley: I do not want case-sensitive comparisons for strings. So I think this is not suitable for the core language. I do not hate switches, but they are not great because of the need to add break statements.
  Bhakta: Just treat the pointer as an integer.
  Veldmeijer: I would suggest prefix to implementation, I would not even do a hash. You want little under the hood, the prefix check is quite straightforward.
  Douglas: Switch is the wrong construct for this, as C++ avoids it. I often want to match the beginning of a string. I would recommend not mentioning "strings" but mention this in terms of byte sequences. That way you avoid Unicode and characters.
  Gustedt: We have multibyte string types: UTF8, 16, 32 and wide strings. If we add this, we would have to handle all of these.
  Straw Poll: Would WG14 like to see something along the lines of N3895? 2-0-3+2-15-3=4-15-5 a really step climb
  

• Ballman, Redefining implementation-defined [N3863] (0.25 hours)
  

  Uecker: Most uses of "implementation-defined" in the standard are the more precise form.
  Ballman: We have some places in which there are choices, but most places have no choice.
  Bhakta: I strongly agree. Other choices that a platform could chose are now sanctioned. That is a quality-of-implementation thing.
  Krause: I do not think this paper improves the wording, it makes it longer. The wording change does not make a difference.
  Ballman: The current definition for unspecified behavior says "two or more possibilities", but we often do not provide them.
  Myers: This paper will make implementation-defined behavior into a friendlier version of undefined behavior, where there is no possibility of reasoning, except for the documentation.
  Bazley: I support this; it acknowledges the real state of things.
  Seacord: I am split on this. I agree that we do not have to enumerate each possible choice. I do not like implementation-defined behavior being defined in terms of unspecified behavior.
  Svoboda: I was shocked to find the "two or more choices" usually does not exist in the standard. Ballman's definition is more intuitive. Logical vs. arithmetic right shift is an example where two or more possibilities is not provided, but could have been.
  Cranmer: Pointer-to-integer conversion, where we need pointer provenance for it to work at all is another example. There is no leeway for implementation-defined behavior.
  Gustedt: Non-erroneous data threw me. It is data that depends on the implementation.
  Ballman: I grabbed non-erroneous data from C++. The committee was asking if you can have implementation-defined behavior from an undefined construct. We do not define "erroneous data".
  Uecker: We add the sentence to the definition, but keep the "two or more choices".
  Myers: Choices might be bounded vs. unbounded, and documented vs. undocumented. That distinguishes undefined behavior, unspecified behavior and implementation-defined behavior.
  Colomar: How about adding a note to the entry saying "two or more possibilities"?
  Ballman: I like having an unbounded set for implementation-defined behavior. If we unbound unspecified behavior, that does not improve anything.
  Banham: It is about when is the choice made? But the choice could be dynamic, or made at compile time.
  Rice-Leech: The 3rd example is illustrative, it is bounded on names on types. The second case is unbounded on what it does. Implementation-defined behavior does not document what the choice is, but rather how the choice is made.
  Bazley: Is there a real problem to be addressed?
  Myers: We have labeled unspecified & implementation-defined without knowing what the choices are.
  Decision Poll: Would WG14 like to adopt N3863 as is into C2y? 2-1-3+13-5-4=15-6-7 no result
  Colomar: There is sustained opposition, I would not count this as consensus.
  Ballman: Since Krause and Myers are voting against it, let us not call it consensus.
  Action Item: Myers: Add a fourth term to supplement N3863.
  

Afternoon break

• Seacord, Removing the Implementation-Defined Signedness of Bit-Fields, v3 [N3902]
  

  Bhakta: I am glad the paper includes "int" being interpreted as "unsigned int". Having an implementation-defined choice between signed vs. unsigned would have documentation there. Forcing it to be signed would be a silent behavior change.
  Seacord: If we kept it implementation-defined, we would still have to figure out solutions for Issue 1007.
  Krause: I like unsigned types. All our target architecture are small enough that this is a performance issue. I have not gotten any complaints from users about switching it.
  Bazley: What hass changed since the last meeting?
  Seacord: The 3rd example resolved an issue raised by Gustedt.
  Decision Poll: Would WG14 like to adopt N3902 as is into C2y? 1-0-4+14-1-1=15-1-5 strong consensus to adopt
  Celeste: There are two different interpretations: 1. We are saying C always behaved that way in the past, but we were never clear about it. 2. A new implementation that supports C99 should comply, but we are not applying to legacy implementations.
  Ballman: The recommendation list was meant to imply that C should always have been interpreted in this way.
  Krause: This does not break old programs. The new behavior we mandate now is one of two implementation-defined choices from previous standards. Not doing this means we leave a defect in the old standards. Not fixing this leaves problems with typedef and typeof().
  Columnar: The charter says that code can be non-portable. This would break non-portable code.
  Decision Poll: Would WG14 like to recommend that N3902 should be applied to previous versions of the standard? 1-0-4+5-8-4=6-8-8 no consensus
  

• Coates, Slaying Some Earthly Demons - remove undefined behavior 28, 29 [N3904] (0.25 hours)
  

  Seacord: I wrote the paper that put this language into the standard, along with Jabot and Honerman from C++ Compatibility Study Group.
  Bhakta: The text you are changing does have some difference such as the dollar sign. Why was that added in here?
  Coates: To make it explicit.
  Bhakta: I would suggest an editorial change by adding a reference where that is allowed.
  Coates: OK, thank you.
  Gustedt: We just forgot about this undefined behavior.
  Jabot: I think this is fine. I do not think the note adds anything; it should be removed.
  Coates: I added the note late on, in response to someone else's comment.
  Myers: There is a 'may' (normative) in a note that should be changed to 'can'.
  Decision Poll: Would WG14 like to adopt N3904 without the two notes into C2y? 2-0-2+16-0-3=18-0-5 strong consensus to adopt
  

• Coates, Slaying Some Earthly Demons - remove undefined behavior 30 - Approach 2 [N3911] (0.25 hours)
  

  Ballman: I want to support this. The problem is that despite MSDN's documentation, the behavior is to truncate silently, even if you do not specify the limit, which is around 2047 characters. Clang does not control what linker gets used. And WG14 has no linker authors. Linkers are a type of project that can get completed and never changed afterwards.
  Bachmann: I am in favor. Since there is a small remaining issue: a line no longer than 4095 characters is possibly undefined behavior, this proposal takes place.
  Bhakta: Many places use separate complete linkers. But that does not mean we should ignore them, including link.exe from Microsoft.
  Jabot: For anything that tries to link C++ code, if you use some library like Boost, you can get identifier names that are thousands of characters long. Every linker we use is fine with that. C++ assumes there is no limit, I think it would be fine for C to do the same.
  Celeste: I am a fan of the wording changes; it increases teach-ability.
  Coates: There were linker implementations that changed between C90 and C99. It would be odd if we cannot ever improve this now.
  Krause: First, C++ has long identifiers because of mangling. There are C compilers and linkers targeting these platforms. It is annoying when linkers silently truncate. The implementation limit in the paper; it does not say how this maximum is counted. The counting rules do not work for implementations that use something besides UTF8.
  Coates: It should be easy to say the counting rules. The front-end count has to account for multiple encodings.
  Columnar: There are certainly new linkers and old linkers that are still maintained; we can talk to those people. We can say that older linkers are not C2y-compliant.
  Bhakta: For the OS360 example, we have a "pre-linker", the compiler does not support the linker.
  Bazley: This table lists Acorn object format, and there is no theoretical limit on identifier lengths. Around 1995, Acorn's compiler truncated identifiers to 256 characters. I do not think that is behavior we want to perpetuate. If you choose to use a linker that does not comply with C2y, that is your problem.
  Jabot: The standard does not distinguish between front-end and back-end in C or C++.
  Cranmer: Is anyone unhappy with what linkers are doing today?
  Columnar: Yes. Silently truncating is not good.
  Bhakta: A lot of linkers are not going to change. In practice, the compiler will comply with C2y, the linker will not. That's a worse case than what we have.
  Decision Poll: Would WG14 like to adopt N3911 as is into C2y? 2-0-3+13-4-3=15-4-6 strong consensus to adopt
  

• Thomas, Proposal for C2Y - Annex F floating-point environment updates [N3779] (0.5 hours)
  

  Myers: Note to editor: update J.3 with the implementation-defined behavior.
  Banham: Do we really need the implementation-defined behavior?
  Bhakta: A programmer and program can know which flow model you have.
  Cranmer: IEEE 754 specifically allows either one to be the default value.
  Decision Poll: Would WG14 like to adopt N3779 as is into C2y? 3-0-1+14-0-0=17-0-1 strong consensus to adopt
  

Wednesday, 19 August

• Karl, Remove undefined behavior for mismatched quote characters [N3806] (0.25 hours)
  

  Myers: There are issues with the wording. We put things in the constraint section rather than saying "a diagnostic is required".
  Gustedt: This would be good material for the Wording Group.
  Seacord: Any objection to saying the committee would like to forward this to the Wording Group? None
  

• Karl, Remove undefined behavior for non-basic source characters in source files (modified) [N3807] (0.25 hours)
  

  Myers: N3866 is a newer? version of this paper.
  Karl: There are three possible solutions: constraint violation, implementation-defined, extensible behavior
  Svoboda: Extensible behavior came from my "How to Slay Earthly Demons" paper.
  Bhakta: We Need to address a problem before proposing these three solutions. Hubert Tong posted to the reflector: N3807 proposes to allow non-basic source characters (including any such characters that are multibyte characters) in source files outside of the current contexts where they are allowed. For most of the current contexts where they are allowed, there is a restriction that the associated lexical element begins and ends in the initial shift state. The paper should explore the possibility of coordinated changes to the shift-state restriction.
  Ballman: I prefer this to be implementation-defined. It is worthwhile exploring Hubert's post.
  Gustedt: We need "implementation-defined" for part of these things.
  Straw Poll: Would WG14 like to adopt something along the lines of using implementation-defined behavior for N3807? 3-0-0+9-0-6=12-0-7 strong direction
  Bhakta: Is there any plan to solve the wider problem?
  Action Item: Karl: Solve the wider problem from N3807.
  

• Karl, Remove undefined behavior for invalid multibyte characters and non-initial shift states in preprocessing tokens and header names [N3808] (0.25 hours)
  

  Gustedt: This thing is confusing. When we are talking of identifiers, we are in translation phase 4; multibyte characters are gone by that point. This should be examined for clarification. There is a wider problem of multibyte characters in the source file, not just identifiers.
  Myers: We should study p2295r6 which was adopted for C++.
  Gustedt: We should support all multibyte encodings, including UTF8.
  Bhakta: Hubert Tong had a reflector post. This does not need to be a constraint violation. Some other tool from the OS can resolve multibyte characters.
  Myers: With regard to C++ papers, do you want things to be valid everywhere or ignore invalid chars in comments? C++ supports UTF8 which must be valid everywhere, even inside comments.
  Gustedt: We could say we do not care about these things as long as we have valid chars in phase 1. We should have explicit text on this matter.
  Ballman: This took a lot of effort in C++ from the Unicode Study Group to get right. We should try to use the same wording as C++. Some implementations might struggle with supporting UTF8. I fear we differ from C++ enough to cause problems in the shared header space.
  Krause: Even if we require that individual code points are valid encodings that does not mean the whole thing is valid text, because of valid characters. We might have a few users that rely on SDCC passing things through in string literals.
  Seacord: I suggest Karl contact Jabot, Honnerman, and bring in co-authors.
  

• Thomas, C2Y proposal - Standard pragmas and headers (Updates N3702) [N3842] (0.5 hours)
  

  Krause: Does this make any change for free implementations that do not support these headers and pragmas?
  Bhakta: If implementations wanted to support the pragmas but lacked the headers, they could.
  Seacord: So this is editorial? This paper makes no normative changes, right?
  Bhakta: You do not need the headers for these pragmas.
  Ballman: This paper makes normative changes but no one is expected to change their behavior.
  Decision Poll: Would WG14 like to adopt N3842 as is into C2y? 3-0-0+16-0-2=19-0-2 strong consensus, adopted.
  

• Thomas, C2Y proposal - Conflicting requirements for double_t [N3843]
  

  Myers: Could we consider this extension for obsolete versions of C?
  Bhakta: If we vote this in, I would agree.
  Seacord: I do not understand what the differences are here.
  Ballman: Clang is not impacted by these changes. But GCC has decimal floating point; how are they impacted?
  Myers: There would be a change to the glibc headers. We do not have any targets in GCC that use this combination. We do not foresee user problems.
  Decision Poll: Would WG14 like to adopt N3843 as is into C2y? 3-0-0+14-0-0=17-0-0 adopted
  Decision Poll: Would WG14 like to recommend N3843 to apply to older version of the standard? 3-0-0+14-0-0=17-0-0 adopted by strong consensus
  

• Bhakta, Range bounds for complex math functions [N3896] (0.5 hours)
  

  Decision Poll: Would WG14 like to adopt N3896 as is into C2y? 3-0-0+13-0-2=16-0-2 strong consensus to adopt
  

• Colomar, The Elvis operator ?: [0N3905]
  

  Ballman: I looked into the preprocessor implementation in Clang. We do not use the same logic; the implementation is manual. This is not free. I am opposed because it diverges the preprocessor more from C++. The wording is awkward (but correctable) to me because it specifies the parameters by count.
  Celeste: It is a different expression for us. Making little changes like this is easier than for the core language.
  Cranmer: What happens if I contract a + (b c ?: d) into b * c ? fma(b, c, a) : a + d) ?
  *Columnar: I think so but I am not an expert.
  Gustedt: I like this operator, but I have the same reservations as Ballman. This is not implemented in any common preprocessors. When people try to use these and fail. It is for those platforms that implement this operator means they are not consistent for expressions between the language and preprocessor. I would be in favor in the long run, but we should coordinate with C++, so this needs time.
  Columnar: This contracted version of the conditional operator, I could not find in existing code, but I could not find conditional operators at all in any #if code.
  Meneide: I am not concerned that this does not show up in the preprocesor.
  Myers: , With regard to diversions, a couple of glibc headers do have condition operators.
  Bazley: I agree with Meneide. Users are unlikely to care if this is implemented in the preprocessor. Anything that avoids multiple evaluation is valuable.
  Bhakta: Given our concerns, is it possible to do this in the language but not preprocessor until we have experience with it?
  Columnar: We could, but it would complicate the syntax in the specification.
  Gustedt: I would be against separating that. The preprocessor only have constant expressions. This would mangle all the different definitions that we have.
  Ballman: In the long term, we may want something like this. Const expressions carry long-term semantics. I would not want to see a carve-out for this.
  Svoboda: Does the example in the final line returns a pointer or 1?
  Columnar: The example prevents 0 from being passed to realloc().
  Bazley: This was funny. Columnar said that he implemented this as the cake preprocessor in just a few lines.
  Gustedt: I implemented this, but it was a little more work than a few lines.
  Columnar: With regard to the C++ concern, we could accept this conditionally to not having strong opposition from WG21 until the next meeting.
  Seacord: A conditional adoption means that no one can object (not just WG21)
  Ballman: We should not be adding examples with undefined behavior. The example should #define my_realloc(), not redefine realloc().
  Banham: I am not convinced of the value of this. The body of knowledge about C will get tripped up by this.
  Columnar: That is a common problem and you can find instances in the Linux kernel.
  Decision Poll: Would WG14 like to adopt N3905 with changing the first realloc() to be my_realloc() into C2y? 1-1-1+9-6-2=10-7-3 not strong consensus, not adopted
  

• Colomar, array parameters of 0 elements [N3802] (0.5 hours)
  

  Seacord: C is a common interface between multiple languages, and Rust supports zero-length arrays. We should add it in to support Rust.
  Bhakta: I like the general idea. The syntax is confusing with the zero-extend-derived types for structs.
  Liber: So sizeof this array is 0?
  Columnar: It is just a pointer.
  Celeste: Rust has zero-sized types as part of the type system. The language is coherent in what they mean. If we want this, we want to answer other such questions like what is a struct with 0 elements?
  Seacord: We had malloc(0), and we deprecated realloc(0).
  Uecker: There is a lot of existing code that is undefined because we do not allow 0's.
  Myers: The extension of 0-sized types would involve a lot of tricky issues. An array of 0-sized elements creates problems.
  Celeste: I support this, because 0 is information that is being thrown away.
  Ballman: This is reasonable,but is fine as a conforming extension. Nothing prevents an implementation from supporting this today.
  Columnar: GCC supports it, kind of.
  Bazley: What does "as many as 0 elements" mean? If not for the syntax no one would be talking about arrays.
  Svoboda: The sizeof(array) / sizeof(type) idiom becomes problematic if sizeof(type) == 0.
  

Morning break

• Na/, Forward Parameter References through Retroactive Scoping, v2 (Updates N3830) [N3923]
  

  Celeste: I like this. But I am worried that "constraint" is too strong. Unrelated libraries can collide with each other. I would recommended practice be strong enough.
  Bhakta: I like the changes. I also like that there is no new syntax for it. Some compilers still have issues with far-enough look-ahead; that is my only concern.
  Gustedt: I am sympathetic to this approach; we need a solution. I am still baffled that we did not get any other solutions. I am scared of the complexity. I would still prefer forward declarations.
  Celeste: This is similar for pre-C90 where you had to hook up with a declaration later.
  Adams: How does this integrate with the type system? Is it separated?
  Na: Your question is about the attributes, right? This is not about attributes. We have other proposals about intended attributes. What is your proposal number?
  Adams: My example is for the noreturn attribute. What is the current status for the C type system?
  Na: This proposal is for core language array size.
  Bazley: SDCC already supports forward parameter declarations, but is more limited than GCC. I wonder if this is an over-engineered solution for a problem that does not need to exist at all?
  Celeste: Is this ready for the Wording Group?
  Gustedt: No, there are too many unanswered questions.
  Columnar: I strongly prefer forward declarations. I like this proposal more. Given that small implementors cannot implement this, I am not comfortable accepting this.
  Uecker: The SlimCC developer and another compiler developer wrote in a discussion about general features that they are worried about parameters for active declaration scoping. It is difficult for them to implement this. They would rather implement template C++ functions.
  Na: I need to discuss with that person offline the nature of their problem.
  Colomar: Would it be acceptable for Clang to propose forward declarations, and then allow compilers to decide whether they want to do this retroactive parsing?
  Tarditi: You could use that rationale to deny many changes. I do not think this is a serious issue. We could add implementation-defined limits if forward tokens is an issue.
  Celeste: This could potentially be optional. I do not think that is possible. It does not give any cues to the compiler. Which bits would be optional? If the expression in the array bounds is limited to an identifier, there is no parsing problem.
  Meneide: We do have an "implementation limit" section in the standard for such things. Limits on look-ahead for this feature can go there.
  Straw Poll: Would WG14 like to adopt something along the lines of N3923 for C2y? 3-0-0+12-7-4=15-7-4 strong direction to proceed
  Gustedt: If we want this into C2y, we should have a paper with the semantics cleared by November, so it can go to the Wording Group.
  

• Meneide, Thread Attributes, r5 [N3916] (0.5 hours)
  

  Myers: I listed wording issues on the reflector.
  Seacord: Can this go to the Wording Group?
  Ballman: This is an odd use of the word "attributes", as it is not the language feature, but rather English usage.
  Meneide: There is existing practice (including from POSIX) of "attribute" that is unrelated to C attributes.
  Straw Poll: Would WG14 like to adopt something along the lines of N3916 for C2y and forwarded to the Wording Group? 4-0-1+9-1-9=13-1-10 strong direction to forward to Wording Group
  

• Múgica, Discarded, VI [N3909] (0.5 hours)
  

  Myers: I am happy with the wording.
  Ballman: C++ has a "discarded-value expression" term they use, which would clash with this one. There is some curious fallout. If you have 0 && 0.0, that is ICE, but 0.0 && 0 is not ICE. That makes it less syntactic and more semantic. It makes things more awkward. Nonetheless, I do think this is heading in the right direction.
  Gustedt: Yes, but the && operator is not symmetric.
  Banham: I was puzzling over changes to 6.5.14 and 6.5.15. If the first operand is an ICE it discards the second operand. Does it depend on the value of the constant expression?
  Gustedt: Yes. It is not ideal.
  Ballman: I posted a link to the C++ definition of discarded value expression. If you cast to void that means you want the side effects.
  

Lunch Break

• Meneide, Transparent Aliases, r8 [N3913] (0.5 hours)
  

  Colomar: This is essentially references and makes the code unreadable. I would not rename a lot of variables with macros. References make the text unreadable.
  Meneide: These are not references. References in C++ are actual things that can take up space, put in structures, etc. You cannot store an alias.
  Colomar: Could you duplicate line 20? Can you modify b in the middle of that, and then print the value of a? We do not have it in C, except through pointers. This will be weird for readability.
  Seacord: This use case is designed towards evolution of your code base for the same feature. When you create this alias, it is pointing to the same thing. If my code calls v0 name, I get the deprecated message. It feels very dangerous to get the old semantics.
  Meneide: You have these backing variables. Instead of deprecating or changing things, you provide the same functionality.
  Bazley: I think the typedef syntax was my suggestions. I immediately regretted it. The committee said we do not want this to be as complicated as typedef. My appetite for controversy has gone down since I joined the committee. I would like to hear people intending to use this feature speak up for it.
  Meneide: The reason we had the typedef syntax was because we wanted to make it simpler, as in, "alias $oldname $newname".
  Jones: I think the syntax is fine. There are more linker-focused existing ways to do this. What does this mean for standard libraries and the evolution of the standard library? My concern is that when we make an alias, that is the same as adding a new function. I am concerned about using this too much. If this gets accepted, then the committee needs to be careful not to use it too much.
  Bhakta: I am strongly in support. As a library developer, I am very happy with this; it gives me a portable way to write libraries.
  Douglas: I strongly support this paper; my libraries are using the same technique, and so do the Boost libraries. It should be standardized.
  Celeste: If we had had this in C23, it would have made the reproducible attribute more attractive.
  Gustedt: I am still torn about this feature. If we had this syntax, it is OK for functions and constants. I am not OK with the aliasing modifable variables. I really do not like this aspect.
  Meneide: That makes sense.
  Ballman: I support the general idea. But there is a lot of discomfort over how is this going to be used. I know it is implemented in a fork of GCC. I would like to see deployment experience before standardizing it. It might make sense for TRFI.
  Bachmann: I am not convinced, but I could be convinced if this were limited to names of a global scope. I fear that reviews will become much more difficult otherwise.
  Bhakta: That was really what Bachmann was saying; it is really for constants, not local variables.
  Serebrennikov: I wonder how this interacts with C threads, similar to attributes.
  Ballman: I have not checked the paper, but my understanding is that it would interact with the C23 feature. You would expect them to work. You could use typeof() on them.
  Uecker: I see no interaction at all.
  Bazley: If this were restricted in power, I would be more inclined to support it.
  Meneide: When I first wrote this paper it was just for functions. I can go back to that if that is what people want.
  Ballman: I am confused by these aliases being declarations. So any attributes are declaration attributes not type attributes. Attributes like "deprecated" would not apply through aliases. Attributes can always associate to the right.
  Celeste: This would reduce the number of special-case rules. You should be fine restricting this to functions and not supporting variables.
  Colomar: Łukasiewicz says rather than preserving ABI, it permits the API to diverge from the ABI.
  Bazley: Ballman, you raised the issue about where attributes should be allowed. If the alternative syntax is there a question of where the attribute goes?
  Ballman: Does the typedef form vs. the assignment form make a difference for the attribute name? I think the assignment form makes it more clear.
  Bhakta: These are already features out there but they are non-standardized. In practice, this has not been a problem with all the fears people are saying.
  

• Munger, Memory allocation with size feedback v4 [N3899] (0.5 hours)
  

  Banham: You referred to issues with realloc(). The paper does not indicate whether extra the space requested is usable. Is it?
  Munger: In the proposal, no. You can use all the space malloc() gives you whether or not you requested it.
  Bhakta: You did not want unspecified opaque types to be supported to avoid breakage. The reason to not include more is not just for ABI but is also what the standard practice is. There are wording issues. Does this have issues with object types and memory access outside the object in the C wording?
  Munger: The way this is specified is that alloc() returns an object of the size it says it is.
  Colomar: The MUSL developers believe this will be a performance hit. They are also concerned about safety.
  Munger: You could implement this with malloc() and not indicate that extra memory might have been allocated. It is a problem that there is no way for allocators to communicate the extra available space.
  Colomar; How many implementations will benefit from this?
  Munger: The cheap benefit is making more eficient use of the memory.
  Bazley: I like this paper. There can now be lots of internal fragmentation, which used to be improbable. This paper mitigates that to some extent.
  Gustedt: We put a lot of effort into making our list of reserved identifiers more precise. These names should come from our reserve list.
  Meneide: I strongly support this.
  Straw Poll: Would WG14 like to adopt something along the lines of N3899 and forward it to the Wording Group for C2y? 3-0-2+12-4-5=15-4-7 direction to forward this to the Wording Group.
  

Afternoon break

• Meneide, Defer block (30 minutes)
  
  • defer Technical Specification (Committee Draft), r5 [N3853]
    

    Douglas: I asked an LLM (DeepSeek 340731) to analyze when to allocate and free resources. The LLM recommended the #1 thing from considering C to be the best feature was a "defer" statement.
    Action Item: Seacord: Convener to submit Defer TS for ballot (once remaining issues are fixed).
    

  • Improved __attribute__((cleanup(…))) Through defer, r5 [N3852]
    
• Meneide, _Any_func* – A Universal Function Pointer Storage Type, r6 [N3914] (0.5 hours)
  

  Bhakta: In section 6.15, why is CHAR_BIT the value for bit pointer width?
  Meneide: Those are minimum values.
  Myers: I commented on the reflector, most of my issues are wording issues. First, the main feature, second, scanf() support.
  Gustedt: I observe that uintptr_t has a minimum of 16.
  Meneide: This is because it should be able to represent 16 bits of objects.
  Straw Poll: Would WG14 like to adopt something along the lines of printf and scanf support for _Any_func pointers in N3914? 4-0-2+12-4-2=16-4-4 strong direction
  Straw Poll: Would WG14 like a two-macro solution to be conversion-reporting in N3914? 1-0-4+3-6-7=4-6-11
  Straw Poll: Would WG14 like a one-macro solution to be conversion-reporting in N3914? 0-0-5+8-1-8=8-1-13 we'd like a one-macro solution
  Straw Poll: Would WG14 like to see something along the lines of N3914 in C2y? 5-0-1+13-1-4=18-1-5 clear direction
  

• Múgica, array ICE subscript out of bounds [N3791] Discarded, VI [N3909] (0.5 hours)
  

  Ballman: This is building on top of N3517 where we still do not have any deployment experience. I worry that this is premature.
  Gustedt: This is about array types not pointer type.
  Celeste: This is something my implementation does warn about.
  Uecker: Clang diagnoses that today. GCC does not.
  Myers: I posted wording issues to the reflector.
  Straw Poll: Would WG14 like to see something along the lines of the short proposed wording in N3791? 3-0-2+7-2-8=10-2-10 strong direction
  Bhakta: I abstained because I want implementation experience.
  Straw Poll: Would WG14 like to see something along the lines of the further restriction in N3791? 1-0-3+5-2-8=6-2-11 weak direction
  

• Celeste, Allow arrays of incomplete element type, v2 [N3839]
  

  Banham: How can you have an array of incomplete objects?
  Celeste: You cannot. You can have an array derivation from a complete type. You can construct a pointer to one of these types.
  Bazley: I am sympathetic to Banham. It is not clear what the motivation for the paper is. Is this just an artifact of the fact of declaring pointers in a function's parameter list? It is hard to comprehend.
  Ballman: I also do not quite understand the motivation. If we are going to progress, we need as much motivation as possible.
  Cranmer: I am confused as to motivation. You are trying to talk about objects whose size you know but whose types you do not know. And you are trying to abuse the type system.
  Celeste: You know the size, but you do not know the type because it is opaque.
  Colomar: I need this for other papers, and will have to work around it if not adopted. This will improve things like countof, it will simplify my life.
  Straw Poll: Would WG14 like to see something along the lines of N3839 for C2y? 3-0-2+8-5-3=11-5-5
  Celeste: How hard are the nays?
  Bhakta: I want implementation experience.
  Colomar: I am trying to convince GCC to implement these things, but Myers is pushing me through the committee first.
  Cranmer: This seems like a dangerous change, and needs motivation in the paper itself.
  Banham: The examples on screen look reasonable, but it is the sentence below that declare an external identifier of void that confused me.
  Bazley: The root of this is semantic confusion about what void means.
  

• Svoboda, Hunting Another Ghost - Macro Suppression [N3918]
  

  Decision Poll: Would WG14 like to adopt N3918 as is into C2y?
  5-0-1+15-0-0=20-0-1 strong consensus, adopted
  

Thursday, 20 August

• Ornato, Function contracts [N3825] (0.5 hours)
  

  Gustedt: This only has preconditions, right? When it is supposed to test the condition? If it is not proved statically, we assume it without testing, right?
  Ornato: Yes, only preconditions. We could add return values. Checking the condition does not have to be an active process. If the compiler cannot static-assert it, then we just go on. It is still undefined behavior so sanitizers could catch them.
  Krause: Using attributes looks like an elegant approach, placed on the function declaration. For function type it would be on the right side. My intuition would be to put the attribute on the type. Why did you put it there? What do you think of the alternative?
  Ornato: I am open to that. It makes more sense to deal with the type.
  Ballman: This attribute already exists in C++, but cannot go aon a function declaration. Having the same attribute in both languages with different definitions is not a good idea. I do not want to see more type attributes standardized. The current ones are problematic. It is better to be a keyword than a type attribute.
  Bazley: I am interested in the example of the divide function. My concern with contracts is different people have different ideals of what they are for. If there were an explicit check for 0, I would prefer it be honored.
  Ornato: I included that example for clarity. The check is checking for undefined behavior. I wanted the contract to be included in the prototype, in the header. As for coding standards, if we check for 0, it would be optimized explicitly.
  Ballman: Myers points out that the contracts people should unify and submit one proposal.
  Colomar: I disagree; it is good to have contract proposals competing.
  Uecker: The poll question when we do not know what they are doing is not useful.
  Ballman: Should we have a Contracts Study Group?
  Bhakta: Study Groups have to have a chair, agenda, and minutes. The language could be French.
  Straw Poll: Would WG14 prefer that contracts be part of the type system? 2-1-1+3-7-7=5-8-8 more opposed than in favor.
  Straw Poll: Would WG14 like something along the lines of N3825 in C2y? 2-1-2+6-6-3=8-7-6 no direction
  

• Veldmeijer, The malloc_allocated_size function [N3869] (0.5 hours)
  

  Seacord: How does N3899 compare to your paper?
  Veldmeijer: Hmm, I haven't seen it.
  Krause: I do not understand section 1.3. It malloc's 65 bytes, and realloc's to 100, and then there is an unnecessary copy. I know SDCC would allocate one byte more, and claims this is O(1).
  Veldmeijer: It is not correct. Agreed.
  Celeste: The standard library provides interfaces to the allocator. This is hidden state that we could expose so we should.
  Bhakta: I have the opposite opinion. N3899 returns the size; it does more than this does. That should be the only way to do it. This is not as safe because it does not already exist on some platforms.
  Jones: In our N3899 discussion, lookup may be expensive. If you know the size is X bytes, but you only requested half of that, then overwriting the second half is still undefined behavior.
  Svoboda: This paper has no normative wording, but something akin to a man-page. Could the Wording Group fix the wording or would we need another paper?
  Gustedt: The Wording Group could handle it.
  Seacord: Munger and Veldmeijer should get together and collaborate on a paper.
  Uecker: This does not work with sanitizers. This is the experience people had with interfaces.
  Bazley: Whether the type passed to free() must be const-qualified, this adds another one. Users say we want it to work like malloc(). I want it to be type-safe. There is an unwarranted assumption that the metadata contains the size. It is not a type-safe interface to get that information. I was in favor of returning an object; but a memory allocation that returns an object needs to be freed.
  Ballman: Deployment experience helps answer these kinds of questions. The previous proposal solves our current deployment experience.
  Banham: This breaks the abstraction of the allocator, exposing its internal workings. Why add user code when you can call realloc()?
  Colomar: realloc() never returns the old object; it returns a new object even if the address is the same.
  Liber: People might want this to know if realloc() would return the same thing or not, but this does not solve that problem.
  Straw Poll: Would WG14 prefer something along the lines of N3869 rather than N3899 for C2y? 0-1-1+0-17-5=0-18-6 direction in favor of N3899.
  

• Colomar, incompatible array parameters [N3933]
  

  Myers: There are a few issues. This is making issues with the same type worse, which is covered in Issue 1013. Regarding ABI specification interfaces; this is changing the description of adjusting the pointers to arrays and vice versa.
  Colomar: I want to wait until we address the same-type issue. I am working on a paper to handle changing all the library prototypes. ABI's should not change and still use the adjustment thing. But as an extension, some compilers might improve that, but that is not mandated by this.
  Krause: I like the idea in general. There are two different things for normal array parameters. I do not like the duplication of static; it has a meaning of this many things. I prefer not to mix it. I would vote for this if it didn't make a change to static.
  Bachmann: This breaks too much so we should not do it.
  Ballman: Implementors should know that constraint violation means error by default. I could never turn this into an error in Clang. This should remain as a recommended practice.
  Uecker: Why does this require Celeste's paper about incomplete types?
  Myers: Because it speaks of adjustments.
  Bazley: The biggest argument for doing this is that C99 added static array bounds. There is a lot of bad stuff about static array bounds. I am more dubious about diagnosing this when there is no static keyword. For many decades, programmers have not known or exploited the fact that what is between the brackets is not important.
  Celeste: This is the kind of thing we have warnings for. MISRA forbids it.
  Krause: This feels like two different intents to be communicated.
  Colomar:I would like to see some real code that does that without being a mistake.
  Straw Poll: Would WG14 prefer something along the lines of N3933? 1-0-4+7-7-4=8-7-8 no direction
  Celeste: This being for a future version swayed me from neutral to supporting it.
  Ballman: My no vote could be changed but only if it is not a constraint violation.
  

• Colomar, comparable types [N3931] (0.5 hours)
  

  Bhakta: I saw comparable types differently from the English understanding. There is not just ==, there is also the relational types. A different term might make sense but this term does not.
  Colomar: If you have a better term, I would welcome it.
  Krause: I am not happy with "comparable", but I like this paper.
  Myers: I am not happy with how this is worded. I am not convinced that what is stated in the footnote is clear from the normative text. This ought to be ideal to send to the Wording Group.
  Colomar: I cannot go through the Wording Group.
  Bazley: I support this. Introducing a term has value in clarifying existing wording. I claimed, mistakenly, that at heart C is all about reference types.
  Colomar: Celeste suggested "value-equivalent types".
  Ballman: I do not think the standard has a definition for what qualifiers or access qualifiers do. We are going to have compatible types, comparable types, and composite types. This would be confusing.
  Bazley: This is way too late. We should not be bike-shedding wording.
  Decision Poll: Would WG14 adopt N3931 as is into C2y? 1-4-0+5-11-0=6-15-0 no consensus
  Colomar: Ballman says it is about access qualifiers. It has some constraints and is not an access qualifier if you violate those constraints.
  Ballman: Similar types might be acceptable. I would like to study the C++ standard before voting on anything.
  Seacord: We could do an online vote.
  Straw Poll: Would WG14 like something along the lines of N3931 with a different name into C2y? 4-0-2+7-3-5=11-3-7 strong direction
  Seacord: We could now do an online poll if we get a new paper.
  Jabot: Did not vote, because I would like similar wording, but I dislike the term "access qualifier". C++ has been using "cv-qualifier", and there is no reason for C not to use this term.
  Gustedt: We should not call it "cv-qualifier" because we also have restrict. Perhaps "standard access qualifier" is a suitable term?
  

Morning break

• Colomar, substitutable types [N3907] (0.25 hours)
  

  Ballman: There is not much motivation for this paper.
  Banham: I agree. The second paragraph refers to future proposals. These are small inconsequential changes precising a much bigger change that the rest of us are not privy to. It would make more sense to present the big change.
  Colomar: Bazley presented the big change a few meetings ago. It was "type variance".
  Seacord: That paper was N3674.
  Bhakta: This is a chicken-and-egg problem. I do not see a direct link between N3097 and N3674.
  Ballman: Are these not supposed to have any impact on any implementation?
  Colomar: Correct!
  Gustedt: We only have the list of papers, we should not accept any papers with no rationale.
  Cranmer: The new term has only one use in your proposal. The argument that it simplifies the proposal does not hold up.
  Colomar: I see three uses.
  Seacord: The description says one use.
  

• Douglas, Constexpr function pointer initialisation [N3937] (0.5 hours)
  

  Myers: I have comments about the wording.
  Gustedt: We shied away from doing pointers at all. We do not do anything that concerns Phase 8 (linkage). I agree that nobody has problems with determining pointers to object or function with linkage. So we could add that. If we agree on semantics, we can put this to the Wording Group.
  Seacord: This is the history of the committee that puzzles me. We were near the end of the C23 cycle, but people were nervous about committing anything. Then C23 gets published and this never comes back.
  Ballman: I support the idea. Function designators can never be NULL. If it is in the model that C++ supports, it is a useful feature.
  Douglas: I agree that the wording is unnecessarily wide.
  Straw Poll: Would WG14 like something along the lines of N3937 for address constants for both function and object pointers and to send the paper to the Wording Group? 3-0-3+14-1-4=17-1-7 strong direction to forward to Wording Group
  

• Celeste, Simple vector types [N3837] (0.5 hours)
  

  Douglas: I love this, it is long overdue. It is confusing to have "vector" and "_Vector". I urge that you do not call it "vector".
  Celeste: I welcome alternative terms to "vector".
  Bachmann: I would love to see vectors in the standard, but not this one. We have proposals with much more readable wording. We need 2-3 meetings to clean up the fallout. I would rather go with the proposal from Sharif (Yaghmaour).
  Celeste: I do not see my paper as competing with Múgica's paper; they are both useful. Mine is as close as you can get to existing practice.
  Krause: Vectors look like arrays. They will be implemented like arrays in the hardware. The syntax for declaring them should be similar to array syntax.
  Celeste: That is in the specification. A vector might have additional alignment requirements, so array-to-vector conversion is hard, but vector-to-array conversion is easy. I welcome contributions for how it can be made prettier.
  Cranmer: There are difference in the semantics of the various floating-point units. Have you thought about how vectors of complex floats work?
  Celeste: Not explicitly.
  Myers: I have comments on the reflector. Having this feature is a good idea; it does correspond to existing extensions.
  Bhakta: I like the feature. I actually like "_Vector". We should be focusing on what is the benefit to C.
  Jones: Having a standardized way to manage vectors in C would be great. The existing libm vec API uses floating-point numbers of different types but indeterminate length. I am not sure what we would want to do there but it is worth considering.
  Ballman: I support the intent of this proposal. I am curious if you are aiming for C2y given our schedule. It would be great if the committee gave direction in favor, but someone provided a patch to Clang. The "for C2y" gives me pause.
  Celeste: I was aiming for C23 but missed badly. This is so far off that I do not think C2y is a realistic target.
  Douglas: Down the line we might want to standardize a vector container. We would likely choose _Vector to match C++. So I do not like "_Vector". It is also confusing in the debugger.
  Liber: C++ uses "vec", not "Vector" for this stuff.
  Bazley: I am not sure this is the right abstraction, given the demand that compiler intrinsic produce particular output has been lost. The prior art is a bit outdated.
  Celeste: If you request a vector of 5 things, and the compiler gives you 8, that is an abstraction; the 5 is a semantic property, not an implementation detail.
  Cranmer: I agree and disagree with Bazley. One of the missing features is that C lacks the ability to describe the sim registers.
  Bhakta: A previous proposal have given macros for vector size, which could be used here for vectors.
  Bazley: I would prefer any solution to be based on array-like syntax. The main utility is to make it easier to express code that is vectorizable. My overall concern is: it appears to offer a low-level abstraction. The trend seems to be going from compiler-intrinsic equal instruction to the opposite.
  Banham: Could we get everything we want by not having a vector type, and supporting arithmetic operations on arrays?
  Celeste: That would be a big change on how arrays work.
  Gustedt: They work because you can add integers to pointers.
  Bazley: Array alignment is so hardware-specific in that it does not belong in a high-level language. If you do super-low parallelism, you do not even need an array in the first place. I am wary of a proposal tied to the current generation of hardware.
  Straw Poll: Would WG14 like something along the lines of N3837? 4-0-0+10-1-5=14-1-5 clear direction
  

• Colomar, Split formatted I/O sections (Editorial) [N3754] (0.5 hours)
  

  Myers: I would like to see a complete proposal for the Annex K functions.
  Seacord: If we vote this in, it should not apply to Annex K.
  Svoboda: I do not see a good motive to do this. Why is this proposal better than the status quo?
  Bazley: I do not think people learn C from the standard. This change does not have much effect.
  Gustedt: I want to emphasize that such papers do not change the standard. If we restructure the standard, this is a lot of work for the editor. I do not see the real gain.
  Seacord: The downside is that section numbers change.
  Decision Poll: Would WG14 like to adopt N3754 apply to subcluase 7 only into C2y? 0-3-4+4-7-4=4-10-8 no consensus
  Meneide: This paper does not help, but it is not harmful.
  Colomar: Would you be OK with taking the function order form here for future papers?
  Seacord: That is between you and Meneide, our editor.
  

Lunch Break

• Myers, C23 issue log, r5 [N3910] (1.5 hours)
  

  Myers: Can we use a separate tracker for issues of features new to C23?
  Ballman: If we have the same process for issues, we could avoid writing a paper.
  Seacord: Each issue is a small paper.
  Decision Poll: Do we want to maintain an issue list for C2y? Objections? None
  

  • 1001. Qualified rvalues from structure or union members
    

    Ballman: It is a good direction for us to go, but it may be a while before we have this implemented in Clang.
    Objections? None
    Moved from Review to Fixed
    

  • 1004. Classification of scanf failures
    

    Objections? None
    Moved from Review to Fixed
    

  • 1012. Error returns from specific width length modifiers
    

    Colomar: I have an action item to write a paper for this. If Meneide applies the movement of the functions, it becomes easier to write the paper. I am working on it.
    

  • 1013. Ambiguity of "same type"
    

    Ballman: The answer to question 1 is yes, attributes affect type. For question 2: we do not rewrite what the user wrote explicitly. For question 3, the answer is yes, static does not affect the type. For questions 4 and 5 I do not know.
    Uecker: My preferred solution is to eliminate the notion of the "same type". I proposed to make types based on compatibility instead, but never followed up because of the C23 feature freeze.
    Colomar: I like Uecker's proposal. If we have to answer this question, a function taking const int vs. function taking int are not the same type, although they are compatible.
    Gustedt: It is not true that we do not use "same type", it is the basis for compatible type. We need that for the standard types. The suggestion that we do not base typedef on "same type", but use compatible types is a good idea. That would remove this usage of "same type" from the standard.
    Ballman: In C23 when we agreed that two structures in the same translation unit can be compatible, I feel we opened this can of worms. My understanding was this was for the case where we describe types inside of macros. It is really a case of being token-for-token identical. How important is compatibility vs. toke-for-token identical?
    Uecker: Every question you could have about this new feature you could have asked about compatible types. Is it important for re-declaration to be compatible? A type system based on token is a bad idea…arbitrary syntactic changes suddenly makes things incompatible.
    Ballman: I thought token equivalence is a portable guarantee,
    Colomar: The typeof() specifier is ruled out by token-by-token comparison.
    Ballman: I would like to rule that out, because the text in the source code is different. It is observable to the user which one is the type. C++ has the concept of token equivalence for template instantiation.
    Serebrennikov: Another piece of wording you can borrow from C++ is the one-definition rule. Each definition shall consist of the same sequence of tokens.
    Gustedt: This is much harder.
    Myers: Would anyone take an action item to write a paper?
    Gustedt: I would team up to remove 'same type'.
    Meneide: We have one place with "same types" in the standard. If you start putting "reproducible" on function types, we have to think about that.
    Colomar: We still need to use "same type" in the standard, because we need to say what typeof() does.
    Action Item: Gustedt, Uecker: Write a paper to address Issue 1013.
    

  • 1017. Unspecified timing and synchronization for cnd_t functions
    

    Gustedt: There was a paper addressing this: N3764. The problem is that this should be synchronized with the other standard's concern.
    Ballman: That might change now that they are done with their VLS.
    

  • 1018. Issue with enum compatibility
    

    Uecker: I have an action item to submit a paper. It is written, will be submitted for November.
    

  • 1019. String functions and trailing null inclusion
    

    Colomar: I remember having read that carefully, everything is fine.
    Uecker: This looks safe to me.
    Objections? None
    Moved from Review to Fixed
    

  • 1020. Definition of address constant
    

    Objections? None
    Moved from Review to Fixed
    

  • 1021. Integer promotions for enumerations
    

    Myers: Seacord did not like my suggested wording.
    Gustedt: This is exactly what we should do.
    Seacord: "applied to certain kinds of" seems very vague.
    Gustedt: So we remove "certain kinds".
    Celeste: The conversions are applied to the operand for certain expressions, right?
    Myers: I should take an action for revised wording.
    Action Item: Myers: Revise wording for Issue 1021
    

  • 1022. Void expressions and lvalues
    

    Ballman: I did some investigation. There is implementation diversions here. For question 1, the construct is accepted by Clang, GCC, SDCC, but is rejected by MS. For question 2 it is not an lvalue. Question 5 had compiler divergence more than question 1. Question 7 should be same as question 2. Question 8 I did not answer. Question 9 I do not think a qualified void should be special compared to void.
    Uecker: Void is strange; we use it in different ways.
    

  • 1023. static_assert in structure and union definitions
    

    Ballman: static_assert in a struct is accepted by 7 compilers and rejected by 4, including SDCC and GCC.
    Celeste: We could allow unnamed members because there is an interpret-able meaning to them.
    Uecker: If there is interest in allowing that, I would write a paper.
    Colomar: I think this is useful, if you want struct members reserved. People come up with unnamed members.
    Gustedt: People currently use bit-fields for that.
    Action Item: Uecker, Myers: Write a paper to resolve Issue 1023.
    

  • 1024. Redeclaration of standard library typedefs
    

    Ballman: I am not convinced that this is a good idea. Allowing that in the first place was done for historical reasons.
    Celeste: It is a bad idea to allow users to redefine functions from the standard library. We should be scaling down on that.
    Action Item: Myers: Write proposed edit for Issue 1024
    Douglas: The windows.h header has lots of declarations, which can be overridden by local declarations.
    Myers: This is only concerned with standard C library headers
    Colomar: There is an opposite direction: disallowing forward declarations of anything in the standard library.
    Ballman: We have 3 different standard library implementors in the room. What do they want? I thought that was a frustration for standard library authors?
    Jones: No, I agree with Myers. You are allowed to write headers, but if this is about users redefining your types, that will cause problems.
    Gustedt: I am not sure this is consistent with what we decided today with typedefs. ?Leave the compiler to do its work.
    Krause: Gustedt, you brought the paper to make _Bool a keyword.
    Gustedt: For _Bool it was explicitly permitted to redefine it.
    Bhakta: I've seen users use it. This just makes it undefined behavior.
    

  • 1025. Variably modified standard library types
    

    Myers: It is possible for implementations to have their own extended types. Given these conforming extensions. Such extensions can be used to define standard library types.
    Ballman: The changes are fine, but this raised a different question: Can implementations add attributes to the types being described? Does a declaration of a function define the declaration of the type?
    Seacord: We had a paper on aliases. I have another word the functions and I can add an attribute to it.
    Myers: You can add an attribute to a type if that attribute is consistent with the semantics for the relevant type.
    Gustedt: I disagree, if you put an attribute on a header file saying this is reproducible. We haven't put function attributes on library functions, but I think this is a valid use of this feature.
    Action Item: Ballman: Write an issue about the whether it is acceptable for standard library implementations to add attributes to their declarations.
    Ballman: When we say "cannot be qualified" does that mean you cannot use nullability qualifiers?
    Colomar: No, just access qualifiers.
    Accepted suggestion correction with the existing "shall" fix.
    Moved to Review
    

  • 1026. thrd_t as an array type
    

    Gustedt: va_list can be an array type. Other standard types like thrd_t would be confusing if they were array types that decayed to pointer types. We should have a general fix for that.
    Colomar: Given the use of this type, it is impossible to be an array, since it is returned by functions.
    Action Item: Myers: Write general wording that excludes all the static library types from being arrays unless explicitly stated otherwise.
    

Afternoon break

• Myers, C23 issue log, r5 [N3910] (1.5 hours)
  
  • 1027. Member declaration attributes and composite types
    

    Krause: Even attributes cannot change the semantics, is that correct?
    Ballman: It depends on who you ask. For the standard type attributes, ignoring them is fine, but for other attributes anything goes.
    Myers: This is about declaration attributes.
    Uecker: What do we do for function parameters?
    Ballman: Declaration attributes on function parameters are still declaration attributes.
    Gustedt: This question is relatively trivial. They are the same type if you take out the attribute. This must be valid code.
    Ballman: So it is observable which type is canonical.
    Colomar: I would take the most restricted option. That makes sense for implementations that ignore the attributes, but what about the other implementations?
    Colomar: I would say they are compatible types, but not the same type.
    Ballman: I expect people who declare the exact same thing in multiple places.
    Colomar: This is like comparing a null pointer to an empty string, they are not equivalent. This next one is implementation-defined.
    Seacord: If everything involves standard attributes, we should have behavior and we do not.
    Celeste: If both variables have a deprecated attribute with different messages, I would expect to get both messages from the compiler.
    Banham: If an attribute has a significant effect on two implementations, then any should be diagnosed. If the attribute has no impact, it could be permissible.
    Seacord: When I see re-declarations, that looks like a mistake. I felt the committee allowed this because there were so many re-declarations. I would therefore go with what Ballman did with Clang.
    Myers: It was deliberately added to structs in C23.
    Ballman: The cure is worse than the disease. This is much more of a practical problem.
    Seacord: Could we broad-brush this by declaring such behavior to be implementation-defined?
    Myers: Could Uecker deal with this issue as part of his "same-type" paper?
    Ballman: I will help as I am interested in the problem.
    Action Item: Uecker: Address Issue 1024 in his "same types" paper.
    

  • 1028. jmp_buf as an incomplete array type
    

    Myers: This is a complete array type, just one word to add. We should move this to review with my suggested wording.
    Banham: "The type declared is" appears again in 7.16.1 for va_list, and that says "…which is a complete object type…".
    Bhakta: Can we do 1058 next?
    Myers: 1058 is a long issue; we do not have time to resolve it today.
    Moved to Review
    

  • 1029. Spelling of LINE
    

    Ballman: The answer to Question 1 is LINE file should be valid. For question 2 I do not know of any.
    Gustedt: I think we discussed this when we discussed decimals. I do not remember why we did not fix it more precisely.
    Ballman: I prefer no digit separators for the same reason we want this to be a decimal.
    Colomar: Do we really need to care about the difference in type?
    Myers: We do not want suffixes.
    Ballman: I think a basic explanation is that #line LINE would work.
    Gustedt: For the line feature itself, there is an easy cure: The user can define a macro that uses line and concatenate with "ll" everywhere he wants to print it.
    Banham: For subclause 6.101.6, it seems implicit that it talking about some number, but does not actually say that. We should be saying that LINE produces a decimal number. Then it will work with the #line directive, which is a digit sequence.
    Myers: Change it from saying "integer" to " a decimal literal".
    Gustedt: It should have the same text as the wording for #line.
    Colomar: I have a different approach: We have "digit sequence"; we can change it to be more strict, and then refer to that thing in LINE.
    Ballman: C++'s wording for this is: "The integer literal 0 or a decimal integer literal, with no digit separators and no integer-suffix, representing the presumed line number of the current source line within the current source file."
    Action Item: Myers: Figure out wording for Issue 1029.
    

  • 1032. errno as a bit-field
    

    Krause: Do we want to encourage taking the address of errno?
    Liber: This breaks in C++, you can pass it by reference to something that takes its address
    Celeste: We should not encourage anything for errno besides reading it and assign its value.
    Bhakta: If we strike everything after "thread-storage duration", I think that resolves the issue and leaves the address-of bit open.
    Action Item: Myers: Provide suitable wording for Issue 1032.
    

Friday, 21 August

• Colomar, Add operator _Typeas [N3634] (0.5 hours)
  

  Bhakta: I do not see a benefit that outweighs the cost of a new keyword in C. Do you have motivation to make the cost worth it? Is there implementation experience as a keyword?
  Colomar: We have prior art, but not for this specific operator.
  Celeste: It took me a long time to understand this; the name is easy to change. Prior art is easily satisfied by typeof(). I think this is worth adding. It is not type-checking, it is entity checking.
  Krause: It is better to put the burden on the compiler. This is a feature, somewhat useful, and can be implemented as a macro.
  Myers: I am dubious that this is sufficiently useful. I agree _Typeas is a bad name, but it should definitely be a keyword not a macro.
  Gustedt: I prefer a macro. I do not know if it is as useful for everybody.
  Ballman: I am not convinced that this solves enough of the problem to go in. Every user will wonder why they should use this rather than typeof().
  Uecker: I understand the use case. I prefer a keyword. It is about type-generic macro programming. It may be a little too early to add this.
  Bazley: I support this idea. Maybe calling it "_asType" instead of "_Typeas". Providing the right tool does not ensure people will use it.
  Colomar: This feature cannot be misused, so I do not see any danger.
  Ballman: You keep claiming that typeof() is dangerous; are there any CVE's based on typeof()? Are these just concerns from the Linux kernel community?
  Straw Poll: Would WG14 like something along the lines of N3634, disregarding the name and the keyword vs. macro argument? 1-0-5+3-8-7=4-8-12 strong direction against
  

• Colomar, disallow function parameters of function type [N3932] (0.5 hours)
  

  Jabot: I looked on GitHub for functions used in parameters. They are used in the Linux kernel. This would be more of a breaking change.
  Colomar: Bazley found exactly one use case.
  Ballman: I posted some links that I saw would break: things like CFS and CPython. Why would we break user code when it works?
  Colomar: Well-maintained projects would just adapt.
  Ballman: One of WG14's principles is to not break existing code.
  Krause: I see Colomar's point in that this is not a necessary feature and is confusing. But it is real C now. We could make it obsolescent or deprecated, and remove it later. We should not remove it unless there is a good reason to, and I do not see it now.
  Colomar: I could write a paper obsolescing it, and removing it in ten years.
  Bazley: I still do not support this. Is there a syntactic restriction, or does it also apply to function types that have been given a name using typedef?
  Colomar: Yes, you would have to use a pointer type.
  Myers: I do not think there are actual real problems with this syntax to justify removing it. This version is worse than the previous version of this paper.
  Gustedt: There is no danger in this feature. We should give better reasons for people to change their code. This feature is symmetric with arrays.
  Colomar: I do not think it is symmetric.
  Serebrennikov: The pointers adapted to changes like K&R function operations. It falls on the shoulders of Linux distribution maintainers to maintain a pile of C code, and we should not create work for them for no good reason.
  Rice-Leech: Is this foundational for some followup paper?
  Colomar: It is not strictly necessary, which this change simplifies, but does not require this.
  Adams: This paper suggests removing this. We could make an issue to deprecate it.
  Colomar: I do not think we are promoting it. But we should remove those examples from the standard that we would not add from scratch.
  Straw Poll: Would WG14 like to change the examples from the standard to use regular notation, along the lines of N3932? 1-3-3+2-10-4=3-13-7 strong direction against
  

• Gustedt, Interfaces with contracts alongside Annex K [N3930]
  

  Jabot: We did in C++26 hardened preconditions in the standard library. You can implement most of these as a set of macros. If you want to do that in C, you cannot need a contract implementation. That is something you should explore.
  Gustedt: If you look at the sources, there is a translation of all of this into existing C.
  Myers: Most of the interesting properties are things you cannot fully check. Things done by GCC's FORTIFY_SOURCE and builtin_object_size. I would like to see discussion of that prior art.
  Banham: This is similar to the fortified checks. We need to distinguish compile-time checks from runtime checking.
  Bazley: It was maybe unwise to use Annex K, as it is unpopular with many people, including me. Adding a size_t parameter to a function makes it a calculation failure. I like contracts, but this is not a good example of them. Functions were a terrible encapsulation failure in the first place.
  Gustedt: I am not a fan of Annex K. I am trying to rescue part of the effort, where people identified problems with interfaces we have in the C library. These things are put into the interface and made explicit as a function call has to verify. In some places we can do better than Annex K, if you are interested at improving the standard library. In many cases it is the best we have. The rest is done by the static array parameter thing.
  De Abreu: Checks at runtime for FORTIFY_SOURCE were one of the core requirements of the feature.
  Liber: I do not know if there is a benefit to putting post-conditions into the standard lib.
  Uecker: I like the paper for providing interesting examples for contacts. You have this precondition on normal parameters, but that is already provided by static. Why?
  Gustedt: It is sort of redundant, but you do not know in what context your code falls.
  Seacord: If we have this in C2y, do we do anything with subclause 7 functions or Annex K functions?
  Gustedt: That is a good question, but for after C2y.
  Colomar: This paper claims that standard strncpy_s() supports the copy of zero bytes.
  Gustedt: Yes, strncpy_s() is ill-advised because it has different semantics than strncpy().
  Ballman: Thank you, Gustedt, for investigating this. A failure in the post-condition indicates a library error, not a user error, right?
  Gustedt: Right!
  Ballman: Is there any possibility to check for that condition, and does that cause performance concerns?
  Gustedt: The post conditions are assumed by the caller.
  

• Myers, C23 issue log, r5 [N3910] (1.5 hours)
  
  • 1030. Lvalue conversion for generic associations
    

    Ballman: All three things should be valid.
    Celeste: I think these should be allowed.
    Gustedt: I agree. This is also related to "discarded".
    Uecker: My mental model about _Generic is that it replaces the expression at a superficial level, and then what happens happens after the replacement.
    Action Item: Myers: Provide wording for Issue 1030.
    

  • 1031. Generic selection controlling expression lvalue of incomplete non-array type
    

    Celeste: I have an implementation-driven instinctive response.
    Ballman: It is not formally lvalue conversion. I think is a constraint violation in C2y unless the controlling operand is a type operand.
    Meneide: Could this be solved by saying we have an "lvalue type converter" which applies to the type rather than the object?
    Ballman: Meneide, what is the use case for allowing it on the expression form? Or is just for making the specification easier?
    Meneide: Yes, easier.
    Celeste: Things like the type operand make _Generic simpler. The type is as if no lvalue conversion occurs.
    Action Item: Meneide: Provide wording for Issue 1031.
    

  • 1033. FILE as a void type
    

    Banham: I always imagined FILE to be a struct or pointer.
    Celeste: If file can be void, then a FILE* cannot be distinguished from some other void*.
    Colomar: We could use "heterogeneous types" to refer to structs and unions.
    Meneide: We have "structure types" which sometimes refers to all structs and sometimes refers to structs and unions.
    Bazley: The real issue is: is FILE a unique type or not? What the committee cares about is: can this be uniquely identified as a file-handle?
    Bhakta: I did not like the directions as void. This is not a problem in practice. I would not like this to be "just structure types". No one is getting this wrong.
    Gustedt: I propose that it say we will not change the text. Changing the text requires a new paper.
    Straw Poll: Would the committee prefer some unspecified fix to Issue 1033? 0-5-0+3-8-2=3-13-2 clear direction
    Moved to Review, saying no changes needed
    

• Infrastructure Discussion
  

  Myers: With a suitable VPS host we can set up a better mailing list.
  Bhakta: Was there e C foundation thing for funding?
  Ballman: I did ask Seacord, and it seems like steam is slowing down on a foundation. Is there anyone affiliated with a university who can get some resources? That might be a potential.
  Myers: I am not convinced that hosting in a university is better than a company.
  Gustedt: 7 years ago when we started this discussion, we could use a public archive, which should remain forever. I do not think money should be a real concern. The main issue is finding somebody, doing the work, and having something set up to avoid a single point of failure..
  Uecker: A university could help. GWDG also has servers; they night do it for free for us. But I am not officially affiliated with them anymore. The maintenance is a much bigger problem.
  Myers: For external hosted services, we might be able to turn on Mailman, or the Mailman plugin interface. We haven't eliminated the need to run custom code.
  Seacord: With regard to privacy, I am not opposed to being more public. If emails are publicly accessible that invites the community in and grows the community. Beyond emails, having the papers public is something we want. If it is not forbidden by ISO, I lean towards transparency. The current policy of the reflector is that it is not restricted to ISO members.
  Ballman: Once you've gotten on to the mailing list, is everything you say public?.
  Uecker: I think we should have a private mailing list.
  Ballman: If it is public, people will have a different risk model for what they talk about.
  Seacord: I set up a private Mattermost server for chats, but it is still private. C++ uses Mattermost.
  Plakosh: These things are easy to say but harder to do. The SEI used to use our own hardware; now we do many things on AWS. I will talk to people at the SEI who could do this.
  Uecker: We would need a couple of people to take charge of this problem.
  Myers: I am happy to do the mailing list stuff.
  Seacord: Can we have the source code for the infrastructure in a Git repository?
  Myers: The code and data are already in our private Gitlab repositories. I've published the links.
  Ballman: WG21 has wg21.link where you can say WG21/link/paper-number. I own wg14.link, and will donate it to whoever does sysadmin stuff. It is nice in WG21, and I would like something similar to WG14. Cranmer also helped with setting it up.
  Myers: Ballot comments are inputs, requesting changes. They would be S-documents.
  Svoboda: Where would UBSG meeting minutes go?
  Myers: For regularly-recurring minutes we would set up a separate list, as we do for CFP. Sporadic ones can be S-documents.
  Plakosh: This is very complicated.
  Myers: The current system addresses these problems for any document: Is there a newer version, and what meeting was this discussed at?
  Banham: This is an impressive piece of work. On the document numbering, it needs to be a more consistent overall design. When looking at consolidated overall indices, you have the "revision" column. That makes the table hard to sort. Maybe the date column is what needs to be sort-able.
  Myers: Sorting by N-document number is not helpful because people get document numbers years before they publish the paper.
  Serebrennikov: The C++ paper tracker system on GitHub works well for subgroup chairs who have to prepare agendas. Each paper has a GitHub issue. They have labels for specific subgroups so chairs can just run a query for papers assigned to their group.
  Myers: C++ has lots of subgroups but C does not. It would be straightforward to query what docs have not been discussed in a meeting. Various people did not like doing things in GitHub. We need to restart the flagship discussion.
  

If time (be prepared to discuss)

Not yet scheduled

• N3876 Ballman, Design concerns with _Optional
  
• N3921 Jelinek, Arbitrary bit-precise varying argument access, stores and loads
  
• N3922 Jelinek, Remove some stdbit.h bit-precise integer restrictions
  
• N3792 Szewczyk, Variadic-argument introspection: VA_COUNT and VA_SLICE (0.5 hours)
  

Withdrawn

• Colomar, add strchrcnt(), strchrscnt(), wcschrcnt(), wcschrscnt() [N3664] (0.5 hours)
  
• Colomar, named arguments after varying arguments in macros [N3805] (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, [static] without array length expression [N3803] (0.5 hours)
  
• Colomar, add _Assert(), not depending on NDEBUG [N3760] (0.5 hours)
  
• Colomar, incompatible array parameters [N3901] (0.5 hours)
  
• Colomar, add stpsep(), wcpsep() [N3666 ] (0.5 hours)
  
• Colomar, C source files are text files [N3633] (0.25 hours)
  

8.1 Review of Decisions Reached

8.2 Review of Action Items

8.3 Re-approve Agenda