_strdate_s
, _wstrdate_s
將目前的系統日期複製到緩衝區。 這些函式是 的版本 _strdate
, _wstrdate
具有 CRT 中安全性功能中所述 的安全性增強功能。
語法
errno_t _strdate_s(
char *buffer,
size_t size
);
errno_t _wstrdate_s(
wchar_t *buffer,
size_t size
);
template <size_t size>
errno_t _strdate_s(
char (&buffer)[size]
); // C++ only
template <size_t size>
errno_t _wstrdate_s(
wchar_t (&buffer)[size]
); // C++ only
參數
buffer
要放置格式化日期字串之緩衝區的指標。
size
以字元單位表示的緩衝區大小。
傳回值
如果成功,則為零。 如果失敗,傳回值就是錯誤碼。 錯誤碼在 EERRNO.H 中定義,請參閱下表查看此函式產生的確切錯誤。 如需錯誤碼的詳細資訊,請參閱 errno
。
錯誤條件
buffer |
size |
傳回 | buffer 的內容。 |
---|---|---|---|
NULL |
(任何) | EINVAL |
未修改 |
不是 NULL (指向有效的緩衝區) |
0 | EINVAL |
未修改 |
不是 NULL (指向有效的緩衝區) |
0 <size < 9 |
EINVAL |
空字串 |
不是 NULL (指向有效的緩衝區) |
size >= 9 |
0 | 目前的日期格式一如<備註>所指定 |
安全性問題
如果您針對 傳入不正確非 Null 值 buffer
,則如果 size
參數大於九,則會導致存取違規。
傳遞的值 size
大於緩衝區滿溢中實際大小 buffer
的結果。
備註
這些函式提供 _strdate
和 _wstrdate
的更安全版本。 函 _strdate_s
式會將目前的系統日期複製到 所指向的 buffer
緩衝區。 其格式為 mm/dd/yy
,其中 mm
是兩位數月份, dd
是兩位數的日期,而 yy
是年份的最後兩位數。 例如,字串 12/05/99
代表 1999 年 12 月 5 日。 緩衝區長度必須至少為九個字元。
_wstrdate_s
是 _strdate_s
的寬字元版本,_wstrdate_s
的引數與傳回值是寬字元字串。 除此之外,這些函式的行為相同。
當 buffer
是 NULL
指標或 size
少於九個字元時,會叫用不正確參數處理常式。 參數驗證 中所述 。 如果允許繼續執行,這些函式會傳回 -1。 如果緩衝區為 NULL
或 size
小於或等於 0,則設定 errno
EINVAL
為 。 或者,如果 size
小於 9,則設定 errno
為 ERANGE
。
在 C++ 中,範本多載可簡化這些函式的使用。 多載可以自動推斷緩衝區長度,而不需要指定 size
引數。 而且,他們可以使用較新的、更安全的對應專案來自動取代非安全函式。 如需詳細資訊,請參閱 保護範本多載 。
這些函式的偵錯程式庫版本會先將緩衝區填入0xFE。 若要停用此行為,請使用 _CrtSetDebugFillThreshold
。
根據預設,此函式的全域狀態會限定于應用程式。 若要變更此行為,請參閱 CRT 中的全域狀態。
泛型文字常式對應:
TCHAR.H 常式 | _UNICODE 和 _MBCS 未定義 |
_MBCS 定義 |
_UNICODE 定義 |
---|---|---|---|
_tstrdate_s |
_strdate_s |
_strdate_s |
_wstrdate_s |
需求
常式 | 必要的標頭 |
---|---|
_strdate |
<time.h> |
_wstrdate |
<time.h > 或 < wchar.h> |
_strdate_s |
<time.h> |
範例
請參閱 的 time
範例。
另請參閱
時間管理
asctime_s
, _wasctime_s
ctime_s
, _ctime32_s
, _ctime64_s
, _wctime_s
, _wctime32_s
, _wctime64_s
gmtime_s
, _gmtime32_s
, _gmtime64_s
localtime_s
, _localtime32_s
, _localtime64_s
mktime
, _mktime32
, _mktime64
time
, _time32
, _time64
_tzset
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應