ISO/IEC TS 6010:2025

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: +41 22 749 01 11
Email: copyright@iso.org
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
...