为什么strcpy（）和strcat（）在嵌入式域中不好用
在这里，我想了解strcpy() and strcat()缺点
我想了解嵌入式域/环境中的这些function危险区域。
有人告诉我，我们从不在嵌入域中使用strcpy,strcat and strlen函数，因为它以null结尾，有时我们处理加密数据和null字符，所以我们无法获得实际结果，因为这些函数停止在null字符上。
所以我想知道这些function的所有东西和其他替代品。 我们如何使用其他替代function
str *函数适用于字符串。 如果您正在处理字符串，只要您正确使用它们就可以使用它们 – 如果您错误地使用它们，很容易创建缓冲区溢出 。
如果你正在处理二进制数据，听起来就像你一样，字符串处理函数是不合适的（它们毕竟是用于字符串，而不是二进制数据）。 使用mem *函数处理二进制数据。
在C中，字符串是以nul字节结尾的字符序列。 如果您正在处理二进制数据，那么很可能是该数据中值为0的char，字符串处理函数假定为字符串的结尾，或者数据不包含任何nul字节且不是nul终止，这将导致字符串函数超过缓冲区的末尾。
好吧，这些函数确实复制了以null结尾的字符串，而不仅仅是在嵌入式域中。 根据您的需要，您可能希望使用mem*函数。
正如其他人已经回答的那样，他们可以正常使用琴弦。 加密数据不能视为字符串。
然而，在嵌入式系统中使用任何 C库函数的方面，特别是在高完整性实时嵌入式系统中，例如汽车/医疗/航空电子设备等。在这些项目中，将使用编码标准，例如MISRA- C。
绝大多数C库可能与您的编码标准不兼容。 即使你有选择（至少在MISRA-C中）做出偏差，你仍然需要validation整个库。 例如，您必须validation整个string.h，因为您使用了strlen（）。 这种系统中的常见做法是自己编写所有函数，特别是像strlen（）这样的简单函数，您可以在一分钟内自己编写。
但是大多数嵌入式系统对质量和安全性没有如此高的要求，因此库函数更受欢迎。 特别是memcpy（）和类似的搜索/排序/移动函数，可能会被编译器大量优化。
如果您担心覆盖缓冲区（每个人都应该这样做），请改用strncpy或strncat 。 我认为strlen没问题。
此问题特定于您描述的系统，而不是嵌入式系统本身。 无论哪种方式，字符串函数都不适合您描述的应用程序。 我认为您应该被告知您不能在特定应用程序的加密数据上使用字符串函数。 这不是嵌入式系统甚至是字符串库的问题。 这完全取决于您加密字符串的性质 – 它们在加密后不再是C字符串，因此任何字符串库操作都将不再有效 – 它只是数据，您有责任保留任何必要的元数据例如，您可以使用Pascal样式字符串来执行此操作（使用合适的附带库）。
现在一般来说，C字符串库和C字符串本身为所有系统提出了许多问题，而不仅仅是嵌入式问题。 请参阅Joel Spolsky撰写的这篇文章，了解为什么在使用C字符串函数时应该谨慎使用，尤其是strcat（）。
原因就是你所说的：
因为它以null结尾，有时我们处理加密数据和null字符，所以我们无法获得实际结果，因为这些函数停止在null字符上。
而对于替代品，我推荐strn*系列，如strncpy ， strnlen 。 这里n表示字符串的最大可能长度。
您可能希望找到C标准库引用并寻找有关这些strn*函数的一些详细信息。
正如其他人所说，str *函数用于字符串，而不是二进制数据。
但是，我建议你在使用字符串时，应该考虑使用strlcpy（）而不是strcpy（）和strlcat（）而不是strcat（）。
它们不是标准function，但你可以很容易地找到它们的副本（或者只是自己编写）。 它们将目标缓冲区的大小作为其标准同类的额外参数，旨在避免缓冲区溢出。
无论你在哪里使用它，都可能需要传递一个指针块的大小，但我担心这就是用C编程的。
至少在我们获得更聪明的指针之前。