c语言 - 带有"易失性"数组的"memcpy((void *)dest， src， n)&q

Question

我有一个用于UART的缓冲区，它是这样声明的：

union   Eusart_Buff {
uint8_t     b8[16];
uint16_t    b9[16];
};
struct  Eusart_Msg {
uint8_t             msg_posn;
uint8_t             msg_len;
union Eusart_Buff   buff;
};
struct  Eusart {
struct Eusart_Msg   tx;
struct Eusart_Msg   rx;
};
extern  volatile    struct Eusart   eusart;

这是填充缓冲区的函数(将使用中断发送)：

void    eusart_msg_transmit (uint8_t n, void *msg)
{
if (!n)
return;
/*
* The end of the previous transmission will reset
* eusart.tx.msg_len (i.e. ISR is off)
*/
while (eusart.tx.msg_len)
;
if (data_9b) {
memcpy((void *)eusart.tx.buff.b9, msg,
sizeof(eusart.tx.buff.b9[0]) * n);
} else {
memcpy((void *)eusart.tx.buff.b8, msg,
sizeof(eusart.tx.buff.b8[0]) * n);
}
eusart.tx.msg_len   = n;
eusart.tx.msg_posn  = 0;
reg_PIE1_TXIE_write(true);
}

在使用memcpy()的那一刻，我知道没有其他人会使用缓冲区(原子)，因为while循环确保已发送最后一条消息，因此中断被禁用。

以这种方式抛弃volatile以便我能够使用memcpy()是否安全，或者我应该创建一个可能调用memcpy_v()这样的函数以确保安全？

void *memcpy_vin(void *dest, const volatile void *src, size_t n)
{
const volatile char *src_c  = (const volatile char *)src;
char *dest_c                = (char *)dest;
for (size_t i = 0; i < n; i++)
dest_c[i]   = src_c[i];
return  dest;
}
volatile void *memcpy_vout(volatile void *dest, const void *src, size_t n)
{
const char *src_c       = (const char *)src;
volatile char *dest_c   = (volatile char *)dest;
for (size_t i = 0; i < n; i++)
dest_c[i]   = src_c[i];
return  dest;
}
volatile void *memcpy_v(volatile void *dest, const volatile void *src, size_t n)
{
const volatile char *src_c  = (const volatile char *)src;
volatile char *dest_c       = (volatile char *)dest;
for (size_t i = 0; i < n; i++)
dest_c[i]   = src_c[i];
return  dest;
}

编辑：

如果我需要这些新功能， 鉴于我知道没有人会同时修改数组，使用restrict来帮助编译器优化(如果可以)是否有意义？ 可能是这样(如果我错了，请纠正我)：

volatile void *memcpy_v(restrict volatile void *dest,
const restrict volatile void *src,
size_t n)
{
const restrict volatile char *src_c = src;
restrict volatile char *dest_c      = dest;
for (size_t i = 0; i < n; i++)
dest_c[i]   = src_c[i];
return  dest;
}

编辑 2(添加上下文)：

void    eusart_end_transmission (void)
{
reg_PIE1_TXIE_write(false); /* TXIE is TX interrupt enable */
eusart.tx.msg_len   = 0;
eusart.tx.msg_posn  = 0;
}
void    eusart_tx_send_next_c   (void)
{
uint16_t    tmp;
if (data_9b) {
tmp     = eusart.tx.buff.b9[eusart.tx.msg_posn++];
reg_TXSTA_TX9D_write(tmp >> 8);
TXREG   = tmp;
} else {
TXREG   = eusart.tx.buff.b8[eusart.tx.msg_posn++];
}
}
void __interrupt()  isr(void)
{
if (reg_PIR1_TXIF_read()) {
if (eusart.tx.msg_posn >= eusart.tx.msg_len)
eusart_end_transmission();
else
eusart_tx_send_next_c();
}
}

尽管可能不需要volatile(我在另一个问题中问过：仅在 ISR 中读取的变量的易失性？，这个问题仍然应该在需要volatile的假设中回答，以便真正需要volatile的未来用户(例如我在实现 RX 缓冲区时)可以知道该怎么做。

---

编辑(相关)(7月19日)：

中断的易失性与内存屏障

基本上说不需要volatile，因此这个问题消失了。

Answer 1

使用volatile数组memcpy((void *)dest, src, n)安全吗？

不。 在一般情况下，未指定memcpy()以在易失性内存中正常工作。
OP的情况看起来可以抛弃volatile，但发布的代码不足以确定。

如果代码想要memcpy()volatile内存，请编写帮助程序函数。

OP 的代码restrict在错误的位置。 建议

volatile void *memcpy_v(volatile void *restrict dest,
const volatile void *restrict src, size_t n) {
const volatile unsigned char *src_c = src;
volatile unsigned char *dest_c      = dest;
while (n > 0) {
n--;
dest_c[n] = src_c[n];
}
return  dest;
}

编写自己的memcpy_v()的唯一原因是编译器可以"理解"/分析memcpy()并发出与预期非常不同的代码 - 如果编译器认为不需要副本，甚至可以对其进行优化。提醒自己，编译器认为memcpy()操纵的内存是非易失性的。

---

然而，OP错误地使用了volatile struct Eusart eusart;。 对eusart的访问需要volatile不提供的保护。

在OP的情况下，代码可以volatile放在缓冲区上，然后使用memcpy()就可以了。

剩下的问题是 OP 如何使用eusart的代码很少。 使用volatile并不能解决OP的问题。 OP确实断言"我以原子方式写入它"，但没有发布atomic代码，这是不确定的。

---

像下面这样的代码的好处是eusart.tx.msg_lenvolatile，但这还不够。volatile确保.tx.msg_len不会被缓存，而是每次重新读取。

while (eusart.tx.msg_len)
;

然而，.tx.msg_len的读取并未指定为原子读取。 当.tx.msg_len == 256和 ISR 触发时，递减.tx.msg_lenLSbyte(从 256 到 0)和 MSbyte(从 255 开始 0)的读取，非 ISR 代码可能会.tx.msg_len视为 0，而不是 255 或 256，从而在错误的时间结束循环。.tx.msg_len的访问需要指定为不可分割(原子)，否则，偶尔代码会神秘失败。

while (eusart.tx.msg_len);也遭受了无休止循环的困扰。 如果传输因空以外的某种原因停止，则 while 循环永远不会退出。

建议改为在检查或更改eusart.tx.msg_len, eusart.tx.msg_posn时阻止中断。 查看编译器对atomic或

size_t tx_msg_len(void) {
// pseudo-code
interrupt_enable_state = get_state();
disable_interrupts();
size_t len = eusart.tx.msg_len;
restore_state(interrupt_enable_state);
return len;
}

---

一般通信代码思想：

1. 当非 ISR 代码读取或写入eusart时，请确保 ISR 永远不会更改eusart。

2. 不要在步骤 #1 中长时间阻止ISR。

3. 不要假设底层ISR()将成功链接输入/输出而不会打嗝。 顶级代码应该准备好在输出停止时重新启动输出。

Answer 2

该标准缺乏程序员可以要求在执行特定volatile指针访问之前完成通过普通指针访问存储区域的操作的任何方法，并且也缺乏任何确保通过普通指针访问存储区域的操作在执行某些特定volatile指针访问之前不会执行的方法。 由于volatile操作的语义是实现定义的，因此该标准的作者可能期望编译器编写者能够识别其客户何时可能需要此类语义，并以与这些需求一致的方式指定其行为。 不幸的是，这并没有发生。

实现你需要的语义要么使用"流行的扩展"，比如 clang 的-fms-volatile模式，一个特定于编译器的内部函数，要么用效率非常低的东西替换memcpy，以至于淹没编译器可能通过不支持此类语义获得的任何假定优势。

Answer 3

C17 标准在第 6.7.3 节"类型限定符"中这样说：

如果尝试通过使用具有非可变限定类型的左值来引用使用可变限定类型定义的对象，则行为是未定义的。¹³⁵⁾

¹³⁵⁾这适用于那些行为就像是用限定类型定义的对象，即使它们实际上从未被定义过。 定义为程序中的对象(例如内存映射输入/输出地址处的对象)。

所以不，这不安全。