C代码32到64位类型转换

乡亲们 我试图理解以下代码中是否有任何东西会导致它在64位平台上失败。我主要关心的是是否发生了一些不适合64位的类型转换。不要太注意分配给变量的实际数字，因为我只是为了这个例子而编的。我主要关心的是

long和int以及size\t

之间发生的类型转换问题，以及您可能看到的任何其他问题

#define NL_AREA 40      
#define NS_AREA 38     
#define NB_EXTRA (1536 - NS_AREA * NL_AREA) 

main()
{
    long int  bufsize;
    int       obssize, nelm, nbuf;
    int ncol, ndet = 10;
    void      *result;

    obssize = xxx; /* some size */
    bufsize = (long)obssize * (NL_AREA * NS_AREA + NB_EXTRA);
    ncol = 50;
    nbuf = ncol * ndet;
    nelm = 1;
    result = Buf_Init(bufsize, nelm, nbuf);
}

void * 
Buf_Init( size_t elm_size, 
          int    nelm_buf, 
          long   nbuf )
{
    long buf_size;
    void *p;
    buf_size = ((long) elm_size) * nelm_buf;
    if ((p = (void *)malloc(buf_size)) == NULL)
      return NULL;
    else
      return p;
}

---

我可以评论类型转换，但是。。。既然可以完全避免，为什么还要考虑代码中意外的类型转换呢？如果可移植性很重要，那么不要使用默认的基本数据类型。改用stdint.h

• 将

  int

  交换为

  int32\t

• 将

  long

  交换为

  int32\t

• 保持大小不变，或者在重要的情况下将其替换为

  uint32\u t

  。很可能不是

突然，代码变成了100%可移植的

其他意见：

• 为什么要做

  （void*）malloc（buf_size）

  ？从

  void*

  到

  void*

  的转换没有任何意义
• 对于托管系统，main（）必须始终返回

  int

  。隐式int在15年前就从C语言中删除了

---

看起来还可以，但是对于所有与尺寸相关的变量，您应该坚持使用

size\t

（即，不要使用

long

）。然后你就可以扔掉很多无用的和潜在危险的铸型。也不要强制转换

malloc

的结果。强制转换malloc返回到

void*

与创建

int x=some\u literal相同inty=（int）x。将某个类型转换为同一类型没有任何意义。有关转换
malloc
结果的详细信息：此类型转换问题是否也对calloc有效？是的，在C中，不应转换返回
void*
的函数的结果。C++是一个不同的故事，谢谢类型评论。你的意思是用
int32\t
替换
int和long
？main（）的问题没有问题。我意识到了这一点，忘了在这里匆忙地输入
int
返回类型。@这取决于变量的用途。如果用于检查标准C函数的返回值，则应为该函数使用指定的返回类型。不建议总是使用固定宽度的整数。例如，如果某些库函数接口为int，则在不同的环境下编译时可能会遇到问题platforms@vlad_tepesch我想将其改写为：使用写得很差且不可移植的库是不可取的。在C语言中使用
int
etc，在从8位MCU到64位PC的任何系统中几乎都是不好的做法。很少有情况下，作为程序员，你想要一个int而不在乎它有多大。@Lundin我不完全同意这一点。使用固定大小类型可能会导致性能损失。如果您使用的是纯32位系统，那么即使您只需要16位，使用int32也可能会更高效。如果您将使用哪种类型的描述留给编译器（只使用int），那么您的代码在16位机器和32位机器上都可能运行得更快。