Skip to content

Commit 1dae365

Browse files
Albertyang0carsonRadtkeTylerMSFTJillGrant615prmerger-automator[bot]
authored
4/22/2025 AM Publish (#5886)
* docs for justification in pragma warning * docs for gsl::suppress * teach gsl::suppress("rule") instead of gsl::suppress(rule) * doc - portion of flag * acrolinx * related to #5230 - call out buffer fill behavior * edit * acrolinx/link fix * Confirm merge from FromPublicMasterBranch to main to sync with https://github.com/MicrosoftDocs/cpp-docs (branch main) (#5870) * vswprintf/_vswprintf_l return value description update. * Return value/Remarks sections update. * Behavior summary update. * Behavior summary update. * Merge pull request #5867 from MicrosoftDocs/main 4/10/2025 AM Publish * Update behavior description for `buffer` and `count` conditions The behavior is slightly different than stated. * Update return value behavior for valid buffer behave is different than written here. * Clarify vswprintf return values for count zero behavior is a little different for count = 0 case. * Update remarks and behavior summary sections The behavior in debug mode applies to all functions on this page, so made more prominent. * Fix NULL character formatting in documentation * 4/11/2025 AM Publish (#5869) * doc - portion of flag * acrolinx --------- Co-authored-by: TylerMSFT <[email protected]> Co-authored-by: Jill Grant <[email protected]> * Clarify vswprintf behavior when count is zero * Standardize 'null' to 'NULL' --------- Co-authored-by: Nikita Leontiev <[email protected]> Co-authored-by: Bo wen Yang <[email protected]> Co-authored-by: learn-build-service-prod[bot] <113403604+learn-build-service-prod[bot]@users.noreply.github.com> Co-authored-by: Learn Build Service GitHub App <Learn Build Service [email protected]> Co-authored-by: Tyler Whitney <[email protected]> Co-authored-by: Jill Grant <[email protected]> Co-authored-by: Courtney Wales <[email protected]> * Add Arm64 forceInterlockedFunctions option (#5822) * Learn Editor: Update compiler-options-listed-by-category.md * Learn Editor: Update compiler-options-listed-alphabetically.md * Learn Editor: Update force-interlocked-functions.md * Learn Editor: Update force-interlocked-functions.md * update Metadata * Update force-interlocked-functions.md with github id author name * Reorder compiler options in toc.yml to be alphabetical * Learn Editor: Update compiler-options-listed-alphabetically.md * Learn Editor: Update compiler-options-listed-by-category.md * Learn Editor: Update force-interlocked-functions.md * change article metadata * Learn Editor: Update force-interlocked-functions.md * Fix casing in toc.yml for forceInterlockedFunctions * Add 'items' section to toc.yml to revert previous change * Fix indentation in toc.yml file * Update metadata and improve documentation wording * Update metadata in force-interlocked-functions.md tidied up metdata * Fix typos and improve clarity in documentation * Update description for `/forceInterlockedFunctions` option * Clarify CPU capability/ runtime description in documentation * Update remark on Armv8.0 instructions * Remove unneeded template comments and update livelock remarks in documentation * Add "---" to metadata --------- Co-authored-by: Tyler Whitney <[email protected]> * address feedback * small edits * Update floating-point-support.md Add a note to capture that floating point math functions can change between OS versions. * Confirm merge from FromPublicMasterBranch to main to sync with https://github.com/MicrosoftDocs/cpp-docs (branch main) (#5874) * vswprintf/_vswprintf_l return value description update. * Return value/Remarks sections update. * Behavior summary update. * Behavior summary update. * Merge pull request #5867 from MicrosoftDocs/main 4/10/2025 AM Publish * Update behavior description for `buffer` and `count` conditions The behavior is slightly different than stated. * Update return value behavior for valid buffer behave is different than written here. * Clarify vswprintf return values for count zero behavior is a little different for count = 0 case. * Update remarks and behavior summary sections The behavior in debug mode applies to all functions on this page, so made more prominent. * Fix NULL character formatting in documentation * 4/11/2025 AM Publish (#5869) * doc - portion of flag * acrolinx --------- Co-authored-by: TylerMSFT <[email protected]> Co-authored-by: Jill Grant <[email protected]> * Clarify vswprintf behavior when count is zero * Standardize 'null' to 'NULL' * 4/14/2025 AM Publish (#5871) * doc - portion of flag * acrolinx * related to #5230 - call out buffer fill behavior * edit * acrolinx/link fix * Confirm merge from FromPublicMasterBranch to main to sync with https://github.com/MicrosoftDocs/cpp-docs (branch main) (#5870) * vswprintf/_vswprintf_l return value description update. * Return value/Remarks sections update. * Behavior summary update. * Behavior summary update. * Merge pull request #5867 from MicrosoftDocs/main 4/10/2025 AM Publish * Update behavior description for `buffer` and `count` conditions The behavior is slightly different than stated. * Update return value behavior for valid buffer behave is different than written here. * Clarify vswprintf return values for count zero behavior is a little different for count = 0 case. * Update remarks and behavior summary sections The behavior in debug mode applies to all functions on this page, so made more prominent. * Fix NULL character formatting in documentation * 4/11/2025 AM Publish (#5869) * doc - portion of flag * acrolinx --------- Co-authored-by: TylerMSFT <[email protected]> Co-authored-by: Jill Grant <[email protected]> * Clarify vswprintf behavior when count is zero * Standardize 'null' to 'NULL' --------- Co-authored-by: Nikita Leontiev <[email protected]> Co-authored-by: Bo wen Yang <[email protected]> Co-authored-by: learn-build-service-prod[bot] <113403604+learn-build-service-prod[bot]@users.noreply.github.com> Co-authored-by: Learn Build Service GitHub App <Learn Build Service [email protected]> Co-authored-by: Tyler Whitney <[email protected]> Co-authored-by: Jill Grant <[email protected]> Co-authored-by: Courtney Wales <[email protected]> --------- Co-authored-by: TylerMSFT <[email protected]> Co-authored-by: Jill Grant <[email protected]> Co-authored-by: prmerger-automator[bot] <40007230+prmerger-automator[bot]@users.noreply.github.com> Co-authored-by: learn-build-service-prod[bot] <113403604+learn-build-service-prod[bot]@users.noreply.github.com> Co-authored-by: Nikita Leontiev <[email protected]> Co-authored-by: Learn Build Service GitHub App <Learn Build Service [email protected]> Co-authored-by: Courtney Wales <[email protected]> * Fix typo VSCode -> VS Code * Fix wrong image file name in get-started-linux-cmake.md Fix the image file name for cmake-bullet3-linux-callstack.png for the call stack. * 4/15/2025 AM Publish (#5873) * docs for justification in pragma warning * docs for gsl::suppress * teach gsl::suppress("rule") instead of gsl::suppress(rule) * doc - portion of flag * acrolinx * related to #5230 - call out buffer fill behavior * edit * acrolinx/link fix * Confirm merge from FromPublicMasterBranch to main to sync with https://github.com/MicrosoftDocs/cpp-docs (branch main) (#5870) * vswprintf/_vswprintf_l return value description update. * Return value/Remarks sections update. * Behavior summary update. * Behavior summary update. * Merge pull request #5867 from MicrosoftDocs/main 4/10/2025 AM Publish * Update behavior description for `buffer` and `count` conditions The behavior is slightly different than stated. * Update return value behavior for valid buffer behave is different than written here. * Clarify vswprintf return values for count zero behavior is a little different for count = 0 case. * Update remarks and behavior summary sections The behavior in debug mode applies to all functions on this page, so made more prominent. * Fix NULL character formatting in documentation * 4/11/2025 AM Publish (#5869) * doc - portion of flag * acrolinx --------- Co-authored-by: TylerMSFT <[email protected]> Co-authored-by: Jill Grant <[email protected]> * Clarify vswprintf behavior when count is zero * Standardize 'null' to 'NULL' --------- Co-authored-by: Nikita Leontiev <[email protected]> Co-authored-by: Bo wen Yang <[email protected]> Co-authored-by: learn-build-service-prod[bot] <113403604+learn-build-service-prod[bot]@users.noreply.github.com> Co-authored-by: Learn Build Service GitHub App <Learn Build Service [email protected]> Co-authored-by: Tyler Whitney <[email protected]> Co-authored-by: Jill Grant <[email protected]> Co-authored-by: Courtney Wales <[email protected]> * Add Arm64 forceInterlockedFunctions option (#5822) * Learn Editor: Update compiler-options-listed-by-category.md * Learn Editor: Update compiler-options-listed-alphabetically.md * Learn Editor: Update force-interlocked-functions.md * Learn Editor: Update force-interlocked-functions.md * update Metadata * Update force-interlocked-functions.md with github id author name * Reorder compiler options in toc.yml to be alphabetical * Learn Editor: Update compiler-options-listed-alphabetically.md * Learn Editor: Update compiler-options-listed-by-category.md * Learn Editor: Update force-interlocked-functions.md * change article metadata * Learn Editor: Update force-interlocked-functions.md * Fix casing in toc.yml for forceInterlockedFunctions * Add 'items' section to toc.yml to revert previous change * Fix indentation in toc.yml file * Update metadata and improve documentation wording * Update metadata in force-interlocked-functions.md tidied up metdata * Fix typos and improve clarity in documentation * Update description for `/forceInterlockedFunctions` option * Clarify CPU capability/ runtime description in documentation * Update remark on Armv8.0 instructions * Remove unneeded template comments and update livelock remarks in documentation * Add "---" to metadata --------- Co-authored-by: Tyler Whitney <[email protected]> * address feedback * small edits --------- Co-authored-by: Carson Radtke <[email protected]> Co-authored-by: TylerMSFT <[email protected]> Co-authored-by: Jill Grant <[email protected]> Co-authored-by: prmerger-automator[bot] <40007230+prmerger-automator[bot]@users.noreply.github.com> Co-authored-by: learn-build-service-prod[bot] <113403604+learn-build-service-prod[bot]@users.noreply.github.com> Co-authored-by: Nikita Leontiev <[email protected]> Co-authored-by: Learn Build Service GitHub App <Learn Build Service [email protected]> Co-authored-by: Courtney Wales <[email protected]> Co-authored-by: Emily Bao <[email protected]> Co-authored-by: Stacy Chambers <[email protected]> --------- Co-authored-by: Nikita Leontiev <[email protected]> Co-authored-by: Bo wen Yang <[email protected]> Co-authored-by: learn-build-service-prod[bot] <113403604+learn-build-service-prod[bot]@users.noreply.github.com> Co-authored-by: Learn Build Service GitHub App <Learn Build Service [email protected]> Co-authored-by: Tyler Whitney <[email protected]> Co-authored-by: Jill Grant <[email protected]> Co-authored-by: Courtney Wales <[email protected]> Co-authored-by: prmerger-automator[bot] <40007230+prmerger-automator[bot]@users.noreply.github.com> Co-authored-by: Takashi Takebayashi <[email protected]> Co-authored-by: liginity <[email protected]> Co-authored-by: Carson Radtke <[email protected]> Co-authored-by: Emily Bao <[email protected]> Co-authored-by: Stacy Chambers <[email protected]> Co-authored-by: Diana Richards <[email protected]> * add customer requested info about #pragma * wordsmith * fix broken link * Confirm merge from FromPublicMasterBranch to main to sync with https://github.com/MicrosoftDocs/cpp-docs (branch main) (#5877) * vswprintf/_vswprintf_l return value description update. * Return value/Remarks sections update. * Behavior summary update. * Behavior summary update. * Merge pull request #5867 from MicrosoftDocs/main 4/10/2025 AM Publish * Update behavior description for `buffer` and `count` conditions The behavior is slightly different than stated. * Update return value behavior for valid buffer behave is different than written here. * Clarify vswprintf return values for count zero behavior is a little different for count = 0 case. * Update remarks and behavior summary sections The behavior in debug mode applies to all functions on this page, so made more prominent. * Fix NULL character formatting in documentation * 4/11/2025 AM Publish (#5869) * doc - portion of flag * acrolinx --------- Co-authored-by: TylerMSFT <[email protected]> Co-authored-by: Jill Grant <[email protected]> * Clarify vswprintf behavior when count is zero * Standardize 'null' to 'NULL' * 4/14/2025 AM Publish (#5871) * doc - portion of flag * acrolinx * related to #5230 - call out buffer fill behavior * edit * acrolinx/link fix * Confirm merge from FromPublicMasterBranch to main to sync with https://github.com/MicrosoftDocs/cpp-docs (branch main) (#5870) * vswprintf/_vswprintf_l return value description update. * Return value/Remarks sections update. * Behavior summary update. * Behavior summary update. * Merge pull request #5867 from MicrosoftDocs/main 4/10/2025 AM Publish * Update behavior description for `buffer` and `count` conditions The behavior is slightly different than stated. * Update return value behavior for valid buffer behave is different than written here. * Clarify vswprintf return values for count zero behavior is a little different for count = 0 case. * Update remarks and behavior summary sections The behavior in debug mode applies to all functions on this page, so made more prominent. * Fix NULL character formatting in documentation * 4/11/2025 AM Publish (#5869) * doc - portion of flag * acrolinx --------- Co-authored-by: TylerMSFT <[email protected]> Co-authored-by: Jill Grant <[email protected]> * Clarify vswprintf behavior when count is zero * Standardize 'null' to 'NULL' --------- Co-authored-by: Nikita Leontiev <[email protected]> Co-authored-by: Bo wen Yang <[email protected]> Co-authored-by: learn-build-service-prod[bot] <113403604+learn-build-service-prod[bot]@users.noreply.github.com> Co-authored-by: Learn Build Service GitHub App <Learn Build Service [email protected]> Co-authored-by: Tyler Whitney <[email protected]> Co-authored-by: Jill Grant <[email protected]> Co-authored-by: Courtney Wales <[email protected]> --------- Co-authored-by: TylerMSFT <[email protected]> Co-authored-by: Jill Grant <[email protected]> Co-authored-by: prmerger-automator[bot] <40007230+prmerger-automator[bot]@users.noreply.github.com> Co-authored-by: learn-build-service-prod[bot] <113403604+learn-build-service-prod[bot]@users.noreply.github.com> Co-authored-by: Nikita Leontiev <[email protected]> Co-authored-by: Learn Build Service GitHub App <Learn Build Service [email protected]> Co-authored-by: Courtney Wales <[email protected]> * Fix typo VSCode -> VS Code * Fix wrong image file name in get-started-linux-cmake.md Fix the image file name for cmake-bullet3-linux-callstack.png for the call stack. * 4/15/2025 AM Publish (#5873) * docs for justification in pragma warning * docs for gsl::suppress * teach gsl::suppress("rule") instead of gsl::suppress(rule) * doc - portion of flag * acrolinx * related to #5230 - call out buffer fill behavior * edit * acrolinx/link fix * Confirm merge from FromPublicMasterBranch to main to sync with https://github.com/MicrosoftDocs/cpp-docs (branch main) (#5870) * vswprintf/_vswprintf_l return value description update. * Return value/Remarks sections update. * Behavior summary update. * Behavior summary update. * Merge pull request #5867 from MicrosoftDocs/main 4/10/2025 AM Publish * Update behavior description for `buffer` and `count` conditions The behavior is slightly different than stated. * Update return value behavior for valid buffer behave is different than written here. * Clarify vswprintf return values for count zero behavior is a little different for count = 0 case. * Update remarks and behavior summary sections The behavior in debug mode applies to all functions on this page, so made more prominent. * Fix NULL character formatting in documentation * 4/11/2025 AM Publish (#5869) * doc - portion of flag * acrolinx --------- Co-authored-by: TylerMSFT <[email protected]> Co-authored-by: Jill Grant <[email protected]> * Clarify vswprintf behavior when count is zero * Standardize 'null' to 'NULL' --------- Co-authored-by: Nikita Leontiev <[email protected]> Co-authored-by: Bo wen Yang <[email protected]> Co-authored-by: learn-build-service-prod[bot] <113403604+learn-build-service-prod[bot]@users.noreply.github.com> Co-authored-by: Learn Build Service GitHub App <Learn Build Service [email protected]> Co-authored-by: Tyler Whitney <[email protected]> Co-authored-by: Jill Grant <[email protected]> Co-authored-by: Courtney Wales <[email protected]> * Add Arm64 forceInterlockedFunctions option (#5822) * Learn Editor: Update compiler-options-listed-by-category.md * Learn Editor: Update compiler-options-listed-alphabetically.md * Learn Editor: Update force-interlocked-functions.md * Learn Editor: Update force-interlocked-functions.md * update Metadata * Update force-interlocked-functions.md with github id author name * Reorder compiler options in toc.yml to be alphabetical * Learn Editor: Update compiler-options-listed-alphabetically.md * Learn Editor: Update compiler-options-listed-by-category.md * Learn Editor: Update force-interlocked-functions.md * change article metadata * Learn Editor: Update force-interlocked-functions.md * Fix casing in toc.yml for forceInterlockedFunctions * Add 'items' section to toc.yml to revert previous change * Fix indentation in toc.yml file * Update metadata and improve documentation wording * Update metadata in force-interlocked-functions.md tidied up metdata * Fix typos and improve clarity in documentation * Update description for `/forceInterlockedFunctions` option * Clarify CPU capability/ runtime description in documentation * Update remark on Armv8.0 instructions * Remove unneeded template comments and update livelock remarks in documentation * Add "---" to metadata --------- Co-authored-by: Tyler Whitney <[email protected]> * address feedback * small edits --------- Co-authored-by: Carson Radtke <[email protected]> Co-authored-by: TylerMSFT <[email protected]> Co-authored-by: Jill Grant <[email protected]> Co-authored-by: prmerger-automator[bot] <40007230+prmerger-automator[bot]@users.noreply.github.com> Co-authored-by: learn-build-service-prod[bot] <113403604+learn-build-service-prod[bot]@users.noreply.github.com> Co-authored-by: Nikita Leontiev <[email protected]> Co-authored-by: Learn Build Service GitHub App <Learn Build Service [email protected]> Co-authored-by: Courtney Wales <[email protected]> Co-authored-by: Emily Bao <[email protected]> Co-authored-by: Stacy Chambers <[email protected]> * 4/16/2025 AM Publish (#5876) * docs for justification in pragma warning * docs for gsl::suppress * teach gsl::suppress("rule") instead of gsl::suppress(rule) * doc - portion of flag * acrolinx * related to #5230 - call out buffer fill behavior * edit * acrolinx/link fix * Confirm merge from FromPublicMasterBranch to main to sync with https://github.com/MicrosoftDocs/cpp-docs (branch main) (#5870) * vswprintf/_vswprintf_l return value description update. * Return value/Remarks sections update. * Behavior summary update. * Behavior summary update. * Merge pull request #5867 from MicrosoftDocs/main 4/10/2025 AM Publish * Update behavior description for `buffer` and `count` conditions The behavior is slightly different than stated. * Update return value behavior for valid buffer behave is different than written here. * Clarify vswprintf return values for count zero behavior is a little different for count = 0 case. * Update remarks and behavior summary sections The behavior in debug mode applies to all functions on this page, so made more prominent. * Fix NULL character formatting in documentation * 4/11/2025 AM Publish (#5869) * doc - portion of flag * acrolinx --------- Co-authored-by: TylerMSFT <[email protected]> Co-authored-by: Jill Grant <[email protected]> * Clarify vswprintf behavior when count is zero * Standardize 'null' to 'NULL' --------- Co-authored-by: Nikita Leontiev <[email protected]> Co-authored-by: Bo wen Yang <[email protected]> Co-authored-by: learn-build-service-prod[bot] <113403604+learn-build-service-prod[bot]@users.noreply.github.com> Co-authored-by: Learn Build Service GitHub App <Learn Build Service [email protected]> Co-authored-by: Tyler Whitney <[email protected]> Co-authored-by: Jill Grant <[email protected]> Co-authored-by: Courtney Wales <[email protected]> * Add Arm64 forceInterlockedFunctions option (#5822) * Learn Editor: Update compiler-options-listed-by-category.md * Learn Editor: Update compiler-options-listed-alphabetically.md * Learn Editor: Update force-interlocked-functions.md * Learn Editor: Update force-interlocked-functions.md * update Metadata * Update force-interlocked-functions.md with github id author name * Reorder compiler options in toc.yml to be alphabetical * Learn Editor: Update compiler-options-listed-alphabetically.md * Learn Editor: Update compiler-options-listed-by-category.md * Learn Editor: Update force-interlocked-functions.md * change article metadata * Learn Editor: Update force-interlocked-functions.md * Fix casing in toc.yml for forceInterlockedFunctions * Add 'items' section to toc.yml to revert previous change * Fix indentation in toc.yml file * Update metadata and improve documentation wording * Update metadata in force-interlocked-functions.md tidied up metdata * Fix typos and improve clarity in documentation * Update description for `/forceInterlockedFunctions` option * Clarify CPU capability/ runtime description in documentation * Update remark on Armv8.0 instructions * Remove unneeded template comments and update livelock remarks in documentation * Add "---" to metadata --------- Co-authored-by: Tyler Whitney <[email protected]> * address feedback * small edits * Confirm merge from FromPublicMasterBranch to main to sync with https://github.com/MicrosoftDocs/cpp-docs (branch main) (#5874) * vswprintf/_vswprintf_l return value description update. * Return value/Remarks sections update. * Behavior summary update. * Behavior summary update. * Merge pull request #5867 from MicrosoftDocs/main 4/10/2025 AM Publish * Update behavior description for `buffer` and `count` conditions The behavior is slightly different than stated. * Update return value behavior for valid buffer behave is different than written here. * Clarify vswprintf return values for count zero behavior is a little different for count = 0 case. * Update remarks and behavior summary sections The behavior in debug mode applies to all functions on this page, so made more prominent. * Fix NULL character formatting in documentation * 4/11/2025 AM Publish (#5869) * doc - portion of flag * acrolinx --------- Co-authored-by: TylerMSFT <[email protected]> Co-authored-by: Jill Grant <[email protected]> * Clarify vswprintf behavior when count is zero * Standardize 'null' to 'NULL' * 4/14/2025 AM Publish (#5871) * doc - portion of flag * acrolinx * related to #5230 - call out buffer fill behavior * edit * acrolinx/link fix * Confirm merge from FromPublicMasterBranch to main to sync with https://github.com/MicrosoftDocs/cpp-docs (branch main) (#5870) * vswprintf/_vswprintf_l return value description update. * Return value/Remarks sections update. * Behavior summary update. * Behavior summary update. * Merge pull request #5867 from MicrosoftDocs/main 4/10/2025 AM Publish * Update behavior description for `buffer` and `count` conditions The behavior is slightly different than stated. * Update return value behavior for valid buffer behave is different than written here. * Clarify vswprintf return values for count zero behavior is a little different for count = 0 case. * Update remarks and behavior summary sections The behavior in debug mode applies to all functions on this page, so made more prominent. * Fix NULL character formatting in documentation * 4/11/2025 AM Publish (#5869) * doc - portion of flag * acrolinx --------- Co-authored-by: TylerMSFT <[email protected]> Co-authored-by: Jill Grant <[email protected]> * Clarify vswprintf behavior when count is zero * Standardize 'null' to 'NULL' --------- Co-authored-by: Nikita Leontiev <[email protected]> Co-authored-by: Bo wen Yang <[email protected]> Co-authored-by: learn-build-service-prod[bot] <113403604+learn-build-service-prod[bot]@users.noreply.github.com> Co-authored-by: Learn Build Service GitHub App <Learn Build Service [email protected]> Co-authored-by: Tyler Whitney <[email protected]> Co-authored-by: Jill Grant <[email protected]> Co-authored-by: Courtney Wales <[email protected]> --------- Co-authored-by: TylerMSFT <[email protected]> Co-authored-by: Jill Grant <[email protected]> Co-authored-by: prmerger-automator[bot] <40007230+prmerger-automator[bot]@users.noreply.github.com> Co-authored-by: learn-build-service-prod[bot] <113403604+learn-build-service-prod[bot]@users.noreply.github.com> Co-authored-by: Nikita Leontiev <[email protected]> Co-authored-by: Learn Build Service GitHub App <Learn Build Service [email protected]> Co-authored-by: Courtney Wales <[email protected]> * Fix typo VSCode -> VS Code * Fix wrong image file name in get-started-linux-cmake.md Fix the image file name for cmake-bullet3-linux-callstack.png for the call stack. * 4/15/2025 AM Publish (#5873) * docs for justification in pragma warning * docs for gsl::suppress * teach gsl::suppress("rule") instead of gsl::suppress(rule) * doc - portion of flag * acrolinx * related to #5230 - call out buffer fill behavior * edit * acrolinx/link fix * Confirm merge from FromPublicMasterBranch to main to sync with https://github.com/MicrosoftDocs/cpp-docs (branch main) (#5870) * vswprintf/_vswprintf_l return value description update. * Return value/Remarks sections update. * Behavior summary update. * Behavior summary update. * Merge pull request #5867 from MicrosoftDocs/main 4/10/2025 AM Publish * Update behavior description for `buffer` and `count` conditions The behavior is slightly different than stated. * Update return value behavior for valid buffer behave is different than written here. * Clarify vswprintf return values for count zero behavior is a little different for count = 0 case. * Update remarks and behavior summary sections The behavior in debug mode applies to all functions on this page, so made more prominent. * Fix NULL character formatting in documentation * 4/11/2025 AM Publish (#5869) * doc - portion of flag * acrolinx --------- Co-authored-by: TylerMSFT <[email protected]> Co-authored-by: Jill Grant <[email protected]> * Clarify vswprintf behavior when count is zero * Standardize 'null' to 'NULL' --------- Co-authored-by: Nikita Leontiev <[email protected]> Co-authored-by: Bo wen Yang <[email protected]> Co-authored-by: learn-build-service-prod[bot] <113403604+learn-build-service-prod[bot]@users.noreply.github.com> Co-authored-by: Learn Build Service GitHub App <Learn Build Service [email protected]> Co-authored-by: Tyler Whitney <[email protected]> Co-authored-by: Jill Grant <[email protected]> Co-authored-by: Courtney Wales <[email protected]> * Add Arm64 forceInterlockedFunctions option (#5822) * Learn Editor: Update compiler-options-listed-by-category.md * Learn Editor: Update compiler-options-listed-alphabetically.md * Learn Editor: Update force-interlocked-functions.md * Learn Editor: Update force-interlocked-functions.md * update Metadata * Update force-interlocked-functions.md with github id author name * Reorder compiler options in toc.yml to be alphabetical * Learn Editor: Update compiler-options-listed-alphabetically.md * Learn Editor: Update compiler-options-listed-by-category.md * Learn Editor: Update force-interlocked-functions.md * change article metadata * Learn Editor: Update force-interlocked-functions.md * Fix casing in toc.yml for forceInterlockedFunctions * Add 'items' section to toc.yml to revert previous change * Fix indentation in toc.yml file * Update metadata and improve documentation wording * Update metadata in force-interlocked-functions.md tidied up metdata * Fix typos and improve clarity in documentation * Update description for `/forceInterlockedFunctions` option * Clarify CPU capability/ runtime description in documentation * Update remark on Armv8.0 instructions * Remove unneeded template comments and update livelock remarks in documentation * Add "---" to metadata --------- Co-authored-by: Tyler Whitney <[email protected]> * address feedback * small edits --------- Co-authored-by: Carson Radtke <[email protected]> Co-authored-by: TylerMSFT <[email protected]> Co-authored-by: Jill Grant <[email protected]> Co-authored-by: prmerger-automator[bot] <40007230+prmerger-automator[bot]@users.noreply.github.com> Co-authored-by: learn-build-service-prod[bot] <113403604+learn-build-service-prod[bot]@users.noreply.github.com> Co-authored-by: Nikita Leontiev <[email protected]> Co-authored-by: Learn Build Service GitHub App <Learn Build Service [email protected]> Co-authored-by: Courtney Wales <[email protected]> Co-authored-by: Emily Bao <[email protected]> Co-authored-by: Stacy Chambers <[email protected]> --------- Co-authored-by: Nikita Leontiev <[email protected]> Co-authored-by: Bo wen Yang <[email protected]> Co-authored-by: learn-build-service-prod[bot] <113403604+learn-build-service-prod[bot]@users.noreply.github.com> Co-authored-by: Learn Build Service GitHub App <Learn Build Service [email protected]> Co-authored-by: Tyler Whitney <[email protected]> Co-authored-by: Jill Grant <[email protected]> Co-authored-by: Courtney Wales <[email protected]> Co-authored-by: prmerger-automator[bot] <40007230+prmerger-automator[bot]@users.noreply.github.com> Co-authored-by: Takashi Takebayashi <[email protected]> Co-authored-by: liginity <[email protected]> Co-authored-by: Carson Radtke <[email protected]> Co-authored-by: Emily Bao <[email protected]> Co-authored-by: Stacy Chambers <[email protected]> Co-authored-by: Diana Richards <[email protected]> --------- Co-authored-by: Carson Radtke <[email protected]> Co-authored-by: TylerMSFT <[email protected]> Co-authored-by: Jill Grant <[email protected]> Co-authored-by: prmerger-automator[bot] <40007230+prmerger-automator[bot]@users.noreply.github.com> Co-authored-by: learn-build-service-prod[bot] <113403604+learn-build-service-prod[bot]@users.noreply.github.com> Co-authored-by: Nikita Leontiev <[email protected]> Co-authored-by: Learn Build Service GitHub App <Learn Build Service [email protected]> Co-authored-by: Courtney Wales <[email protected]> Co-authored-by: Emily Bao <[email protected]> Co-authored-by: Stacy Chambers <[email protected]> Co-authored-by: Takashi Takebayashi <[email protected]> Co-authored-by: liginity <[email protected]> Co-authored-by: Diana Richards <[email protected]> * cl.exe CLI clarify default for space being allowed between option and arg * wordsmith per MS style --------- Co-authored-by: Nikita Leontiev <[email protected]> Co-authored-by: Bo wen Yang <[email protected]> Co-authored-by: learn-build-service-prod[bot] <113403604+learn-build-service-prod[bot]@users.noreply.github.com> Co-authored-by: Learn Build Service GitHub App <Learn Build Service [email protected]> Co-authored-by: Tyler Whitney <[email protected]> Co-authored-by: Jill Grant <[email protected]> Co-authored-by: Courtney Wales <[email protected]> Co-authored-by: prmerger-automator[bot] <40007230+prmerger-automator[bot]@users.noreply.github.com> Co-authored-by: Takashi Takebayashi <[email protected]> Co-authored-by: liginity <[email protected]> Co-authored-by: Carson Radtke <[email protected]> Co-authored-by: Emily Bao <[email protected]> Co-authored-by: Stacy Chambers <[email protected]> Co-authored-by: Diana Richards <[email protected]> Co-authored-by: Mitch Capper <[email protected]> * use the modern way * add see also * fix links * Replace with Tyler's suggestion to avoid passive voice. Also quick-fixed preexisting missing hyphens in 'floating-point'. * remove std.filesystem * acrolinx * clarify what arm architecture means * spacing * add note formatting * casing, code escape * acrolinx --------- Co-authored-by: Carson Radtke <[email protected]> Co-authored-by: TylerMSFT <[email protected]> Co-authored-by: Jill Grant <[email protected]> Co-authored-by: prmerger-automator[bot] <40007230+prmerger-automator[bot]@users.noreply.github.com> Co-authored-by: learn-build-service-prod[bot] <113403604+learn-build-service-prod[bot]@users.noreply.github.com> Co-authored-by: Nikita Leontiev <[email protected]> Co-authored-by: Learn Build Service GitHub App <Learn Build Service [email protected]> Co-authored-by: Courtney Wales <[email protected]> Co-authored-by: Emily Bao <[email protected]> Co-authored-by: Stacy Chambers <[email protected]> Co-authored-by: Amy Wishnousky <[email protected]> Co-authored-by: Takashi Takebayashi <[email protected]> Co-authored-by: liginity <[email protected]> Co-authored-by: Diana Richards <[email protected]> Co-authored-by: Mitch Capper <[email protected]> Co-authored-by: James Barnett <[email protected]>
1 parent 201af13 commit 1dae365

File tree

4 files changed

+22
-20
lines changed

4 files changed

+22
-20
lines changed

‎docs/build/common-visual-cpp-arm-migration-issues.md

Lines changed: 18 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -2,28 +2,30 @@
22
description: "Learn more about: Common Visual C++ ARM Migration Issues"
33
title: "Common Visual C++ ARM Migration Issues"
44
ms.date: "05/06/2019"
5-
ms.assetid: 0f4c434e-0679-4331-ba0a-cc15dd435a46
65
---
7-
# Common Visual C++ ARM Migration Issues
6+
# Common Visual C++ ARM migration issues
87

9-
When using the Microsoft C++ compiler (MSVC), the same C++ source code might produce different results on the ARM architecture than it does on x86 or x64 architectures.
8+
This document describes some of the common issues that you might encounter when you migrate code from x86 or x64 architectures to the ARM architecture. It also describes how to avoid these issues, and how to use the compiler to help identify them.
9+
10+
> [!NOTE]
11+
> When this article refers to the ARM architecture, it applies to both ARM32 and ARM64.
1012
1113
## Sources of migration issues
1214

1315
Many issues that you might encounter when you migrate code from the x86 or x64 architectures to the ARM architecture are related to source-code constructs that might invoke undefined, implementation-defined, or unspecified behavior.
1416

15-
*Undefined behavior* is behavior that the C++ standard does not define, and that's caused by an operation that has no reasonable result: for example, converting a floating-point value to an unsigned integer, or shifting a value by a number of positions that is negative or exceeds the number of bits in its promoted type.
17+
*Undefined behavior* is behavior that the C++ standard doesn't define, and that's caused by an operation that has no reasonable result: for example, converting a floating-point value to an unsigned integer, or shifting a value by a number of positions that is negative or exceeds the number of bits in its promoted type.
1618

1719
*Implementation-defined behavior* is behavior that the C++ standard requires the compiler vendor to define and document. A program can safely rely on implementation-defined behavior, even though doing so might not be portable. Examples of implementation-defined behavior include the sizes of built-in data types and their alignment requirements. An example of an operation that might be affected by implementation-defined behavior is accessing the variable arguments list.
1820

19-
*Unspecified behavior* is behavior that the C++ standard leaves intentionally non-deterministic. Although the behavior is considered non-deterministic, particular invocations of unspecified behavior are determined by the compiler implementation. However, there is no requirement for a compiler vendor to predetermine the result or guarantee consistent behavior between comparable invocations, and there is no requirement for documentation. An example of unspecified behavior is the order in which sub-expressions, which include arguments to a function call, are evaluated.
21+
*Unspecified behavior* is behavior that the C++ standard leaves intentionally nondeterministic. Although the behavior is considered nondeterministic, particular invocations of unspecified behavior are determined by the compiler implementation. However, there's no requirement for a compiler vendor to predetermine the result or guarantee consistent behavior between comparable invocations, and there's no requirement for documentation. An example of unspecified behavior is the order in which sub-expressions, which include arguments to a function call, are evaluated.
2022

21-
Other migration issues can be attributed to hardware differences between ARM and x86 or x64 architectures that interact with the C++ standard differently. For example, the strong memory model of the x86 and x64 architecture gives **`volatile`**-qualified variables some additional properties that have been used to facilitate certain kinds of inter-thread communication in the past. But the ARM architecture's weak memory model doesn't support this use, nor does the C++ standard require it.
23+
Other migration issues can be attributed to hardware differences between ARM and x86 or x64 architectures that interact with the C++ standard differently. For example, the strong memory model of the x86 and x64 architecture gives **`volatile`**-qualified variables some extra properties that have been used to facilitate certain kinds of inter-thread communication in the past. But the ARM architecture's weak memory model doesn't support this use, nor does the C++ standard require it.
2224

2325
> [!IMPORTANT]
24-
> Although **`volatile`** gains some properties that can be used to implement limited forms of inter-thread communication on x86 and x64, these additional properties are not sufficient to implement inter-thread communication in general. The C++ standard recommends that such communication be implemented by using appropriate synchronization primitives instead.
26+
> Although **`volatile`** gains some properties that can be used to implement limited forms of inter-thread communication on x86 and x64, these properties aren't sufficient to implement inter-thread communication in general. The C++ standard recommends that such communication be implemented by using appropriate synchronization primitives instead.
2527
26-
Because different platforms might express these kinds of behavior differently, porting software between platforms can be difficult and bug-prone if it depends on the behavior of a specific platform. Although many of these kinds of behavior can be observed and might appear stable, relying on them is at least non-portable, and in the cases of undefined or unspecified behavior, is also an error. Even the behavior that's cited in this document should not be relied on, and could change in future compilers or CPU implementations.
28+
Because different platforms might express these kinds of behavior differently, porting software between platforms can be difficult and bug-prone if it depends on the behavior of a specific platform. Although many of these kinds of behavior can be observed and might appear stable, relying on them is at least non-portable, and in the cases of undefined or unspecified behavior, is also an error. Even the behavior cited in this document shouldn't be relied on, and could change in future compilers or CPU implementations.
2729

2830
## Example migration issues
2931

@@ -41,15 +43,15 @@ These platforms also differ in how they handle conversion of NaN (Not-a-Number)
4143

4244
Floating-point conversion can only be relied on if you know that the value is within the range of the integer type that it's being converted to.
4345

44-
### Shift operator (\<\< >>) behavior
46+
### Shift operator (`<<` `>>`) behavior
4547

46-
On the ARM architecture, a value can be shifted left or right up to 255 bits before the pattern begins to repeat. On x86 and x64 architectures, the pattern is repeated at every multiple of 32 unless the source of the pattern is a 64-bit variable; in that case, the pattern repeats at every multiple of 64 on x64, and every multiple of 256 on x86, where a software implementation is employed. For example, for a 32-bit variable that has a value of 1 shifted left by 32 positions, on ARM the result is 0, on x86 the result is 1, and on x64 the result is also 1. However, if the source of the value is a 64-bit variable, then the result on all three platforms is 4294967296, and the value doesn't "wrap around" until it's shifted 64 positions on x64, or 256 positions on ARM and x86.
48+
On the ARM architecture, a value can be shifted left or right up to 255 bits before the pattern begins to repeat. On x86 and x64 architectures, the pattern is repeated at every multiple of 32 unless the source of the pattern is a 64-bit variable. In that case, the pattern repeats at every multiple of 64 on x64, and every multiple of 256 on x86, where a software implementation is employed. For example, for a 32-bit variable that has a value of 1 shifted left by 32 positions, on ARM the result is 0, on x86 the result is 1, and on x64 the result is also 1. However, if the source of the value is a 64-bit variable, then the result on all three platforms is 4294967296, and the value doesn't "wrap around" until it's shifted 64 positions on x64, or 256 positions on ARM and x86.
4749

48-
Because the result of a shift operation that exceeds the number of bits in the source type is undefined, the compiler is not required to have consistent behavior in all situations. For example, if both operands of a shift are known at compile time, the compiler may optimize the program by using an internal routine to precompute the result of the shift and then substituting the result in place of the shift operation. If the shift amount is too large, or negative, the result of the internal routine might be different than the result of the same shift expression as executed by the CPU.
50+
Because the result of a shift operation that exceeds the number of bits in the source type is undefined, the compiler isn't required to have consistent behavior in all situations. For example, if both operands of a shift are known at compile time, the compiler may optimize the program by using an internal routine to precompute the result of the shift and then substituting the result in place of the shift operation. If the shift amount is too large, or negative, the result of the internal routine might be different than the result of the same shift expression as executed by the CPU.
4951

5052
### Variable arguments (varargs) behavior
5153

52-
On the ARM architecture, parameters from the variable arguments list that are passed on the stack are subject to alignment. For example, a 64-bit parameter is aligned on a 64-bit boundary. On x86 and x64, arguments that are passed on the stack are not subject to alignment and pack tightly. This difference can cause a variadic function like `printf` to read memory addresses that were intended as padding on ARM if the expected layout of the variable arguments list is not matched exactly, even though it might work for a subset of some values on the x86 or x64 architectures. Consider this example:
54+
On the ARM architecture, parameters from the variable arguments list that are passed on the stack are subject to alignment. For example, a 64-bit parameter is aligned on a 64-bit boundary. On x86 and x64, arguments that are passed on the stack aren't subject to alignment and pack tightly. This difference can cause a variadic function like `printf` to read memory addresses that were intended as padding on ARM if the expected layout of the variable arguments list isn't matched exactly, even though it might work for a subset of some values on the x86 or x64 architectures. Consider this example:
5355

5456
```C
5557
// notice that a 64-bit integer is passed to the function, but '%d' is used to read it.
@@ -69,7 +71,7 @@ printf("%I64d\n", 1LL);
6971

7072
Because ARM, x86, and x64 processors are so different, they can present different requirements to compiler implementations, and also different opportunities for optimizations. Because of this, together with other factors like calling-convention and optimization settings, a compiler might evaluate function arguments in a different order on different architectures or when the other factors are changed. This can cause the behavior of an app that relies on a specific evaluation order to change unexpectedly.
7173

72-
This kind of error can occur when arguments to a function have side effects that impact other arguments to the function in the same call. Usually this kind of dependency is easy to avoid, but it can sometimes be obscured by dependencies that are difficult to discern, or by operator overloading. Consider this code example:
74+
This kind of error can occur when arguments to a function have side effects that impact other arguments to the function in the same call. Usually this kind of dependency is easy to avoid but can be obscured by dependencies that are difficult to discern or by operator overloading. Consider this code example:
7375

7476
```cpp
7577
handle memory_handle;
@@ -83,15 +85,15 @@ This appears well-defined, but if `->` and `*` are overloaded operators, then th
8385
Handle::acquire(operator->(memory_handle), operator*(p));
8486
```
8587

86-
And if there's a dependency between `operator->(memory_handle)` and `operator*(p)`, the code might rely on a specific evaluation order, even though the original code looks like there is no possible dependency.
88+
And if there's a dependency between `operator->(memory_handle)` and `operator*(p)`, the code might rely on a specific evaluation order, even though the original code looks like there's no possible dependency.
8789

88-
### volatile keyword default behavior
90+
### `volatile` keyword default behavior
8991

9092
The MSVC compiler supports two different interpretations of the **`volatile`** storage qualifier that you can specify by using compiler switches. The [/volatile:ms](reference/volatile-volatile-keyword-interpretation.md) switch selects the Microsoft extended volatile semantics that guarantee strong ordering, as has been the traditional case for x86 and x64 because of the strong memory model on those architectures. The [/volatile:iso](reference/volatile-volatile-keyword-interpretation.md) switch selects the strict C++ standard volatile semantics that don't guarantee strong ordering.
9193

9294
On the ARM architecture (except ARM64EC), the default is **/volatile:iso** because ARM processors have a weakly ordered memory model, and because ARM software doesn't have a legacy of relying on the extended semantics of **/volatile:ms** and doesn't usually have to interface with software that does. However, it's still sometimes convenient or even required to compile an ARM program to use the extended semantics. For example, it may be too costly to port a program to use the ISO C++ semantics, or driver software might have to adhere to the traditional semantics to function correctly. In these cases, you can use the **/volatile:ms** switch; however, to recreate the traditional volatile semantics on ARM targets, the compiler must insert memory barriers around each read or write of a **`volatile`** variable to enforce strong ordering, which can have a negative impact on performance.
9395

94-
On the x86, x64 and ARM64EC architectures, the default is **/volatile:ms** because much of the software that has already been created for these architectures by using MSVC relies on them. When you compile x86, x64 and ARM64EC programs, you can specify the **/volatile:iso** switch to help avoid unnecessary reliance on the traditional volatile semantics, and to promote portability.
96+
On the x86, x64, and ARM64EC architectures, the default is **/volatile:ms** because much of the software that has already been created for these architectures by using MSVC relies on them. When you compile x86, x64 and ARM64EC programs, you can specify the **/volatile:iso** switch to help avoid unnecessary reliance on the traditional volatile semantics, and to promote portability.
9597

9698
## See also
9799

‎docs/build/reference/sourcedependencies-directives.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ helpviewer_keywords: ["/sourceDependencies:directives compiler option", "/source
99
---
1010
# `/sourceDependencies:directives` (List module and header unit dependencies)
1111

12-
This command-line option scans source files and their `#include` statements to generate a JSON file that lists module export and imports. This information can be used by a build system to determine the build order of modules and header units.
12+
This command-line option scans source files and their `#include` statements to generate a JSON file that lists module export and imports. A build system can use this information to determine the build order of modules and header units.
1313

1414
This option differs from [`/sourceDependencies`](sourcedependencies.md) in the following ways:
1515

@@ -99,7 +99,7 @@ No *`.ifc`* files are listed in the output because they weren't built. Unlike `/
9999

100100
## To set this compiler option in Visual Studio
101101

102-
You normally shouldn't set this option yourself in the Visual Studio development environment. It's set by the build system.
102+
You normally shouldn't set this option yourself in the Visual Studio development environment. The build system sets it.
103103

104104
## See also
105105

‎docs/cpp/import-export-module.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -40,7 +40,7 @@ namespace ModuleA_NS
4040
}
4141
```
4242

43-
Non-exported names aren't visible to code that imports the module:
43+
Nonexported names aren't visible to code that imports the module:
4444

4545
```cpp
4646
import ModuleA;

‎docs/cpp/modules-cpp.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -106,7 +106,7 @@ The **`export`** keyword is only used in interface files. An implementation file
106106

107107
The rules for namespaces in modules are the same as any other code. If a declaration within a namespace is exported, the enclosing namespace (excluding members that aren't explicitly exported in that namespace) is also implicitly exported. If a namespace is explicitly exported, all declarations within that namespace definition are exported.
108108

109-
When the compiler does argument-dependent lookup for overload resolutions in the importing translation unit, it considers functions declared in the same translation unit (including module interfaces) as where the type of the function's arguments are defined.
109+
When the compiler does argument-dependent lookup for overload resolution in the importing translation unit, it considers functions declared in the same translation unit (including module interfaces) as where the type of the function's arguments is defined.
110110

111111
### Module partitions
112112

0 commit comments

Comments
 (0)