MEETING OF ISO/IEC JTC 1/SC 22/WG 14
WG14 / N3583
Dates and Times:
24 February, 2025 09:00 – 12:00 Lunch 13:30 – 16:30
25 February, 2025 09:00 – 12:00 Lunch 13:30 – 16:30
26 February, 2025 09:00 – 12:00 Lunch 13:30 – 16:30
27 February, 2025 09:00 – 12:00 Lunch 13:30 – 16:30
28 February, 2025 09:00 – 12:00
Graz University of Technology Biomedical Engineering Building, Stremayrgasse 16, 8010 Graz Austria
"Raw" notes are available at N3584.
Some questions about the correct official number for this meeting. ISO appears to miss some early meetings from its list.
Seacord: our time here is to ask and answer questions, not to present, hard-sell, or read out papers. There will be time for polls and questions will be cut off if necessary. We are flexible within reason.
Visitors attending from SC32WG3, the Linux Manpages project, and SEI.
| Name | Organization | WG14 Country| Notes |
|------------------+--------------------------------------+-------------+---------------------------|
| Aaron Bachmann | Efkon GmbH | Austria | Austria NB |
| Aaron Ballman | Intel | USA | |
| Alejandro Colomar| Linux | Spain | Spain NB |
| Alex Celeste | Perforce Software | USA | MISRA; Scribe |
| Andrew Banks | LDRA Ltd. | UK | MISRA Liaison |
| Ash Chronister | Apple | USA | |
| Chris Anley | NCC Group | USA | |
| Chris Bazley | Arm | UK | |
| Clive Pygott | LDRA Technology | USA | |
| Daniel Plakosh | SEI/CERT/CMU | USA | |
| Dave Banham | BlackBerry QNX | UK | MISRA Liaison |
| David Svoboda | SEI/CERT/CMU | USA | Undef. Behav. SG Chair |
| David Tarditi | Apple | USA | |
| Douglas Teeple | Plum Hall | USA | |
| Eskil Steenberg | Quel Solaar | Sweden | Sweden NB |
| Fred Tydeman | Keaton Consulting | USA | INCITS/C Vice Chair |
| Freek Wiedijk | Plum Hall | USA | |
| Glenn Coates | Real Time Embedded Ltd | UK | |
| Henry Kleynhans | Bloomberg | USA | |
| Jakub Lukasiewicz| Motorola Solutions Systems Polska | Poland | Poland NB |
| Jan Schultke | Boost Foundation (ANSI) | | |
| Jaroslaw Stanczyk| | | |
| Javier Mugica | Self | Spain | Spain guest |
| JeanHeyd Meneide | NEN | Netherlands | Neth. NB; C++ Comp. SG |
| Jens Gustedt | INRIA/ICube | France | France NB |
| Joseph Myers | Red Hat | UK | UK NB |
| Joshua Crammer | Intel | USA | |
| Leandro Melo | ABNT | Brazil | |
| Martin Uecker | Graz University of Technology | Austria | |
| Maryam Karampour | Aviar Inc. | Canada | Canada NB |
| Niall Douglas | Ireland ned Productions Ltd | Ireland | Ireland NB |
| Nick Stoughton | Self | USA | SC22 Austin Group Liaison |
| Peter Eisentrand | EDB | Germany | |
| Philipp Krause | SDCC | Germany | |
| Rajan Bhakta | IBM | USA, Canada | USA NB; INCITS/C Chair |
| Robin Rowe | Fountain Abode | USA | |
| Robert Seacord | Woven Planet North America Inc | USA | |
| Roberto Bagnara | BUGSENG | Italy | Italy NB, MISRA Liaison |
| Ryan Karl | SEI/CERT/CMU | USA | |
| Stephen Huemann | Self | USA | |
| Ted Johnson | Hewlett Packard Enterprise | USA | |
| Thiago Adams | ABNT | Brazil | Brazil NB |
| Yeoul Na | Apple | USA | |
|------------------+--------------------------------------+-------------+---------------------------|
Straw polls as usual, with one vote per attendee. Consensus will be defined and determined by Seacord, trying to stick to the model provided by Bazley and Bhakta, but able to use some discretion if needed.
No voting by national body.
Chat is available for use as a side-channel only, not for primary discussion.
The ISO Code of Conduct was presented without discussion.
The ISO guidance and process and the IEC Code of Conduct were presented. JTC1 N2613 was presented, summarizing the key points.
Ballman moves to approve N3372. Bachmann seconds. No objections.
Ballman to add N3286, N3322, N3305 to the list of papers of interest to maintainers of older versions (the "retcon list"). DONE.
Svoboda to resubmit the minutes for Summer 2024. DONE.
Bazley moves to approve N3430. Plakosh and Wiedijk second.
Bhakta raises an objection: do not change the agenda during the session.
Seacord: want the agenda to reflect the actual discussion i.e. papers moved around in the sequence. Bhakta: we can do that but we should approve the sent out agenda. Re-approve the "actual" at the end.
The "actual" agenda was made available as N3502.
There will be an SC22 meeting before Pittsburgh. No real news right now.
INCITS/C will meet in two weeks, attendance is mandatory. Three ballots are scheduled.
C++26 is roughly feature-complete. The pipeline may still contain some things that don't make it in. No profiles, no patterns, probably not reflection.
No report.
Banks: significant work has been done but the exact content is embargoed for now. (in reference to MISRA C:2025 and MISRA C Addendum 6, which were announced shortly after the meeting)
The MISRA/CERT mapping has been updated. The MISRA/CWE mapping is in progress. Guidance for how to tag compliance is now included.
MISRA is collaborating more widely with other groups, including MITRE.
Seacord: some progress was achieved last week w.r.t naming conventions for the C Standard. Right now there is no recommended action for WG14.
No report.
No report.
The changes to science funding in the US have effectively shut down the Enduring Security Framework. Documents can still be accessed on the archived websites.
BSI is in the middle of a move.
Some comments provided in Reflector message 28105.
We get defect reports about TR 18037 (Embedded C) but have no way to maintain it. Does the CFP cover fixed-point math? Could this be folded into C2Y?
The CFP group has no expertise w.r.t this, so there's no benefit to CFP doing it. A visitor from LLVM wanted to add imaginary types, which were just removed, as well as work on the TR. Bhakta and Bazley may have individual expertise.
No QAC user has ever expressed interest in this. IBM implemented it, but not following the TR. SDCC has architectural support, but users prefer to use third-party libraries rather than built-in compiler support. Some old projects still in service use fixpoints for determinism.
The TR is considered obsolete.
WG14 appreciates CFP's hard work.
The TS is published! Thanks to all reviewers.
Gustedt: The SG has not met recently and prefers to disband.
Wiedijk: MoM is still a mess in C and clarifying it - not adding new features - is still useful. Will chair if needed.
Jens will continue to participate but not chair. Others may be interested.
Kleynhans: the original documents were very math-heavy - can we publish that content as a whitepaper so it isn't lost?
Seacord: yes. No rules about this.
The TS is intended to capture the math but expressed in English. The TS was intended for merging into the IS. The Committee retains the option to merge it if experience is positive. The TS provides a stable point for implementations to refer to. LLVM and Intel have started but not finished implementing TS 6010. Whether this can be completed without affecting existing users remains to be seen.
The floating point TS is a good example of content being merged back into the IS. Annex K was a failed example.
If there is no implementer feedback, especially from LLVM, this effort will probably have failed.
Nina Dinka Ranns has been running the SG, which is working well.
Should there be a corresponding group liaising CFP and SG6-Numerics? CFP is open to it.
The Examples of Undefined Behavior document N3453 has been published for review. A series of Earthly Demons papers will be seen this meeting. The Educational document is not currently on the agenda; work continues and it is likely to be published as a whitepaper rather than a TR.
(deferred, author unavailable)
Published but retired; WG14 is now responsible for it.
Since we have no mechanism to repair, we should identify the parts still of value and pull them into the IS.
Bhakta: we have named address spaces, but don't follow the TR.
Krause: we follow the TR for intrinsic address spaces but not user-defined ones.
Consensus that the functionality is wanted and some of it is implemented, but that there is absolutely no implementation compatibility. This functionality could be put in an Annex or as an optional feature described in the main text of the IS. The TS served its purpose of gathering information; the result is that the current text does not reflect praxis.
Seacord: would anyone work on pursuing this? (tentative support from 4-5 people)
An issue tracking system is wanted.
It is possible to share the WG21 infrastructure but the cost would be non-zero. There are unresolved licensing questions about the WG21 P-document system. In practice everything goes through GitHub now. The WG21 infrastructure is open source although not all of it may have been made public.
Myers has a working issue tracker and paper tracker, based on Meneide's original design of "everything represented in a Git repository".
Straw poll (opinion): Would WG14 like to adopt Myers's issue tracking system?
17 / 0 / 4 (approval)
Myers to discuss further with Keld about hosting the issue tracker.
The venue and meeting were introduced by Plakosh.
NOTE however that this meeting was subsequently cancelled due to the group's concerns about required travel to the United States.
The group thanks Plakosh and Carnegie Mellon for making the venue available.
NOTE not discussed in the session details of the replacement meeting were made available in N3541, to take place in Brno, Czechia.
The replacement meeting will run from 2025-08-25 to 2025-08-29 and the updated mailing deadline is 2025-07-25.
Potential future venues were proposed, including Bangkok, Bracknell, Nijmegen, Strasbourg, Valencia, and more use of virtual meetings. It is possible (but not "free") to schedule more short meetings with fixed agendas, and was noted that many tasks currently handled in session can actually be taken offline, especially so that the number of papers turned over with minor changes is reduced.
It was noted that hosts should be mindful of financial constraints, as not all members may have expenses covered, and offers for in-person meetings should prefer the off-season where possible.
The Pittsburgh meeting was cancelled and the mailing deadline no longer applies.
The pre-Brno mailing deadline is 2025-07-25.
DTS-18661-4: GB-001 and GB-002 are editorial, CFP approves.
WG14 approves by unanimous consent.
DTS-18661-5: non-editorial but non-technical, unintentional text changes.
The editor has agreed this was a mistake and only affects the example.
WG14 approves by unanimous consent.
DTS-6010: author recommends accepting all four comments, three editorial.
WG14 approves GB-001, GB-002 and GB-003 by unanimous consent.
WG14 observed FR-004 which does not recomment any action.
All changes have been applied by the editors.
N3363 stdarg.h wording... v3
Previously seen as N3359. The word "variadic" has been added to the working draft and can now be used by this paper.
The paper makes many line-item changes and was hard for some readers to understand correctly.
Straw poll (decision): Does WG14 want to adopt N3363 into C2Y, restoring footnote 292?
24 / 0 / 3
Originally a C++ feature to be added by UDL. There are much more substantial benefits in C++ because of type deduction, overloads, etc., but literal compatibility is good.
Prefer to name the type directly. Does this solve a real problem for C users? The implementation burden is almost zero though. May be useful for generic dispatch. Storing a literal is usually harmless but conversions apply in operator expressions and may be unexpected without the ability to be explicit.
Some formatting errors, all fixed in the revision.
MISRA would appreciate this, composes well with Essential Types.
Straw poll (opinion): Would WG14 like something along the lines of N3485 in C2Y?
15 / 3 / 11 (direction to continue)
N3472 auto as a placeholder type specifier, v2
This has been seen several times and illustrates the case for a wording SG.
This should be ordered w.r.t N3427 to avoid wording clashes. Either can be adopted first.
The deduction of array sizes is not a C++ feature because C++ has initializer_list. Happy to
diverge over this since the feature does not exist in C. C++ doesn't deduce arrays in this way.
Straw poll (opinion): Would WG14 like something along the lines of N3472 in C2Y?
18 / 0 / 6 (clear direction)
Straw poll (opinion): Would WG14 like array inference to always require [] in the declaration?
17 / 1 / 8 (clear direction)
(i.e. WG14 would not like to allow array derivations to be deduced that are not signaled by array declarator syntax)
N3484 Slay Some Earthly Demons V (update v3)
This turns compatible type issues from undefined behaviors into Constraint violations. Some "shall" are moved out of Semantics and become part of definitions instead. There are non non-UB code changes, and this does not impact UBs that are truly usable.
Straw poll (decision): Does WG14 want to adopt N3484 as-is into C2Y?
25 / 0 / 7
The editors should not add this change before the next meeting, giving time for objections. This is not a change worth adding to the retcon list.
Noted that the "Earthly Demons" title series may be confusing to some newcomers.
N3459 Integer and arithmetic constant expressions, v2
Mostly this changes the claim that the "result" of an expression is itself any category of expression rather than a value.
alignof does not change because the result is never dynamic even when the operand is a VMT.
Straw poll (decision): Does WG14 want to adopt the first change from N3459 into C2Y?
20 / 0 / 7
The second change is just a simplification of wording.
Straw poll (decision): Does WG14 want to adopt the second change from N3459 into C2Y?
14 / 0 / 12
High abstentions due to not fully understanding the intent of the diff. Future papers requested to have clearer diffmarks.
N3503 Integer and arithmetic constant expressions, v3
(continues the same topic as version 3 of the proposal)
Objection to the late submission. The differences from the V2 are very minor.
N3464 "Discarded", and its update N3504, will handle aspects of this better.
No poll on change 3.
N3377 Named Loops Should Name Their Loops: An Alternative Syntax for N3355
Addresses the scope issue with existing change. Removes the implied meaning of a label as a jump target, intentionally, for readability. Not tied to this syntax.
Discussion of how important avoiding goto really is. Prefer not to pitch for avoiding features that exist.
Clarified that shadowing is intended to apply in this model.
Several voices in support for not using label syntax. The counterproposal to continue using N3355 syntax
has been brought to WG21 in Hagenberg and met with tentative approval. This model would also allow
putting the loop name in some of the "preferred" other positions discussed before. Noted that this
breaks widespread precedent, has some composability and ergonomic issues, doesn't work well with macros.
WG21 has strong support for the semantic feature regardless of what it looks like. "Context-sensitive
keywords" in C++ have not generally been considered a good design. Noted that although other languages
use label syntax that is usually visually distinct from goto labels if they exist at all.
This introduces novel syntax that may confuse readers and syntax highlighters.
Labels describing a "happens-before" relationship are common in assembly but misleading. Labels used
for naming things is intuitive. Does not change the need to search for the jump target of break
or continue.
Noted that Rust allows breaking any block, not just loops. Forcing visual distinction between loop
names and goto targets can be left up to style guides.
Subjective opinions about which syntax is confusing and whether that's just familiarity.
Straw poll (opinion): Would WG14 like to see a paper changing the syntax for loop names at a future meeting?
6 / 11 / 9 (no direction)
N3493 Array subscripting without decay v6
Objection to the late submission. Only terminology changes since N3380.
Aim to split pointer and array subscript operators. index[array] is deprecated but not removed for the
moment. Discussion of proper formulation for ordinals and whether the wording is clear.
The new constraint against negative indices was always UB and applies based on the operand type, not the storage. Negative indexing remains OK for pointer-typed operands, in particular for parameters declared with a syntactic array type, and is widely used in practice.
Straw poll (decision): Does WG14 want to conditionally adopt N3493 into C2Y, subject to any editorial changes?
11 / 6 / 8 (not adequate consensus)
After a homework update the text makes it clearer that zero-indexing is used. Whatever form the text uses should be consistent.
N3464 Discarded-III
Updates N3382. Relies on some extended definitions of "not evaluated". Introducing the idea that types "resolve" while expressions "evaluate" to distinguish the context; "discarded" can't map to "not evaluated" because of arrays. Only operator-based for now.
Adoption delayed pending objections. Wording not clear enough for the group.
Straw poll (opinion): Would WG14 like something along the lines of N3504 in C2Y?
12 / 0 / 11
N3465 Preprocessing integer expressions
Potential risk of breaking user code. Would this forbid builtins in the preprocessor? Seems to be a theoretical problem. Clarify that this comes after all macro replacement.
Straw poll (decision): Does WG14 want to adopt N3465 into C2Y?
10 / 2 / 12
High abstentions from implementers who don't feel strongly either way. Considered consensus.
N3473 if declarations, v5, wording improvements
Preference to retain the Constraint against a storage class for now. C++ has an equivalent rule, even though the rationale isn't known to this group.
Straw poll (opinion): Would WG14 like to retain the current Constraints for if-declarations?
9 / 7 / 12
Not consensus to make any change.
N3390 Remove the imaginary I
Sentiment to remove completely. The suffix in the examples should be fi not i.
Is it still UB for the user to define it? Yes, if they give it linkage.
There should be an example of defining I as _Complex_I.
Straw poll (opinion): Would WG14 like to remove the macro I and add an example of it defined as _Complex_I?
17 / 1 / 9
N3432 Composite types
See also N3397 for background. Originates from the "size" vs "length" debate. Since any non-VLA has a fixed size, this can eliminate an undefined behavior. Adding rules clarifies the fallthrough.
Discussion of the exact wording and whether this changes any resolved types. Examples need work. Discussion of how not all cases can be resolved statically.
Straw poll (opinion): Would WG14 like to replace the undefined behavior identified in N3432 with a constraint?
20 / 3 / 4
The wording on UB needs more work.
N3495 Clarify syntactic terms for array declarators v3
No normative changes since N3414, only clarified diffmarks. None of the normative changes should affect real behavior, only accurate terminology. Referring to assignment-expression in this text is confusing, makes declarators look like expressions. A syntax rule rename for clarity would be more useful to the reader. Use font choice to clarify when grammar production names are meant.
Straw poll (opinion): Would WG14 like something along the lines of N3495 in C2Y?
22 / 0 / 6
N3332 Record types
Solves a problem left over from C23 w.r.t tag compatibility, which was unfinished and left C without fully generic structures or algebraic types. Wording is not yet ready to integrate.
Can this introduce unintentional compatibilities? Semantics should come from types, which are erased here. This ensures that types that are intended to be the same are recognized as such. It is intentionally opt-in only, communicating that intent. The keyword is additive and not another third kind of taggregate. Will people misuse it to make wrong code quietly compile?
Discussed whether better without the addition to the grammar; removes opt-in nature, general dislike from group that that erases types. Concern that this may not scale. Useful for types like vectors and graphics types. People already do this in practice and just cast.
Discussion of whether a non-ignorable attribute could be used. C++ tried this and it did not
work, [[no_unique_address]] broke existing code. A keyword is allowed to do that and
doesn't fork dialects, forcing implementations to be compatible.
No poll.
N3451 Initialization of anonymous structures and unions (v2)
Standardizes existing practice. Needs a direction for which way to resolve it. Not fixed by N2038 which treats unnamed members as excluded. The existing wording dates to C99 and would not have been intended to apply to structures.
SDCC would not be broken by this. Clang and GCC would have to change existing behavior.
The intent is to match existing practice, but the proposed wording doesn't do that.
Good change which would improve portability.
Straw poll (decision): Does WG14 want to adopt N3451 into C2Y?
21 / 1 / 9
N3409 Slay Some Earthly Demons X
Addresses "void expressions".
extern void x; is somehow well-defined?
Straw poll (decision): Does WG14 want to adopt N3409 into C2Y?
22 / 0 / 4
N2698 Enabling Generic Functions and Parametric Types
Dissatisfied with both macros and with void *.
The principal difference from void-which-binds is that this proposal requires monomorphization.
The overall goal remains type safety. Integration with structures is slightly better.
_Any can be a value type as well as a pointer type in this proposal because of monomorphization.
"Pending requests" use a different model from C++ instantiation, and do not need two-phase lookup, so clearer to the reader what code means. The iterated substitution model is complicated for the implementation though. It is still possible to write expressions that do not instantiate correctly, e.g. dereference of a member that does not exist, like in C++. A prototype is available.
Compatibility applies to the monomorphized program, not the polymorphic code.
Clarify that this does therefore require code cloning. Discussion of how this differs from
Gustedt's generic lambdas. Uecker's _Any is unrelated despite the similar name.
How to require that two items have "the same" type? Needs C++-like unification. Could add a way to express this relation to the syntax, currently missing.
N3499 Reproducible expressions v3
Side effects inside a VMT are "usually" an error. Would be unfriendly to make them UB. A new expression category can syntactically ban things like function calls. Another case where grammar renames would help reader clarity.
In practice the side effect occurs frequently in real code. Debug info is the common use case. Debugging does tend to involve UB though. Is this always used intentionally in a way that cannot be hoisted? May be less clear, cause off-by-one errors.
May be better to promise a guarantee if a requirement is met rather than to ban code that does not meet the requirement.
Straw poll (opinion): Would WG14 like something along the lines of N3499 in C2Y?
9 / 3 / 11
N3498 Objects of known constant size v3
No intended semantic change, all normative changes are for clarity.
It is possible for an object to both be a VLA and have a known constant size. Does this imply anything? Would they be allowed in structs?
Author will refine wording. No poll, no opposition.
N3394 Forward Declaration of Parameters v4
This proposal is similar to the GCC feature. The group had different preferences for the specific syntax.
Apple objects because they already implemented full bounds-safety extension, and would prefer a more general solution than this which does not apply to return types, members, or other contexts. Forward-declaration is inherently error-prone.
No rush to approve this now. Apple would prefer to wait. IBM wants to make forward progress.
Previously group preferred not to allow forward-references, but implementation experience provides new information.
Are the different approaches incompatible? Consensus to avoid many ways to do one thing.
N3433 Alternative syntax for forward declaration of parameters
Aims to address the concerns with the previous proposal. Prefer for syntax to follow semantics, not vice versa. Do not want to add declarations for different kinds of things. Semicolons have parsing and readability issues.
Discussion of the implications of semicolons for reducing the risk; redeclarations and compatibility of redeclarations. Can the list be empty?
This does solve the issue created in C23. Neither form is compatible with C++, but both can be hidden by a macro. Has anyone asked C++?
Why not just swap the order? Is this really useful?
Allows stability of ABI.
Straw poll (opinion): Does WG14 prefer N3433 ("Chris's version") to N3394 ("Martin's version")?
15 / 3 / 11
N3395 Memory Safety: Unsafe Buffer Usage
Builds on the static and dynamic memory safety modes introduced by N3211. Pragmas are more useful for describing regions, while attributes describe whole blocks. Seeking feedback on the forms.
Is doing nothing a valid implementation of a trap, if a trap is undefined behavior?
Is it valid for external declarations to exist in different pragma regions? Could add a Constraint.
GCC has some prior art, but this is the opposite way around from bounds-safety-extensions. Not yet guided by experience. The two approaches can feed into each other if better bounds checking means more constructs can exist in safe regions.
Should this be applied by compiler switches at the TU level instead? Combine with the optimization level. Could simplify the rules, make safe functions unable to call unsafe ones. Would like an overview of existing approaches and how much needs to be changed; Checked-C uses pragmas. May need an SG.
Something along these lines is an extremely popular user-requested feature. This isn't full bounds checking but would enable it to be built on top. Does not exclude the bounds-safety-extensions but will not work with existing code.
Annex L should probably be removed to make room for this as it is unfinished.
A way to reason that code cannot trap is essential as most languages with this need to insert runtime checks otherwise.
Agreement that this is a widely-requested feature.
N3426 Improved Type Safety for Null Pointer Constants, v2
nullptr is incomplete as long as conversion from 0 exists. A YouTube video showing Community
surprise and disappointment at the incomplete state of the feature was shown. Two part proposal
to make NULL typed, and to obsolete 0 as a valid null pointer constant.
Concerns that compilers do not treat Constraint violations as errors already so just
obsolescence may do less than nothing. Opposing concern that the more radical approach may
cause C99-like lack of adoption and a soft-fork. Sweeping changes to user codebases are
a serious risk of introducing bugs, and diagnostic in -pedantic or equivalent modes
will break many users. Implementer experience is that adding such Constraints causes
code to keep breaking for a long time and will cause a soft-fork by emitting false positive
warnings against existing code.
Multiple implementer comments to the effect that they would be forced to be nonconforming over this.
The impact on existing code needs to be understood.
Straw poll (opinion): Would WG14 like to define NULL as a macro expanding to an expression with type void *?
9 / 6 / 7 (not considered clear direction)
Straw poll (opinion): Would WG14 like to disallow NULL from expanding to an expression with integer type?
15 / 2 / 7 (clear direction)
N3398 The Containerof Macro
A widely used API that relies on implementation magic, therefore a good candidate for Standardization. There are some known issues with the proposed wording. Linux has a different spelling.
More examples wanted for what kind of subobjects this can find, how qualifiers are handled. Strong support for putting into the Standard, which will mean that however it works, it is definitively no longer UB, any casts used internally are known to be correct for the implementation.
This is similar to a downcast. There is varying QoI in the wild. Some level of UB is implied by
this feature for the same reason because the operand is dynamic. Better behavior can be
guaranteed if the _Ugly keyword is added for the compiler to check. Otherwise, it is a
new undefined behavior distinct from offsetof. Sentiment prefers a keyword.
Straw poll (opinion): Would WG14 like something along the lines of N3398 in C2Y?
20 / 0 / 5
(no poll for the keyword vs. macro at this time)
Adding a language feature adds implementation burden. We should also consider making offsetof
a core language feature at the same time for symmetry, or keeping this a library feature for
the same reason; there is no known portability issue with a macro.
The UB cannot be eliminated as long as the type parameter allows the pointer parameter to
have void * type and potentially point to an invalid object.
N3422 _Optional: a type qualifier to indicate pointer nullability (v2)
Revision of the proposal from Strasbourg. Some misconceptions addressed and slides submitted.
A working implementation is up on Compiler Explorer and new directions have been added to the
proposal including analogies to user-understood features like const.
Now seeking guidance for progression rather than more debate about whether this is a good idea.
Could this be overused? What are the risks of false positives and negatives? This is not worse than the status quo with regard to UB.
The use of a qualifier over an ignorable attribute is intentional.
User experience with Clang resulted in repeatedly having to explain why the qualifier is where
it is, which indicates a UX design problem. Internal studies at Google suggest that neither
_Optional nor _Mandatory are easy to apply incrementally. Some calls for a TS to gather
experience.
Straw poll (opinion): Would WG14 support the syntax and semantics described in N3422 to be presented in a TS?
12 / 6 / 7
Four indicative voices of support from National Body members. At least one No vote was to indicate support for direct adoption into the IS.
N3471 Reducing undefined behavior for printf-style functions v2
There is an "embarrassing" UB in printf if a specifier results in too many characters.
Minimal change to praxis expected. Since not all long double values fit in this many digits,
it should not be UB to print them. Not expected to be a serious implementation burden.
In general the UB is not needed here for "reasonable" usages.
There is a format vulnerability in the use of signed here, but negative values are used for errors.
Possible to saturate at INT_MAX instead.
SDCC would struggle with some of the increased limits but they are only needed for correct rounding anyway. Possible that this doesn't actually help anyone become conforming if they aren't already. The macro can change spelling but should be there for users to query.
Straw poll (opinion): Would WG14 like a limit macro along the lines of the one expressed in N3471?
13 / 3 / 8
Straw poll (opinion): Would WG14 like to increase the limit value from 4096 along the lines of N3471?
6 / 7 / 11 (direction against)
The proposal will be amended to make this implementation-defined.
N3466 Clarifications on null pointers in the library
Clarifying wording in response to implementation questions, with regard to which arguments can be null. This is not worse than before with regard to static analyses. It is conditionally valid on passing zero; however, this can't be expressed as a static constraint.
Straw poll (decision): Does WG14 want to adopt N3466 into C2Y?
14 / 1 / 6
N3410 Slay Some Earthly Demons XI
Not aware of any possible use cases for the undefined behavior this removes. Widely rejected by tools.
Straw poll (decision): Does WG14 want to adopt N3410 into C2Y?
20 / 0 / 1
N3411 Slay Some Earthly Demons XII
This is a real UB, to some disbelief. N3477 updates this with a Constraint to replace the deleted UB.
This shows up in machine-generated code and has to be diagnosed. It is not a 70s thing and is still relevant to "record-based" files which remain in use. The original authors probably intended for this to be an error, but opposition to adding a Constraint for things which are not real errors.
Straw poll (decision): Does WG14 want to adopt N3411 into C2Y?
20 / 2 / 3
NOTE N3411 was voted for, not N3477.
N3478 Slay Some Earthly Demons XIII
This updates N3412. No objection to including the update.
This fixes what seems to be a non-issue as there are no partial preprocessing tokens and therefore they do not need a Constraint.
If the syntax doesn't allow a line comment on the last line (without a newline), we should change the syntax to permit it, as this is "obviously" not intended to fail. Commonly produced by automatic code generation.
Straw poll (decision): Does WG14 want to adopt N3478 into C2Y?
23 / 0 / 1
N3418 Slay Some Earthly Demons XIV
The existence of an undefined behavior allows divergence between GCC and Clang. Promoting this to a Constraint would resolve the divergence.
The example link is not considered a valid example.
This will not result in a diagnostic from the output of a standalone preprocessor simply because the compiler cannot generally recognize what is produced in earlier phases if it is a separate binary. Does not appear to cause preprocessor divergence. Possible existing difference between C and C++.
Straw poll (decision): Does WG14 want to adopt N3418 into C2Y?
20 / 1 / 3
N3480 Slay Some Earthly Demons XV
Updates N3419.
Although this is an extension point the other declarable types should be implementation-defined, therefore not undefined. Possibly all explicit extension points should gain a new category distinct from UB in general.
In practice the "or no definition" extension point is widely used on Windows. Unclear if this is intended by the proposed wording. POSIX uses another form that implementation-defined would require it to document.
This is widely used and the proposal seems to ignore praxis. New paper needed to clarify the intent.
No poll.
N3481 Slay Some Earthly Demons XVI
Updates N3420.
Minimal change, making the undefined behavior into a Constraint violation. Appears to be an unused extension point.
Should this add a Constraint where one wasn't before? Keeping related things together is clearer and there is no normative difference because of where the Constraint appears.
Straw poll (decision): Does WG14 want to adopt N3481 as-is into C2Y?
14 / 0 / 7
However, the editor is requested to remove the double-negative wording.
N3482 Slay Some Earthly Demons XVII
Updates N3421.
This undefined behavior should be safe to delete because it only applies in the case of a Constraint violation anyway. Possibly referred to pre-Standard mechanisms for implementing variadics (vararg.h).
The difference between Ia and Ib is only in where to add the requirement. It is not a Constraint with the current structure.
Straw poll (decision): Does WG14 want to adopt N3482 into C2Y, without the additional changes?
18 / 0 / 6
N3496 Clarify the specification of the width macros v2
Resolves a misunderstanding on the part of the tool vendors and clarifies where to look up the relevant definition. Requested by Clang.
Width and precision are only different for signed types and this change takes them into account.
Straw poll (decision): Does WG14 want to adopt N3496 into C2Y?
20 / 0 / 4
Editor to replace "shall be" with "are" in the affected locations when integrating this.
N3329 Transparent Aliases, r4
Discussion only. Consensus was lost in Strasbourg; this addresses some issues raised at that time. This entirely follows existing praxis and there is no runtime aspect to this.
Understanding how this is useful over and above a macro name if this doesn't work at the linker level: in existing practice, the name declared by an external declaration doesn't have to correlate to the generated linker name.
The ability to redeclare Library APIs is what prevents this from being solved with macros; if the header was always required to be included, we might not need this. However, this solution allows proper scoping and shadowing and doesn't trample properly-declared identifiers, while it does solve the problem of being able to leave old code unmodified.
This solves a real problem that is not limited to the Standard Library; a portable notion of
linker labels is useful in general. This only captures part of what asm does, but all
linkers can implement it. This does not copy the "stringly typed" practice of mangling with
additional symbols like @, so there is no dependence on linker technology, .def files, etc.
This also solves issues in tgmath.h which currently every implementation gets wrong.
The syntax seems to imply assignability; syntax similar to typedef is also an option.
Attributes are not inherited across the alias, intentionally. Existing practice supports
variables as well as functions; users requested this.
Straw poll (opinion): Would WG14 prefer a typedef-like syntax for aliases?
8 / 6 / 13 (no clear direction)
N3442 Improved attribute((cleanup(...))) Through defer, r1
Mostly ready and seeking direction on a few details. There is an N-document and a TS in parallel, to get the wording out for both purposes ASAP.
There are not sufficient open questions to bother with an SG. panic and recover are
not included in this proposal. It is ready for implementer feedback.
Confusion over jumping out of blocks - not allowed in the Strasbourg version.
Requested by users; wanted the group's opinion. There is some prior art for allowing this
in goto out of nested functions and returning from a __finally.
General dislike for allowing the jumpout. No compelling evidence that this feature is intentional, rather than an emergent combination of vendor extensions. The user who asked for this didn't actually need it.
Some support for tying execution of defer to a control structure rather than a scope
like in Go - not possible and not proposed here because that would be stateful.
We can warn against defer in a loop, but not hoist it. Other object-based
solutions require an object model that doesn't exist in C.
N3497 Even simpler defer for direct integration v2
This proposal aims to see what can be done with existing extensions, simplifying the syntax and requiring a header. There is implementation experience of this way. It is very simple to build on top of nested functions or blocks or other vendor extensions, but requires the operand to be a block item rather than an arbitrary statement, forcing the semicolon. "Weird jumps" become undefined.
"Jump-over" refers to the same concept as jumping over declaration of a VLA and into its scope, not allowed for similar reasons.
Not convinced by standardizing the limitations of existing practice rather than aspiring to do better.
But implementations can allow all aspects of the full feature as extensions. The UB on
longjmp is a concern, but may be necessary.
Since alternative library implementations also exist, forcing the limitations of one library implementation into the definition may make this harder to develop portably. Some support for gathering implementation experience in a TS; the group already committed to this and has the work item open.
Straw poll (opinion): Would WG14 prefer the operand of defer to be defined as a block-item as in N3497?
7 / 4 / 17
The authors should come to a conclusion, this is not direction. We do have the implementations.
Straw poll (opinion): Would WG14 like to allow jumps out of deferred blocks?
1 / 17 / 9
Straw poll (opinion): Would WG14 like to allow defer to be provided as a library feature by requiring a standard header name?
4 / 10 / 11
Clear direction for the TS. We can target the IS as well but the purpose of the TS is to gather information from users.
N3494 Clarify status of non-returning functions with respect to function attributes v3
C23's new attributes missed some features used in practice by pure and const because they assume a return.
This is a reasonable requirement to impose since non-returning can affect other side effects on the callee side.
Optimizers don't generally consider things like signals. Some debate over which functions are OK to call; abort
is "morally stateless" for instance.
Is there any risk to allowing these from a security perspective? longjmp may be problematic.
Not helpful to use similar but subtly different wording - "visible side effect" vs. "observable state of execution" are different things, because side effects are modelled as-if they are effects on objects.
Want to match what GCC and Clang do but they are inadequately documented. Possible that compilers don't consider any of this. Clang treats this as silent UB. It tells LLVM to believe the annotations.
A direct call could be a Constraint violation, but this is not detectable in general.
Straw poll (opinion): Would WG14 like to add a list of exceptional behaviors along the lines of those specified in N3494?
4 / 6 / 12 (unclear direction)
N3427 Unspecified Sizes in Definitions of Arrays, v2
Dynamic size information now passes through auto and typeof. With the star notation, it is possible to
deduce the element count while specifying an element type. This is similar to the extension allowing auto
to deduce only parts of a type, forming a composite.
Is this worthwhile if we have countof? Saves repetition.
This also works with declaration of a scalar value, which is a pointer to an array of deduced size.
The "optionally enclosed in braces" refers to this where the initializer may be braced or un-braced.
The size propagates as though auto had been used, without risking errors sneaking in through repetition.
Value in communicating that two types are intended to be "the same" rather than having any specific count.
This would be a conforming extension to implement now, has anyone done so? There is a GCC patch available. The implementation effort is very low, implementability is not the problem. Using the star in this position allows it to use the existing composite type rules, and works with multi-dimensional arrays. Empty braces signify an incomplete type. Bounds checking could work with this (neither enables nor hinders it).
This makes a lot of macros easier to write by safely removing large areas of inserted repetition in the declared types. Making users retype things is a vulnerability.
There are some wording issues. This should be revisited after finishing the extended auto specifier.
Straw poll (opinion): Would WG14 like something along the lines of N3427 in C2Y?
11 / 3 / 9
N3357 frexp and double-double
While double double is not part of the C model, it can be read as applying to C, to IEEE, or to others.
This uses language from the Standard about the floating-point model. This doesn't introduce any terms.
Only the C model is discussed. This matches existing practice.
Is this prescribing an extension? That would be out of scope. This is the opposite. The model allows for floating-point numbers that aren't part of itself. This is just wording for if you follow it. This might be a better fit in the preamble.
Straw poll (decision): Does WG14 want to adopt N3357 into C2Y?
1 / 19 / 3 (no consensus)
Some C23 functions broken by these not applying to integer types. Obsolescence for the remaining listed functions keeps all implementations valid.
Straw poll (decision): Does WG14 want to adopt N3461 into C2Y?
20 / 0 / 2
Unanimous consent (decision) to put this item on the retcon list as it appears to be TC content.
Moves content from Annex G to the body text as requested in a previous meeting. Covers mixed domains and non-IEEE754 types as well by doing so.
Straw poll (decision): Does WG14 want to adopt N3460 into C2Y?
21 / 0 / 2
N3401 SIGFPE and I/O, version 2
This is an individual submission and not on behalf of CFP. Option 1 is the author's preferred resolution.
Implementations were polled by asking about this on the Reflector. There were no replies.
Some concern that this may not be a representative poll of embedded implementations.
Concern that this undermines opt-in error handling through fenv_t and fractures the
reliability of signals. Documented by the Linux Programming book, implying existing
behavior is relied upon. The floating-point exception mode is a global mode and can also
affect integer math on some platforms.
CFP were consulted but are neutral as this is out of scope for the group.
The "except as documented" clause in the Standard implies the STandard facilities cannot raise SIGFPE.
Straw poll (decision): Does WG14 want to adopt option 1 from N3401 into C2Y?
8 / 8 / 10 (not consensus)
Straw poll (decision): Does WG14 want to adopt option 3 from N3401 into C2Y?
4 / 8 / 13 (not consensus)
Straw poll (decision): Does WG14 want to adopt option 4 from N3401 into C2Y?
11 / 4 / 10 (consensus)
Straw poll (decision): Does WG14 want to adopt option 2 from N3401 into C2Y?
5 / 6 / 13 (not consensus)
N3492 Improved treatment of error conditions for functions that round result to narrow type (updates N3404)
The latitude provided by C99 means implementations diverged. Since implementations with no infinity cannot represent a domain error it has to be weakened in order to make more code conforming.
Concern that the error should still be included; this would make existing code non-conforming. The normal tendency is to soften requirements instead.
Straw poll (decision): Does WG14 want to adopt N3492 into C2Y?
15 / 2 / 8
N3405 Improved wording for treatment of error conditions in <math.h>
Similarly inconsistent on errors. This resolves a contradiction in the current text without intending for any existing implementation to change. Some opposition to weakening rather than strengthening the requirement.
"can" is correct here vs. "may".
Straw poll (decision): Does WG14 want to adopt N3405 into C2Y?
15 / 1 / 6
N3452 Complex literals warning
This is a non-normative clarification to users only.
The editor is requested to use "because" rather than "since" (and to generally avoid British-isms).
As error-related content these two papers should probably go on the retcon list too. The intent was that these are fixes to regressions.
Unanimous consent (decision) Does WG14 want N3492 and N3405 to be added to the list of papers of interest to maintainers of older versions? (consensus)
N3437 Variable Length Array Allocation Control, r0
Attempting to address the moral and technical issues that got VLAs downgraded in C11.
This is currently underspecified, limiting the support and portability. Does not attempt
to overturn the optional status of VLAs. Unifies praxis with alloca.
Allocators cannot return null for objects which must exist. The allocators can be function pointers in scope rather than function definitions. No change to default functionality and no API exposing the default functionality is provided.
Support for the concept; much support for the idea of instrumenting allocation in test code; concern that this is too similar to overloading and strangely different from other ways of providing Standard functionality. Some expectation that this would use a registration API rather than be implicit and scope-based.
Why can't users just malloc and free if they want to control the memory? Is there
real user demand? malloc would need defer.
Implementers unsure how they would deploy this. Compilers need to work with (some) foreign
Library implementations and this would be a potential ABI break from C23 to C2Y.
Observation that we are asking the user to define a reserved name (although it would be reserved for them to define in this case). Registration functions would eliminate the need for this. Wanted to avoid the overhead of making the functions dynamic by binding tightly to scope. Has to be provided in scope, not (just) at link time.
Not providing a guarantee if or when the free is called means existing optimizations are allowed to apply. Registration or mutability implies thread safety problems and possible efficiency loss.
Concerns about security risks, use-after-free, and interfering with existing security mitigations. Some support from people who dislike VLAs entirely because of the original design. Some concern about adding user hooks into the implementation - that could change existing code silently. EVen the scope based approach can change existing code by modifying a header.
Straw poll (opinion): Would WG14 like something along the lines of 3437 in C2Y?
5 / 12 / 11 (no direction to continue)
N3423 TrapC
Slide presentation by the author. The slides are available as N3512.
Presented as an "extended subset", therefore not an in-language subset of C itself.
TrapC includes a build system modeled on cargo which can be used for pure C projects as well.
Clarified that the "decimal" types mentioned are scaled-fixed-point values, not floating point.
Questions about seemingly arbitrary restrictions against unions and goto.
Questions about how the bounds checking is statically applied, especially in the case of
subscripting with arbitrary expressions or within a loop.
"Put AI in the compiler" to achieve this.
A runtime check would be required for some subscripts but not for every access.
When an invalid access is trapped, are valid accesses up to that point guaranteed to have been evaluated? Optimization is allowed, so the UB may result in some accesses being lost. Which outcome is worse (incomplete buffer vs. partial writes) depends on the domain. Wasn't really intended for embedded.
Is this a runtime or compile-time tool? For safety-critical, thorough test coverage is needed so intends for traps to be a runtime feature.
No poll.
N3438 #embed Synchronization, r0
Small changes to align with work on C++26 and consistency with GCC.
The use case for offset is to only load part of a file, mirroring limit. This was
an immediate user request and provided by compilers.
Implementation frustration about the order of the operators if combined. Is it
supposed to be possible to embed /dev/urandom now? Order of the existing operators
is already unclear.
All existing implementations seem to have the same behavior - skip offset elements,
then limit to limit elements. There seems to be no divergence in practice or intent
on this. Clang may have introduced divergences after a rewrite.
It is still possible to offset without limit into an infinite stream, what is this
supposed to do?
Discarding the first N from the infinite sequence of elements is intended to work.
limit is intended to be used with infinite streams and devices and was described as
such in the original feature.
General agreement that the intent of offset is clear. Sentiment that its combination
with limit is also clear, to pull out a fixed sequence from within a file.
Straw poll (opinion): Would WG14 like to apply changes along the lines of those specified by 3438 in C2Y?
11 / 2 / 11
N3469 Big Array Size Survey, r1
An actual statistical analysis of over one thousand Community responses. Many graphs provided in the linked blog post.
Survey was the result of a long debate in the previous session. SOme surprising preferences and a large number of free-text field responses.
Some negativity about the amount of time and effort spent in the previous session on this. This permanently closes the debate.
Straw poll (decision): Does WG14 want to rename lengthof to _Countof as specified in N3469?
9 / 3 / 12 (considered consensus)
Straw poll (decision): Does WG14 want to add a <stdcountof.h> header as specified in N3469?
10 / 3 / 11 (considered consensus)
Note to the editor to re-alphabetize the keyword list.
N3443 Integer Constant Expression-Initialized const Integer Declarations are Implicitly constexpr, r1
Aims to counterbalance the earlier proposal to force all arrays to be VLAs unless the size is
a strict integer constant expression. Not as aggressive as what GCC and Clang allow. Falls
within the C++ rules, but not as extensive. Does not obsolete constexpr, which is a more
general tool usable with other objects. Subset of existing practice.
Some users even wanted extern to work for this.
Straw poll (opinion): Would WG14 like something along the lines of N3443 in C2Y?
21 / 1 / 5
N3505 Preprocessor integer expressions, v. 2
Revises N3465 as homework. Resolves concerns and clarifies that builtins are OK.
Straw poll (decision): Does WG14 want to adopt N3505 into C2Y?
24 / 0 / 3
N3507 Pitch for #dialect directive (v2)
This is a pitch, not a concrete feature proposal. Slide presentation without fixed syntax. Noted some cases where C23 and GCC-latest breaks older code. Some projects like curl are explicitly saying that they will not move away from C89. A marker to communicate the intended version may therefore be useful.
This is metadata, not an instruction to the compiler intended to have effects. There is strong precedent in other languages.
Potential to integrate with build systems, improve error messaging by communicating intent,
and ease transition to new features like _Optional or deprecation of features like 0 as
the null pointer constant.
Allowing the directive to change language or control the set of active extensions is also a possible direction.
Has been proposed before; the problem is older translation units that need to keep working without changes including changes to add this annotation. Switching dialect mid-TU is a problem; the group probably do not want to allow it.
A pragma may be better, users will expect less direct effect from it. Should be put under
#pragma STDC. Agreement that metadata about a file should generally be in that file if possible.
There are some existing implementations of related pragmas. Existing practice does not allow
switching directive and just warns if subsequent pragmas are incompatible.
Straw poll (opinion): Would WG14 like something along the lines of the #dialect directive proposed by N3507 in C2Y?
9 / 12 / 7 (direction against)
The group wants "something, but not this".
N3389 C Extensions to Support Generalized Function Calls, v4
Reworded to borrow terms and specification from C++11. One final revision expected to fix minor wording issues before the balloted version. No changes to the intent of the feature since the Minneapolis meeting, but reworks how evaluation is specified.
Section 7 is overcomplicated and not a good candidate for adoption into the IS, but the Community wanted it to appear in the TS. Author would oppose putting Section 7 in the IS. This makes the position and scope of Section 6 clearer.
Tail calls can be rejected by a conforming implementation for any reason, or no reason at all, so long as they are rejected and not silently compiled as non-tail calls. There is now a feature macro so users can test this. In particular a conforming implementation is free to reject every tail call so long as it documents this.
Comment that TS should be limited to one feature per document. However, the scope of this TS was set previously to include both features and cannot be changed.
No poll (content has been voted on before).
N3453 Examples of Undefined Behavior
Updates the version last seen in Minneapolis, with examples for every UB, or a comment that the UB cannot be recreated if not. Some examples come from CERT. Reviewers needed.
Some of the Demons series of papers come from the UBs identified as having no example code and therefore as possible to delete.
Additional examples wanted; they can be direct links as well as inline. To Compiler Explorer or to an external test suite. Pseudocode may also be useful.
Confusion about example 6. Example 195 only affects hypothetical platforms.
In the previous meeting it was decided to aim for a whitepaper rather than to put the content into Annex J.
N3450 Function pointers are more readable with typeof()
Vague support from the room but a general preference to use typedef names for
complicated argument types instead, that can also appear in the Standard.
Straw poll (opinion): Would WG14 like typedef names to represent function types appearing in signatures, along the lines of the proposal in N3450?
8 / 4 / 10 (some direction)
Straw poll (decision): Does WG14 want to adopt N3450 into C2Y?
4 / 6 / 15 (not consensus)
Any such names should avoid treading on the user namespace. POSIX names may be good to adopt here.
N3408 About branding, community, website
A slide presentation and not a proposal for changes to C.
The traditional "K&R" logo is preferred over the "purple hexagon" logo (borrowed from C++). A colloquial-names list for various Standard versions is provided. The proper name of the working group proposed to be "C Committee" vs "WG14"; many names on sites like GitHub are currently occupied by domain-squatters. A Codeberg project would require it to be FOSS. Similar issues apply to domain names being squatted.
The new home page for the language itself (as opposed to the working group) was demo-ed and can be found at https://www.c-language.org/
General opposition to an official presence on GitHub.
Working out an arrangement with Codeberg may be possible.
The current website will not go away or be changed as part of this.
Need to ensure the website includes useful information for users (like links to standards) and limits distracting or non-useful information about the Committee.
N3447 Chasing Ghosts I: constant expressions
Many instances of "shall" which do not express a requirement and therefore do not link to any possible UB. This proposal reorders 6.6 significantly in aid of readability but is not intended to introduce any normative change.
Annex J is not normative; it is explicitly maintained by the editor. The UBSG could be given maintenance responsibility for the list. This is already de-facto the case since the UBSG needs to advise the editor, so it should be brought into official scope.
The text change is extensive although it is only a reordering, needs careful review. There are some unintentional normative changes identified already, alongside numbering errors and other merge-conflict-style issues. Diffmarks would be basically unreadable, however. It is clear that this should wait until the working draft has stabilized more in terms of changes being made to 6.6, such as integrating "discarded" expressions.
Straw poll (opinion): Would WG14 like something along the lines of N3447 in C2Y?
16 / 0 / 5
It is possible to make the pass removing non-requirement instances of "shall" separately, replacing it with "is" or "are".
Straw poll (decision): Does WG14 want to update Annex J.2 as specified by N3447?
12 / 0 / 6
Noted that Annex J is editorial, and this decision is just direction to the editor. However, it should be kept in sync with the body text.
Similar tautological requirements apply to e.g. integer constant expressions, which cannot have a non-integer type by their constructed definition.
The editor is requested not to add newly added UBs specified in N3447 before review by CFP and others.
N3448 Chasing Ghosts II: accessing allocated storage
Additional redundant uses of "shall" exposed by the changes to model byte arrays. This was officially never undefined. The values are unspecified but the behavior was always defined, and there is no non-value representation for byte types.
The change to remove "wobbly" memory was already previously applied.
This change could equally well refer to value bits rather than to a particular byte type.
There is potential for the same change to malloc and friends.
Access by a different type would be undefined even if it is defined not to have any non-value representations, so this is only about byte types.
Straw poll (decision): Does WG14 want to adopt the changes specified in N3448 into C2Y?
15 / 0 / 5
N3449 Enhanced type variance
A limitation in the type system means that users struggle with qualifiers. const
was a relatively late addition to C90. Intuitive features like adding qualification
to a parameter's pointed-to type doesn't work, but should. The teachability of this
is extremely poor, and removing the dependence on casting would greatly improve
safety and usability.
We do not currently have wording that enforces that a pointer to a qualified type and a pointer to an unqualified type have identical representations. This assumption doesn't hold in general, only for CVR-qualification; address-space qualification is completely different. Bringing parts of TR 18037 into C2Y would fix this kind of issue.
Address spaces and atomic derivations possibly shouldn't be considered qualifiers anyway. Every implementation has some of these "non-qualifier qualifiers" that would break because of this.
Currently lacking implementation experience, but wouldn't be hard; Needed to make
_Optional user-friendly. Need to be sure there is no break to extensions like
bounds-safety. Currently seeking a directional poll.
There is good experience of -wcast diagnostics in GCC et. al. Users tend to
be punished for being early adopters of features like this so there is a
chicken-egg problem w.r.t gaining experience. The parts of this proposal which
subset C++'s rules could potentially be split out and implemented first.
This sort of corner case would be a good thing to put on the new website.
Straw poll (opinion): Would WG14 like something along the lines of N3449 in C2Y?
15 / 1 / 8
Straw poll (opinion): Would WG14 like to see another document extending the principle of substitution to include void?
12 / 2 / 9
N3508 Objects of known constant size v4
This does not consider count. This does introduce a lot of changes to the syntax, and resolves the confusion between an expression and its value.
Straw poll (decision): Does WG14 want to adopt N3508 into C2Y, pending any objections before the next meeting?
20 / 1 / 2
"Array length" could potentially be improved to something like "element count" but is considered adequate wording for this change.
Note to the editor to change _Lengthof to _Countof in the merge conflict.
Reflector 29101 Questions about N3357
This asked for feedback after a negative vote, in the hopes of improving the response.
Terms like "the model" are unclear and should introduce something like "the C model" to avoid repetition but be clear what is being described. The exact phrasing may look a little strange.
Which section heading should this be introduced in? The model itself is described in 5.x, but the term is relied on by the definitions in 7.12.
A statement that other models than the C model exist should appear in the introduction in the Library section, and that the results of a Library function can be unspecified if evaluation doesn't follow the core C model. Make the exception a blanket one.
Direction for CFP to propose wording to place at the start of Section 7, which would then also apply to tgmath.h, float.h, etc.
Discussion about Pittsburgh, but see [4] above about the subsequent cancellation of that meeting.
None.
No specific action items assigned, except for Ballman to update the retcon list with items from the document review (all handled during the session: nothing outstanding).
Does WG14 want to adopt N3363 into C2Y, restoring footnote 292?
24 / 0 / 3
Does WG14 want to adopt N3484 as-is into C2Y?
25 / 0 / 7
Does WG14 want to adopt the first change from N3459 into C2Y?
20 / 0 / 7
Does WG14 want to adopt the second change from N3459 into C2Y?
14 / 0 / 12
Does WG14 want to conditionally adopt N3493 into C2Y, subject to any editorial changes?
11 / 6 / 8 (not adequate consensus)
Does WG14 want to adopt N3465 into C2Y?
10 / 2 / 12
Does WG14 want to adopt N3451 into C2Y?
21 / 1 / 9
Does WG14 want to adopt N3409 into C2Y?
22 / 0 / 4
Does WG14 want to adopt N3466 into C2Y?
14 / 1 / 6
Does WG14 want to adopt N3410 into C2Y?
20 / 0 / 1
Does WG14 want to adopt N3411 into C2Y?
20 / 2 / 3
Does WG14 want to adopt N3478 into C2Y?
23 / 0 / 1
Does WG14 want to adopt N3418 into C2Y?
20 / 1 / 3
Does WG14 want to adopt N3481 as-is into C2Y?
14 / 0 / 7
Does WG14 want to adopt N3482 into C2Y, without the additional changes?
18 / 0 / 6
Does WG14 want to adopt N3496 into C2Y?
20 / 0 / 4
Does WG14 want to adopt N3357 into C2Y?
1 / 19 / 3 (no consensus)
Does WG14 want to adopt N3461 into C2Y?
20 / 0 / 2
Does WG14 want N3461 to be added to the list of papers of interest to maintainers of older versions?
unanimous consent
Does WG14 want to adopt N3460 into C2Y?
21 / 0 / 2
Does WG14 want to adopt option 1 from N3401 into C2Y?
8 / 8 / 10 (not consensus)
Does WG14 want to adopt option 3 from N3401 into C2Y?
4 / 8 / 13 (not consensus)
Does WG14 want to adopt option 4 from N3401 into C2Y?
11 / 4 / 10 (consensus)
Does WG14 want to adopt option 2 from N3401 into C2Y?
5 / 6 / 13 (not consensus)
Does WG14 want to adopt N3492 into C2Y?
15 / 2 / 8
Does WG14 want to adopt N3405 into C2Y?
15 / 1 / 6
Does WG14 want to adopt N3452 into C2Y?
19 / 0 / 5
Does WG14 want N3492 and N3405 to be added to the list of papers of interest to maintainers of older versions?
unanimous consent
Does WG14 want to rename lengthof to _Countof as specified in N3469?
9 / 3 / 12 (considered consensus)
Does WG14 want to add a <stdcountof.h> header as specified in N3469?
10 / 3 / 11 (considered consensus)
Does WG14 want to adopt N3505 into C2Y?
24 / 0 / 3
Does WG14 want to adopt N3450 into C2Y?
4 / 6 / 15 (not consensus)
Does WG14 want to update Annex J.2 as specified by N3447?
12 / 0 / 6
Does WG14 want to adopt the changes specified in N3448 into C2Y?
15 / 0 / 5
Does WG14 want to adopt N3508 into C2Y, pending any objections before the next meeting?
20 / 1 / 2
Would WG14 like to adopt Myers's issue tracking system?
17 / 0 / 4 (approval)
Would WG14 like something along the lines of N3472 in C2Y?
18 / 0 / 6 (clear direction)
Would WG14 like array inference to always require [] in the declaration?
17 / 1 / 8 (clear direction)
Would WG14 like to see a paper changing the syntax for loop names at a future meeting?
6 / 11 / 9 (no direction)
Would WG14 like something along the lines of N3504 in C2Y?
12 / 0 / 11
Would WG14 like to retain the current Constraints for if-declarations?
9 / 7 / 12
Would WG14 like to remove the macro I and add an example of it defined as _Complex_I?
17 / 1 / 9
Would WG14 like to replace the undefined behavior identified in N3432 with a constraint?
20 / 3 / 4
Would WG14 like something along the lines of N3495 in C2Y?
22 / 0 / 6
Would WG14 like something along the lines of N3485 in C2Y?
15 / 3 / 11 (direction to continue)
Would WG14 like something along the lines of N3499 in C2Y?
9 / 3 / 11
Does WG14 prefer N3433 ("Chris's version") to N3394 ("Martin's version")?
15 / 3 / 11
Would WG14 like to define NULL as a macro expanding to an expression with type void *?
9 / 6 / 7 (not considered clear direction)
Would WG14 like to disallow NULL from expanding to an expression with integer type?
15 / 2 / 7 (clear direction)
Would WG14 like something along the lines of N3398 in C2Y?
20 / 0 / 5
Would WG14 support the syntax and semantics described in N3422 to be presented in a TS?
12 / 6 / 7
Would WG14 like a limit macro along the lines of the one expressed in N3471?
13 / 3 / 8
Would WG14 like to increase the limit value from 4096 along the lines of N3471?
6 / 7 / 11 (direction against)
Would WG14 prefer a typedef-like syntax for aliases?
8 / 6 / 13 (no clear direction)
Would WG14 prefer the operand of defer to be defined as a block-item as in N3497?
7 / 4 / 17
Would WG14 like to allow jumps out of deferred blocks?
1 / 17 / 9
Would WG14 like to allow defer to be provided as a library feature by requiring a standard header name?
4 / 10 / 11
Would WG14 like to add a list of exceptional behaviours along the lines of those specified in N3494?
4 / 6 / 12 (unclear direction)
Would WG14 like something along the lines of N3427 in C2Y?
11 / 3 / 9
Would WG14 like something along the lines of 3437 in C2Y?
5 / 12 / 11 (no direction to continue)
Would WG14 like to apply changes along the lines of those specified by 3438 in C2Y?
11 / 2 / 11
Would WG14 like something along the lines of N3443 in C2Y?
21 / 1 / 5
Would WG14 like something along the lines of the #dialect directive proposed by N3507 in C2Y?
9 / 12 / 7 (direction against)
Would WG14 like typedef names to represent function types appearing in signatures, along the lines of the proposal in N3450?
8 / 4 / 10 (some direction)
Would WG14 like something along the lines of N3447 in C2Y?
16 / 0 / 5
Would WG14 like something along the lines of N3449 in C2Y?
15 / 1 / 8
Would WG14 like to see another document extending the principle of substitution to include void?
12 / 2 / 9
The Committee thanks Dr Uecker and TU Graz for hosting this meeting!
Ballman moves, Johnson seconds. No objections.
Adjourned!