替代POSIX-unconformant系统上的ssize_t

cad*_*luk 6 c posix

我正在写一个程序,涉及网络I/O,所以sendrecv使用,这是POSIX功能.它们返回a ssize_t,也是POSIX特有的.
包装器看起来像这个ATM:

ssize_t sock_send(int sock, const void* msg, size_t len) {
    return send(sock, msg, len, 0);
}
Run Code Online (Sandbox Code Playgroud)

尽管我在当前的实现中严重依赖POSIX,但我希望使接口更贴近标准,因为我计划稍后编写一个Windows实现,其中POSIX不一定可用(该死的,Windows!).

ssize_t根据C11标准的规定,什么是一个很好的替代品?也许ptrdiff_t吧?
或者我该如何处理这个问题呢?

chq*_*lie 5

如果ssize_t未定义类型,您可以自己定义它.它应该是一个signed大小相同的类型size_t.从技术上讲,类型ptrdiff_t不应小于size_t,但它可以更大,以适应更大的范围.

这是一种可移植的方式来定义它:

#include <limits.h>
#include <stddef.h>

#if SIZE_MAX == UINT_MAX
typedef int ssize_t;        /* common 32 bit case */
#elif SIZE_MAX == ULONG_MAX
typedef long ssize_t;       /* linux 64 bits */
#elif SIZE_MAX == ULLONG_MAX
typedef long long ssize_t;  /* windows 64 bits */
#elif SIZE_MAX == USHRT_MAX
typedef short ssize_t;      /* is this even possible? */
#else
#error platform has exotic SIZE_MAX
#endif
Run Code Online (Sandbox Code Playgroud)

  • 我知道至少有一个平台会失败:在 MSP430X 微控制器上,一些工具链(特别是 gcc 工具链的最新版本)使用 `uint20_t` 表示 `size_t`,使用 `int20_t` 表示 `ssize_t`。 (3认同)
  • @fuz `uint20_t` 和 8 位 `char` 看起来不兼容,因为 `uintN_t` 和 `char` 不应该有填充,并且位宽 20 不是位宽 8 的倍数。嗯。 (2认同)