ISO/IEC TS 6010:2025

Programming languages - C - A provenance-aware memory object model for C

This document specifies the form and establishes the interpretation of programs written in the C programming language. It is not a complete specification of that language but builds upon ISO/IEC 9899:2018 by constraining and clarifying the Memory Object Model.

Langages de programmation — C — Modèle d’objet mémoire sensible à la provenance pour C

General Information

• Status: Published
• Publication Date: 14-May-2025
• ICS: 35.060 - Languages used in information technology
• Technical Committee: ISO/IEC JTC 1/SC 22 - Programming languages, their environments and system software interfaces
• Drafting Committee: ISO/IEC JTC 1/SC 22 - Programming languages, their environments and system software interfaces
• Current Stage: 6060 - International Standard published
• Start Date: 15-May-2025
• Due Date: 02-Sep-2024
• Completion Date: 15-May-2025

Overview

ISO/IEC TS 6010:2025 - “Programming languages - C - A provenance-aware memory object model for C” - is a Technical Specification that refines the C memory object model defined in ISO/IEC 9899:2018. It is not a full re‑specification of C; rather, it constrains and clarifies the Memory Object Model by formalizing the concept of pointer provenance and the identities of storage instances. The TS provides precise semantics for pointer validity, object lifetimes and addresses, and includes an executable semantics (see the Cerberus implementation) to explore small test programs.

Key topics and requirements

• Pointer provenance: Defines provenance as the entity associated with a pointer value (either empty or the identity of a storage instance). A pointer’s validity depends on having non‑empty provenance, a live storage instance for that provenance, and an address within or one‑past that storage instance.
• Storage instance: Introduces the term for inclusion‑maximal regions of data storage created by object definitions or allocations. Storage instances have unique identities and may or may not have a memory address.
• Object lifetimes and storage durations: Clarifies lifetimes as side effects and reiterates the four storage durations (static, thread, automatic, allocated), applying storage duration to storage instances.
• Representation of types and addresses: States that addressable storage instances provide access to a byte array whose abstract byte addresses are represented as uintptr_t (implementation‑defined conversion rules). Relative positions of storage instances in the address space are described without imposing additional ordering constraints.
• Signal handling: Requires that when a signal handler modifies an object that is neither a lock‑free atomic nor of type volatile sig_atomic_t, the object’s representation becomes indeterminate when the handler exits.
• Scope and exclusions: Explicitly does not address subobject provenance and builds on normative references such as ISO/IEC 9899:2018 and ISO 80000‑2.

Applications

ISO/IEC TS 6010:2025 is directly applicable to:

• Compiler and tool developers - to implement provenance‑aware alias analysis and safe optimizations aligned with the C abstract machine.
• Static analysis and formal verification - to reason about pointer validity, undefined behavior and memory safety.
• Runtime sanitizers and debuggers - for more accurate detection of provenance violations and use‑after‑free.
• Security researchers - to model exploit mitigations that depend on precise pointer provenance semantics.
• Embedded and systems programmers - for understanding portability and memory‑model constraints affecting low‑level code.

Related standards

• ISO/IEC 9899:2018 - Programming languages - C (base standard extended by this TS)
• ISO 80000‑2 - Quantities and units (normative reference in the TS)

Keywords: ISO/IEC TS 6010:2025, C, provenance-aware, memory object model, pointer provenance, storage instance, ISO/IEC 9899:2018, memory model, alias analysis, static analysis, compilers.

Standards Content (Sample)

Technical
Specification
ISO/IEC TS 6010
First edition
Programming languages — C — A
2025-05
provenance-aware memory object
model for C
Langages de programmation — C — Modèle d’objet mémoire
sensible à la provenance pour C
Reference number
© ISO/IEC 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2025 – All rights reserved
ii
ISO/IECDTS6010:2025(en)
Contents
1 Scope 1
2 Normativereferences 1
3 Termsanddefinitions 1
4 Environment 2
4.1 Executionenvironments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4.2 Sizesofintegertypes . . . . . . . . . . . . . . . . . . . . . . . 2
5 Language 3
5.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5.1.1 Storagedurationsandobjectlifetimes . . . . . . . . . . . . . . . . . 3
5.1.2 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5.1.3 Representationoftypes . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.2 Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2.1 Lvalues,arraysandfunctiondesignators . . . . . . . . . . . . . . . 6
5.2.2 Pointers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2.3 Stringliterals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3.1 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3.2 Postfixoperators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3.3 Addressandindirectionoperators . . . . . . . . . . . . . . . . . . . 9
5.3.4 Additiveoperators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3.5 Relationaloperators . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3.6 Equalityoperators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3.7 Assignmentoperators . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3.8 Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3.9 Structureandunionspecifiers . . . . . . . . . . . . . . . . . . . . . . 11
5.3.10 Arraydeclarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3.11 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4 Statementsandblocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4.1 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4.2 Theswitchstatement . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.5 Externaldefinitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.5.1 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.5.2 Functiondefinitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6 Library 12
©ISO/IEC2025–Allrightsreserved
iii
ISO/IECDTS6010:2025(en)
6.1 Useoflibraryfunctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6.3 Thelongjmpfunction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.4 Thesignalfunction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.5 Variablearguments . . . . . . . . . . . . . . . . . . . . . . . . 14
6.6 Atomics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.6.1 TheATOMIC_VAR_INITmacro . . . . . . . . . . . . . . . . . . . . 14
6.6.2 Atomicflagtypeandoperations . . . . . . . . . . . . . . . . . . . . . 14
6.7 Integertypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.7.1 Integertypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.7.2 Macrosforintegerconstants . . . . . . . . . . . . . . . . . . . . . . . 15
6.8 Input/output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.8.1 Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.8.2 Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.8.3 Fileaccessfunctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.8.4 Directioninput/outputfunctions . . . . . . . . . . . . . . . . . . . . 16
6.9 Generalutilities . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.9.1 Storagemanagementfunctions . . . . . . . . . . . . . . . . . . . . . 17
6.9.2 Multibyte/widecharacterconversionfunctions. . . . . . . . . . . 18
6.10 Stringhandling . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.10.1 Copyingfunctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.10.2 Thestrxfrmfunction . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.11 Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.11.1 Thetss_createfunction . . . . . . . . . . . . . . . . . . . . . . . . 18
6.11.2 Thetss_setfunction . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.12 Thestrftimefunction,Dateandtime . . . . . . . . . . . . . 19
6.13 Extendedmultibyteandwidecharacterutilities. . . . . . . 19
6.13.1 Thefwprintffunction. . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.13.2 Thefwscanffunction . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.13.3 Thefgetwsfunction . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.13.4 Thewcsxfrmfunction . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.13.5 Thewcsftimefunction. . . . . . . . . . . . . . . . . . . . . . . . . . 20
AnnexA(informative)Portabilityissues 21
AnnexB(informative)Boundscheckinginterfaces 22
AnnexC(informative)Analyzability 23
Index 24
©ISO/IEC2025–Allrightsreserved
iv
ISO/IECDTS6010:2025(en)
Foreword
ISO(theInternationalOrganizationforStandardization)andIEC(theInternational
Electrotechnical Commission) form the specialized system for worldwide
standardization. National bodies that are members of ISO or IEC participate in
thedevelopmentofInternationalStandardsthroughtechnicalcommitteesestablished
bytherespectiveorganizationtodealwithparticularfieldsoftechnicalactivity.ISOand
IECtechnicalcommitteescollaborateinfieldsofmutualinterest. Otherinternational
organizations,governmentalandnon-governmental,inliaisonwithISOandIEC,also
takepartinthework.
The procedures used to develop this document and those intended for its further
maintenancearedescribedintheISO/IECDirectives,Part1. Inparticular,thedifferent
approval criteria needed for the different types of document should be noted. This
documentwasdraftedinaccordancewiththeeditorialrulesoftheISO/IECDirectives,
Part2(seewww.iso.org/directivesorwww.iec.ch/members_experts/refdocs).
ISOandIECdrawattentiontothepossibilitythattheimplementationofthisdocument
may involve the use of (a) patent(s). ISO and IEC take no position concerning the
evidence,validityorapplicabilityofanyclaimedpatentrightsinrespectthereof. As
ofthedateofpublicationofthisdocument,ISOandIEChadnotreceivednoticeof(a)
patent(s)whichmayberequiredtoimplementthisdocument. However,implementers
arecautionedthatthismaynotrepresentthelatestinformation,whichmaybeobtained
fromthepatentdatabaseavailableatwww.iso.org/patentsandhttps://patents.iec.ch.
ISOandIECshallnotbeheldresponsibleforidentifyinganyorallsuchpatentrights.
Anytradenameusedinthisdocumentisinformationgivenfortheconvenienceofusers
anddoesnotconstituteanendorsement.
Foranexplanationofthevoluntarynatureofstandards,themeaningofISOspecific
terms and expressions related to conformity assessment, as well as information
about ISO’s adherence to the World Trade Organization (WTO) principles in the
Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html. In the IEC,
seewww.iec.ch/understanding-standards.
ThisdocumentwaspreparedbyJointTechnicalCommitteeISO/IECJTC1,Information
technology, Subcommittee SC 22, Programming languages, their environments and
systemsoftwareinterfaces.
Any feedback or questions on this document should be directed to the user’s
national standards body. A complete listing of these bodies can be found at
www.iso.org/members.htmlandwww.iec.ch/national-committees.
©ISO/IEC2025–Allrightsreserved
v
ISO/IECDTS6010:2025(en)
Introduction
TheresolutionofDR260confirmedtheconceptofprovenanceofpointers,introducedas
meanstotrackanddistinguishpointervaluesthatrepresentstorageinstanceswiththe
sameaddress. Implementationsstartedtousethatconceptinoptimisationsrelyingon
provenance-basedaliasanalysis,withoutiteverbeingclearlyorformallydefined,and
withoutitbeingintegratedconsistentlywiththerestoftheCstandard. Thisdocument
providesasolutionforthis:aprovenance-awarememoryobjectmodelforCtoputC
programmersandimplementersonasolidfootinginthisregard.
In addition to this document, https://cerberus.cl.cam.ac.uk/cerberus provides an
executableversionofthesemantics,withawebinterfacethatallowsonetoexplore
andvisualisethebehaviourofsmalltestprograms.
Thisdocumentdoesnotaddresssubobjectprovenance.
©ISO/IEC2025–Allrightsreserved
vi
ISO/IECDTS6010:2025(en)
1 Scope
Thisdocumentspecifiestheformandestablishestheinterpretationofprogramswritten
intheCprogramminglanguage. Itisnotacompletespecificationofthatlanguagebut
builds upon ISO/IEC 9899:2018 by constraining and clarifying the Memory Object
Model.
2 Normativereferences
Thefollowingdocumentsarereferredtointhetextinsuchawaythatsomeorallof
theircontentconstitutesrequirementsofthisdocument. Fordatedreferences,only
theeditioncitedapplies.Forundatedreferences,thelatesteditionofthereferenced
document(includinganyamendments)applies.
ISO/IEC9899:2018,Programminglanguages–C
ISO80000–2,Quantitiesandunits—Part2: Mathematicalsignsandsymbolsto
beusedinthenaturalsciencesandtechnology.
3 Termsanddefinitions
For the purposes of this document, the terms and definitions given in ISO/IEC
9899:2018andthefollowingapply.
ISOandIECmaintainterminologydatabasesforuseinstandardizationatthefollowing
addresses:
– ISOOnlinebrowsingplatform: availableathttps://www.iso.org/obp/ui
– IECElectropedia: availableathttps://www.electropedia.org/
3.1
pointerprovenance
provenance
entity that is associated to a pointer value in the abstract machine, which is either
empty,ortheidentityofastorageinstance
3.2
storageinstance
storageinstance
inclusion-maximalregionofdatastorageintheexecutionenvironmentthatiscreated
wheneitheranobjectdefinitionoranallocationisencountered
Note1toentry: Storageinstancesarecreatedanddestroyedwhenspecificlanguageconstructs(ISO/IEC
9899:2018,6.2.4)aremetduringprogramexecution,includingprogramstartup,orwhenspecificlibrary
functions(ISO/IEC9899:2018,7.22.3)arecalled.
©ISO/IEC2025–Allrightsreserved
ISO/IECDTS6010:2025(en)
Note 2 to entry: It is possible that a storage instance does not have a memory address and is not
accessiblefromallthreadsofexecution.

Note3toentry: Storageinstanceshaveidentitieswhichareuniqueacrosstheprogramexecution.
Note4toentry: Astorageinstancewithamemoryaddressoccupiesaregionofzeroormorebytesof
contiguousdatastorageintheexecutionenvironment.
Note5toentry: Oneormoreobjectscanberepresentedwithinthesamestorageinstance,suchas
twosubobjectswithinanobjectofstructuretype,twoconst-qualifiedcompoundliteralswithidentical
objectrepresentation,ortwostringliteralswhereoneistheterminalcharactersequenceoftheother.
3.3
indeterminaterepresentation
object representation that either represents an unspecified value or is a non-value
representation
Note1toentry: Thisitemisadaptedfromtheterm"indeterminatevalue"(ISO/IEC9899:2018,3.19.2)
3.4
unspecifiedvalue
valid value of the relevant type where this document imposes no requirements on
whichvalueischoseninanyinstance
[SOURCE:ISO/IEC9899:2018,3.19.3,modified-Note1toentryhasbeenremoved.]
3.5
non-valuerepresentation
objectrepresentationthatdoesnotrepresentavalueoftheobjecttype
Note 1 to entry: This term was adapted from the term "trap representation" (ISO/IEC 9899:2018,
3.19.4)
4 Environment
4.1 Executionenvironments
The requirements in ISO/IEC 9899:2818, 5.1.2.3 shall apply in addition to the
following. For the purposes of this document, when processing of the abstract
machine is interrupted by the receipt of a signal, the representation of any object
modified by the handler that is neither a lock-free atomic object nor of type
volatile sig_atomic_tbecomesindeterminatewhenthehandlerexits.
4.2 Sizesofintegertypes
TherequirementsinISO/IEC9899:2018,5.2.4.2.1shallapply. Inadditionifthevalue
and promoted type is in the range of the type intmax_t (for a signed type) or
uintmax_t(foranunsignedtype),seeISO/IEC9899:2018,7.20.1.5,theexpression
©ISO/IEC2025–Allrightsreserved
ISO/IECDTS6010:2025(en)
shallbesuitableforusein#ifpreprocessingdirectives.

5 Language
5.1 Concepts
5.1.1 Storagedurationsandobjectlifetimes
ForthepurposesofthisdocumenttherequirementsfromISO/IEC9899:2018,6.2.4
shall applyin additionto thefollowing. Thelifetime ofan objecthas astart andan
end, which both constitute side effects in the abstract machine, and is the set of all
evaluationsthatoccurduringexecution.Anobjectexists,hasastorageinstancethat
1) 2)
isguaranteedtobereservedforit, hasaconstantaddress, ifany,andretainsits
3)
last-storedvaluethroughoutitslifetime.
Thelifetimeofanobjectisdeterminedbyitsstorageduration. Therearefourstorage
durations: static,thread,automatic,andallocated. Allocatedstorageanditsduration
aredescribedinISO/IEC9899:2018,7.22.3.
For the purposes of this document storage duration applies to an object’s storage
instance. Storageinstancesforstringliteralsandsomecompoundliteralshavestatic
4)
storageduration. Thereisadistinctinstanceoftheobjectanddistinctassociated
storageinstanceperthreadforthestorageinstanceofanobjectwiththreadstorage
duration. Storageinstancesoftemporaryobjectshaveautomaticstorageduration.
5.1.2 Types
ThisdocumentbuildsontherequirementsofISO/IEC9899:2018,6.2.5regardinghow
apointertypecanbederivedfromafunctiontypeoranobjecttypeasfollows.
A pointer type can be derived from a function type or an object type, called the
referencedtype.Apointertypedescribesanobjectwhosevalueprovidesareferenceto
anentityofthereferencedtype. Ifthetypeisanobjecttype,thepointeralsocarriesa
provenance,typicallyidentifyingthestorageinstanceholdingthecorrespondingobject,
if any; its value is valid if and only if it has a non-empty provenance, there is a live
storageinstanceforthatprovenance,andtheaddressiseitherwithinorone-pastthe
addressesofthatstorageinstance.Apointer-to-functionisvalidifitreferstoavalid
functiondefinitionoftheprogram. Pointersadditionallycanhaveaspecialvaluenull
thatisdifferentfromtheaddressofanystorageinstanceandhasnoprovenance(for
5)
objectpointers), orfromtheaddressofanyfunctionoftheprogram(forfunction
1)
Stringliterals,compoundliteralsorcertainobjectswithtemporarylifetimecanshareastorage
instancewithothersuchobjects.
2)
Theterm"constantaddress"meansthattwopointerstotheobjectconstructedatpossiblydifferent
timeswillcompareequal. Theaddresscanbedifferentduringtwodifferentexecutionsofthesame
program.
3)
Inthecaseofavolatileobject,thelaststorageisnotrequiredtobeexplicitintheprogram.
4)
Suchareforexamplecompoundliteralsthatareevaluatedinfilescopeorthatareconstqualified
andhaveonlyconstantexpressionsasinitializers.
5)
Apointerobjectcanbenullbyimplicitorexplicitinitializationorassignmentwithanullpointer
constantorbyanothernullpointervalue. Apointervaluecanbenullifitiseitheranullpointerconstant
ortheresultofanlvalueconversionofanullpointerobject. Anullpointerwillnotappearastheresult
©ISO/IEC2025–Allrightsreserved
ISO/IECDTS6010:2025(en)
pointers). Ifapointervalueisneithervalidnornull,itisinvalid. Apointertypederived
fromthereferencedtypeTissometimescalleda"pointertoT".Theconstructionofa

pointertypefromareferencetypeiscalled"pointertypederivation".Apointertype
6)
is a complete object type. Under certain circumstances, a pointer value can have
an address that is the end address of one storage instance and the start address of
another. It(andanypointervaluederivedfromitbymeansofarithmeticoperations)
shallthennotbeusedinwaysthatrequire(indifferentusages)morethanoneofthese
provenances.
Inadditiontotherequirementsontherepresentationandalignmentofpointersin
ISO/IEC 9899:2018, it is implementation-defined whether other groups of pointer
7)
typeshavethesamerepresentationoralignmentrequirements.
5.1.3 Representationoftypes
5.1.3.1 General
Forthepurposesofthisdocument,therequirementsofISO/IEC9899:2018,6.2.6.1
shallapplyinadditiontothefollowing. Anobjectisrepresented(orheld)byastorage
instance(orpartthereof)thatiseithercreatedbyanallocation(forallocatedstorage
duration),atprogramstartup(forstaticstorageduration),atthreadstartup(forthread
storage duration), or when the lifetime of the object starts (for automatic storage
duration).
8)
Anaddressablestorageinstance ofsizemprovidesaccesstoabytearrayoflengthm.
Eachbyteofthearrayhasanabstractaddress,whichisavalueoftypeuintptr_tthat
isdeterminedinanimplementation-definedmannerbypointer-to-integerconversion.
Theabstractaddressesofthebytesareincreasingwiththeorderingwithinthearray,
and they shall be unique and constant during the lifetime. The address of the first
byteofthearrayisthestartaddressofthestorageinstance,theaddressoneelement
beyondthearrayatindexmisitsendaddress. Theabstractaddressesofthebytesof
allstorageinstancesofaprogramexecutionformitsaddressspace. Astorageinstance
Y followsstorageinstanceX ifthestartaddressofY isgreaterorequalthantheend
addressofX,anditfollowsimmediatelyiftheyareequal. Ifthelifetimesofanytwo
distinctaddressablestorageinstancesXandY overlap,eitherY followsXorXfollowsY
intheaddressspace. Thisdocumentimposesnootherconstraintsaboutsuchrelative
9)
positionofaddressablestorageinstanceswhenevertheyarecreated.
ofanarithmeticoperation.
6)
The provenance of a pointer value and the property that such a pointer value is valid or not
are generally not observable. In particular, in the course of the same program execution the same
pointerobjectwiththesamerepresentationbytes(ISO/IEC9899:2018,6.2.6)cansometimesrepresent
validvaluesbutwithdifferentprovenance(andthusrefertodifferentobjects). Sometimestheobject
representationcanevenbeindeterminate,namelywhenthelifetimeofthestorageinstancehasended
andnonewstorageinstanceusesthesameaddress. Yet,thisinformationispartoftheabstractmachine
andcanrestrictthesetofoperationsthatcanbeperformedonthepointer.
7)
Animplementationcanrepresentallpointersthesameandwiththesamealignmentrequirements.
8)
Allstorageinstancesthatdonotoriginatefromanobjectdefinitionwithregisterstorageclass
areaddressablebyusingthepointervaluethatwasreturnedbytheirallocation(forallocatedstorage
duration)orbyapplyingtheaddress-ofoperator&(ISO/IEC9899:2018,6.5.3.2)totheobjectthatgave
risetotheirdefinition(forotherstoragedurations).
9)
This means that no relative ordering between storage instances and the objects they represent
©ISO/IEC2025–Allrightsreserved
ISO/IECDTS6010:2025(en)
The object representation of a pointer object does not necessarily determine
provenanceofapointervalue;atdifferentpointsoftheprogramexecution,identical

objectrepresentationsofpointervaluescanrefertodistinctstorageinstances. Unless
stated otherwise, a storage instance becomes exposed when a pointer value p of
10)
effectivetypeT withthisprovenanceisusedinthefollowingcontexts:
*
11)
– Anybyteoftheobjectrepresentationofpisusedinanexpression.
– Thebytearraypointed-tobythefirstargumentofacalltothefwritelibrary
functionintersectswithanobjectrepresentationofp.
– pisconvertedtoaninteger.
– pisusedasanargumenttoa%p conversionspecifieroftheprintffamilyof
12)
libraryfunctions.
Nevertheless,iftheobjectrepresentationofpisreadthroughanlvalueofapointertype
S thathasthesamerepresentationandalignmentrequirementsasT ,thatlvaluehas
* *
13)
thesameprovenanceaspandtheprovenancedoesnottherebybecomeexposed.
Exposureofastorageinstanceisirreversibleandconstitutesasideeffectintheabstract
machine.
Unlessstatedotherwise,pointervaluepissynthesizedifitisconstructedbyoneofthe
14)
following:
– Anybyteoftheobjectrepresentationofpischanged
– byanexplicitbyteoperation
– bytypepunningwithanon-pointerobjectorwithapointerobjectthatonly
partiallyoverlaps,
– or by a call tomemcpy or similar function that does not write the entire
pointerorrepresentationwherethesourceobjectdoesnothaveaneffective
pointertype.
– Theobjectrepresentationofpintersectswithabytearraypointed-tobythefirst
argumentofacalltothefreadlibraryfunction.
canbededucedfromsyntacticpropertiesoftheprogram(suchasdeclarationorderororderinsidea
parameterlist)orsequencingpropertiesoftheexecution(suchasoneinstantiationhappeningbefore
another).
10)
Pointervalueswithexposedprovenancecanaliasinwaysthatcannotbepredictedbysimpledata
flowanalysis.
11)
Theexposureofbytesoftheobjectrepresentationcanhappenthroughaconversionoftheaddress
ofapointerobjectcontainingptoacharactertypeandasubsequentaccesstothebytes,orbyreadingthe
representationofapointervaluepthroughaunionwithatypethatisnotapointertype(forexample
anintegertype)orwithapointertypethathasadifferentobjectrepresentationthantheoriginalpointer.
12)
Passingapointervaluetoa%sconversiondoesnotexposethestorageinstance.
13)
Thismeansthatpointermembersinaunioncanbeusedtoreinterpretrepresentationsofdifferent
character and void pointers, differentstruct pointers, differentunion pointers or pointers with
differentqualifiedtargettypes.
14)
Synthesizedpointervaluescanaliasinwaysthatcannotbepredictedbysimpledataflowanalysis.
©ISO/IEC2025–Allrightsreserved
ISO/IECDTS6010:2025(en)
– pisconvertedfromanintegervalue.

– &p is used as an argument to%p conversion specifier of thescanf family of
libraryfunctions.
Specialprovisionsintherespectiveclausesclarifywhensuchasynthesizedpointeris
null,valid,orinvalid.
Valuesstoredinnon-bit-fieldobjectsofanyotherobjecttypearerepresentedusing
n x CHAR_BIT bits, where n is the size of that object type, in bytes. Converting a
pointerofsuchanobjecttoapointertoacharactertypeorvoidyieldsapointerinto
thebytearrayofthestorageinstancesuchthatthevaluesofthefirstnbytesdetermine
thevalueoftheobject; thepositionofthefirstbyteoftheseinthebytearrayisthe
byteoffsetoftheobjectinitsstorageinstance,theconvertedaddressiscalledthebyte
addressoftheobject,andtherangeofbyteswithinthebytearrayiscalledtheobject
representationofthevalue. Theobjectrepresentationcanbeusedtocopythevalueof
theobjectintoanotherobject(e.g.,bymemcpy). Theobjectrepresentationsofpointers
andhowtheyrelatetotheabstractaddressestheyrepresentarenotfurtherspecified
bythisdocument.
For the purposes of this document, trap representation is referred to as non-value
representation.
5.1.3.2 IntegerTypes
The requirements of ISO/IEC 9899:2018, 6.2.6.2 shall apply. For the purposes of
this document trap and non-trap values are referred to as value and non-value
representationsofthevalue.
5.2 Conversion
5.2.1 Lvalues,arraysandfunctiondesignators
ForthepurposesofthisdocumenttherequirementsfromISO/IEC9899:2018,6.3.2.1
shall apply in addition to the following. The behavior of an lvalue conversion is
undefined if the lvalue object representation is a non-value representation for the
15)
type.
Additionally,ifthetypeisapointertypeT ,apointervalueandassociatedprovenance,
*
ifany,isdeterminedasfollows:
– Iftheobjectrepresentationrepresentsanullpointertheresultisanullpointer.
– IfthelaststoretotherepresentationarraywaswithapointertypeS thathas
*
thesamerepresentationandalignmentrequirementsasT ,theresultisthesame
*
addressandprovenanceasthestoredvalue.
– Otherwise,theobjectrepresentationofthelvalueshallrepresentabyteaddress
within(orone-past)theobjectrepresentationofanexposedstorageinstance,
15)
Character types have no non-value representation, thus reading representation bytes of an
addressablelivestorageinstanceisalwaysdefined.
©ISO/IEC2025–Allrightsreserved
ISO/IECDTS6010:2025(en)
suchthattheexposurehappenedbeforethislvalueconversion,andtheresult
16)
hasthataddressandprovenance.
Thebehaviorisundefinedifthepointerobjecthasanindeterminaterepresentation,in
particularifthelvalueconversiondoesnothappenduringthelifetimeoftheprovenance
thatwasassociatedtothestoredpointervalue,therepresentedaddressisnotavalid
address(orone-past)fortheassociatedprovenance,ortherepresentedaddressisnot
correctlyalignedforthetype.
5.2.2 Pointers
The requirements from ISO/IEC 9899:2018, 6.3.2.3 shall apply in addition to the
following. Anintegercanbeconvertedtoanypointertype. Ifthesourcetypeissigned,
theoperandisfirstconvertedtothecorrespondingunsignedtype.Theresultisthen
determinedinthefollowingorder:
– The operand value is the result of the conversion of a null pointer value. The
resultisanullpointer.
– Theoperandvalueisanabstractaddresswithinoronepastaliveandexposed
storageinstance,suchthattheexposurehappenedbeforethisinteger-to-pointer
conversion. The conversion synthesizes a pointer value with that address,
17)
provenanceandtargettype.
– Thepointervalueisinvalid.
Exceptaspreviouslyspecified,theresultisimplementation-defined,canbeincorrectly
aligned,canpointtoanentitywithatypedifferenttothereferencedtype,canbeinvalid,
andcanproduceanindeterminaterepresentationwhenstoredintoanobject.
Anypointertypecanbeconvertedtoanintegertype.Foranullpointer,theresultis
18)
chosenfromanon-emptysetofimplementation-definedvalues. Ifthepointervalue
isvalid,itsprovenanceishenceforthexposed. Exceptaspreviouslyspecified,theresult
istheabstractaddress(whichhastypeuintptr_t)convertedtothetargettype.If
thetargettype hasawidththatislessthanthewidthofuintptr_t, the behavior
is undefined. If the target type is a signed type and the abstract address is larger
thanthemaximumvalueofofthattypetheimplementation-definedconversionfrom
19)
uintptr_ttothetargettypeasspecifiedinISO/IEC9899:2018,6.3.1.3isapplied.
Ifthepointerisnullorvalid,theintegerresultconvertedbacktothepointertypeshall
20)
compareequaltotheoriginalpointer. Fortwovalidpointervaluesthatcompare
equal,conversiontothesameintegertypeyieldsidenticalvalues.
16)
Iftheaddresscorrespondstomorethanoneprovenance, onlyoneoftheseshallbeusedinthe
sequel,seeISO/IEC9899:2018,6.2.5.
17)
Iftheaddresscorrespondstomorethanoneprovenance, onlyoneoftheseshallbeusedinthe
sequel,seeISO/IEC9899:2018,6.2.5.
18)
Itisrecommendedthat0isamemberofthatset.
19)
Thus,theresultisanimplementation-definedvalueoranimplementation-definedsignalisraised.
20)
Althoughsucharound-tripconversioncanbetheidentityforthepointervalue,thesideeffectof
exposingastorageinstancestilltakesplace.
©ISO/IEC2025–Allrightsreserved
ISO/IECDTS6010:2025(en)
A pointer to an object type can be converted to a pointer to a different object type,
21)
retaining its provenance. If the resulting pointer is not correctly aligned for the

reference type, the behavior is undefined. Otherwise, when converted back again,
theresultshallcompareequaltotheoriginalpointer.Whenapointertoanobjectis
convertedtoapointertoacharactertypeorvoid,theresultisthebyteaddressofthe
object.
NOTE:Iftheresultpofanlvalueconversionorinteger-to-pointerconversionisthe
endaddressofanexposedstorageinstanceAandthestartofanotherexposedstorage
instance B that happens to follow immediately in the address space, a conforming
programisexpectedtoonlyuseoneoftheseprovenancesinanyexpressionsthatare
derivedfromp,seeISO/IEC9899:2018,6.2.5.
ThefollowingthreecasesdetermineifpisusedwitheitherAorBandshallhencenot
beusedotherwise:
– OperationsthatconstituteauseofpwitheitherAorBanddonotprohibitause
withtheother:
– anyrelationaloperatororpointersubtractionwheretheotheroperandq
can haveboth provenances, that iswhereqis alsothe resultofa similar
conversionwherep == q;
– q == pandq != pregardlessoftheprovenanceofq;
– additionorsubtractionofthevalue0;
– conversiontointeger.
In the latter case A and B have been exposed before, and so any choice of
provenance,thatwouldotherwisehaveexposedoneofthestorageinstances,is
consistentwithanyotheruse.
– Operationsthat,ifotherwisewelldefined,constituteauseofpwithAandprohibit
anyusewithB:
– anyrelationaloperatororpointersubtractionwheretheotheroperandq
hasprovenanceAandcannothaveprovenanceB;
– p + nandp[n],wherenisanintegerstrictlylessthan0;
– p - n,wherenisstrictlygreaterthan0.
– Operationsthat,ifotherwisewelldefined,constituteauseofpwithBandprohibit
anyusewithA:
– anyrelationaloperatororpointersubtractionwheretheotheroperandq
hasprovenanceBandcannothaveprovenanceA;
– p + nandp[n],wherenisstrictlygreaterthan0;
21)
Ingeneral,theconcept"correctlyaligned"istransitive: ifapointertotypeAiscorrectlyaligned
forapointertoB,whichinturniscorrectlyalignedforapointertotypeC,thenapointertotypeAis
correctlyalignedforapointertotypeC.
©ISO/IEC2025–Allrightsreserved
ISO/IECDTS6010:2025(en)
– p - n,wherenisstrictlylessthan0.
– operationsthataccessanobjectinB,thatisindirection( p orp[n]for
*
n == 0)andmemberaccess(p->member).
5.2.3 Stringliterals
InadditiontoISO/IEC9899:2018,6.4.5,paragraph7,itisunspecifiedwhetherthese
22)
arrays are distinct provided their elements have the appropriate values. If the
programattemptstomodifysuchanarray,thebehaviorisundefined.
5.3 Expressions
5.3.1 General
InadditiontotherequirementsspecifiedinISO/IEC9899:2018,6.5,theeffectivetype
23)
ofanobjectforanaccesstoitsstoredvalueisthedeclaredtypeoftheobject,ifany.
5.3.2 Postfixoperators
5.3.2.1 Structureandunionmembers
The requirements from ISO/IEC 9899:2018, 6.5.2.3 shall apply in addition to the
following. A postfix expression followed by the -> operator and an identifier
designatesamemberofastructureorunionobject.Thepointervalueshallbevalid,
notbetheendaddressofitsprovenance,andbecorrectlyalignedforthestructureor
uniontype.
Inaddition,forthepurposesofthisdocument,atraprepresentationisreferredtoasa
non-valuerepresentation.
5.3.2.2 Compoundliterals
The requirements from ISO/IEC 9899:2018, 6.5.2.5 shall apply in addition to the
following. For the purposes of this document the storage of string literals, and
compound literals with const-qualified types, are referred to as storage instances.
Additionally,indeterminatevalueisreferredtoasindeterminaterepresentation.
Forexample8,thebehaviorofthelvalueconversionofpintheassignmenttoqwould
thenbeundefined.
5.3.3 Addres
...