#include <stdio.h>

//计算cpu字长
int c_get_cpu_lenth()
{
    unsigned int a;
    int i;
    a=~0;
    i=1;
    while((a>>=1)!=0) ++i;
    return i;
}

//计算2^N
unsigned int c_get_half_one()
{
    unsigned int t=1;
    for(int i=1;i<=c_get_cpu_lenth()/2;i++) t*=2u;
    return t-1;
}

int main()
{
    long test = 10*61380;
    long tl = test & c_get_half_one(); //获取整数的低16位 或者低X位  这里就不用0xffff 了  以避免弄错 可行？
    printf("L16=%X\n",tl);
    return 0;
}

实话说，不能理喻。
c_get_cpu_lenth可以直接return sizeof(int)*8

楼上说的是

为啥是乘以8呢

因为一个字节有8bits。
C标准中没有强制规定，但可以这么理解
即：sizeof返回字节数，一字节是8bits

你的 c_get_cpu_lenth 可以直接用常数 sizeof(unsigned int)*8
你的 c_get_half_one 可以直接用常数 (1u<<sizeof(unsigned int)*8/2)-1

64位cpu 中  sizeof int ==8  ？

没有64位cpu 瞎猜

64位时，有些不愉快的地方
按道理 sizeof(long long) >= sizeof(long) >= sizeof(int) >= sizeof(short)，且int应该是64bits
但是这样一来，short是32bits呢，还是16bits？不管是哪个，都有一个无法表示了。
所以要么忍痛丢掉16/32中的一个，要么让int不是64bits。

先给你看个表
GCC默认使用LP64数据模型
VC默认使用LLP64数据模型
但是，都可以通过编译参数进行修改。

不可否认的是，C语言诞生得太早，好多情况没能预料到。
假如重新设计的话，对于整型，应该这样：
int8、uint8、int16、uint16、int32、uint32、int64、uint64、……
这样就可以避免升级引发的混乱。当然，仅仅这些还不够，比如int16类型的一系列数 在32位CPU上运算，效率就不高，因为中间每一步都要做一个无意义的截断到16bits的操作，因此还得增加
int8least、uint8least、int16least、uint16least、int32least、uint32least、int64least、uint64least、……
也就是加了least结尾的表示：我不管你实际是多少位，只要你能保证至少有我指定的位数就行了，这样一来，既能满足我的要求，你编译器又可能使用最高效的运算类型。

事实上，C语言也正在这样变化，就是标准库中的<stdint.h>文件
比如 uint16_t 就表示一个 16bits的无符号整型
uint_least16_t 就表示一个至少16bits的无符号整型，编译器可能实际使用32bits或64bits的无符号类型进行优化