类型转换，头疼，头疼。有两个简单问题（对我来说有点难），请教大家。

moxies

晚上好，
          有两个问题请教大家：

          1、在看<endian.h>文件时，发现他引入了另一个头文件<bits/endian.h>,后一个文件是在/usr/include/i386-linux-gnu下，请问是在哪里指定的i386-linux-gnu这个路径的？ （grep -R -n i386-linux-gnu /usr/include 无果）。

          2、uint16_t bt_get_unaligned 相关，先上测试代码：

1. #include <bluetooth/bluetooth.h>
   
2. #include "hci.h"
   
3. #include "mgmt.h"
   
4. #include <inttypes.h>
   
5. 
   
6. int main(){
   
7.         printf("result: %d\n",1&1<<1);
   
8.         char  buf[] = {0x04,0x04,0x0a,0x2e,0xe7,0xde,0x3d,0x1e,0x00,0x00,0x1f,0x00,0x01};
   
9.         struct mgmt_hdr *hdr = (void *)buf;
   
10. 
    
11.         printf("%s\n",(char*)&hdr->opcode); //这里实在不知道改怎么写了。想先把原始值打出来，和转换后的做对比。
    
12. 
    
13.         uint16_t code = btohs(bt_get_unaligned(&hdr->opcode));
    
14.         if(code == 0x000B){
    
15.                 printf("ok\n");
    
16.         }
    
17.         printf("result is : %" PRIu16 "\n",code);
    
18.         return 0;
    
19. }

复制代码

输出是：result is : 1028

        这是bluez的代码：

1. opcode = btohs(bt_get_unaligned(&hdr->opcode));
   
2.         len = btohs(bt_get_unaligned(&hdr->len));
   
3.         index = btohs(bt_get_unaligned(&hdr->index));
   
4. 
   
5.         if (ret != MGMT_HDR_SIZE + len) {
   
6.                 error("Packet length mismatch. ret %zd len %u", ret, len);
   
7.                 return TRUE;
   
8.         }
   
9. 
   
10.         switch (opcode) {
    
11.         case MGMT_EV_CMD_COMPLETE:
    
12.                 mgmt_cmd_complete(sk, index, buf + MGMT_HDR_SIZE, len);
    
13.                 break;
    
14. 。。。。

复制代码

补充下bt_get_unaligned宏：

1. #define bt_get_unaligned(ptr)                        \
   
2. ({                                                \
   
3.         struct __attribute__((packed)) {        \
   
4.                 __typeof__(*(ptr)) __v;                \
   
5.         } *__p = (__typeof__(__p)) (ptr);        \
   
6.         __p->__v;                                \
   
7. })

复制代码

跟踪bluez日志发现bluez 走的是MGMT_EV_DEVICE_CONNECTED（0x000B）分支。
        这里就抓狂了。测试中的code 和 bluez的opcode 对不上了。很不解。也许printf的问题。还请大神帮忙讲讲bt_get_unaligned这个宏。为什么要这么做。谢谢。

moxies

@windoze 看你在，帮说说看吧。 哎。。。闹不清楚不想睡觉了都。。

moxies

路过的兄弟门，别光看啊。有想法的来讲讲。也许我测试的数据不对。但真的想知道那个宏的作用。猜测都可以。要留下你的脚印啊。否则这个帖子太孤独了。

windoze

第一个问题，include这玩意儿是cpp负责的，所以可以用

1. cpp -v

复制代码

看到所有缺省的include path，不出意外应该能看到/usr/include/i386-linux-gnu，不过我的Arch里endian.h是在/usr/include/bits下面。

第二个问题还没看，等下有空了再说

moxies

回复 4# windoze


1 第一个问题的追问：如果是app的include_path决定，那么在bits下的endian 和 /usr/include下endian 并没有做 头文件重复导入定义的判断，怎么能保证先加载/usr/include下的endian呢？


2 一定要看啊。谢谢了先。呵呵

windoze

回复 5# moxies

我看到bits/endian.h里面写着

Never use <bits/endian.h> directly; include <endian.h> instead.

而endian.h里面分明有

1. 
   
2. #ifndef _ENDIAN_H
   
3. #define _ENDIAN_H        1
   
4. ...
   
5. #endif        /* endian.h */
   

复制代码

只不过最开头一段都是版权声明，你可能没看清。

moxies

哦。我粗心了。第一个问题解决了。早点休息吧。明天如果有空，帮我看看第二个问题。很感谢。
   

windoze

bt_get_unaligned(ptr)看起来根据ptr指向的类型定义了一个新的类型。
这个新类型有__attribute__((packed))属性，目的就是把原有类型里末尾的padding干掉，所以才起这个名字吧。
比如

1. 
   
2. // 这个类型是4字节对齐的，因为里面有一个int成员，所以其实后面有3个字节的padding
   
3. struct S {
   
4.   int n;
   
5.   char c;
   
6. };
   
7. S *ptr;
   
8. bt_get_unaligned(ptr);
   
9. // 上面那个宏相当于定义了一个新的unaligned S，1字节对齐
   
10. struct  __attribute__((packed))  unaligned_S_wrapper {
    
11.    struct S v;
    
12. } *__p=(unaligned_S *)(ptr);
    
13. // 这里v就变成1字节对齐的了，因为外面的wrapper有packed属性
    

复制代码

估计这个宏是用来做I/O的，因为原有的S后面有3个字节完全没用的东西，用这个宏搞一下就把这3个字节干掉了。

moxies

回复 8# windoze



    呵呵，我这个提问者，还真是懒，居然比你下线的早。真是该罚。 总之，谢谢你。 刚突然想到，是否可用用二进制观察下。数据的变化，比对起来可能就直观了。我再想想代码怎么写。