New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sixlowpan: ignore warnings about GCC extensions #1609

Closed
sgso opened this Issue Aug 24, 2014 · 5 comments

Comments

Projects
None yet
4 participants
@sgso
Contributor

sgso commented Aug 24, 2014

When compiling any network enabled program in RIOT, there are a lot of warnings from file sys/net/include/sixlowpan/types.h about:

types.h:84:5: warning: type of bit-field ‘pad’ is a GCC extension [-Wpedantic]
types.h:85:5: warning: type of bit-field ‘reserved’ is a GCC extension [-Wpedantic]

Even compiling the tiny rpl_udp example, you get 48 of these. Are you open to silencing them by GCC diagnostic pragmas?

#pragma GCC diagnostic ignored "-Wpedantic"
    unsigned long pad:4;            /**< number of octets used for padding after adresses. */
    unsigned long reserved:20;      /**< reserved. Set to 0. */
#pragma GCC diagnostic pop
@miri64

This comment has been minimized.

Show comment
Hide comment
@miri64

miri64 Sep 10, 2014

Member

I think we better make a non-GCC specific implementation as in all the other types:

typedef struct __attribute__((packed)) {
    uint8_t nextheader;             /**< type of next header in this packet. */
    uint8_t hdrextlen;              /**< length of header in 8-octet units. */
    uint8_t routing_type;           /**< identify srh-variant. */
    uint8_t segments_left;          /**< remaining route segments before reaching destination. */
    uint32_t cmpr_i_e_pad_res;      /**< 4+4 bit, expressing prefix octets from each/last segment + 
                                     *   number of octets used for padding after adresses + Reserved */
} ipv6_srh_t;

#define IPV6_SRH_CMPR_I(srh) ((srh->cmpr_i_e_pad_res & 0xf0000000) >> 28)
#define IPV6_SRH_CMPR_E(srh) ((srh->cmpr_i_e_pad_res & 0x0f000000) >> 24)
#define IPV6_SRH_PAD(srh)    ((srh->cmpr_i_e_pad_res & 0x00f00000) >> 20)
#define IPV6_SRH_RES(srh)    ((srh->cmpr_i_e_pad_res & 0x000fffff))
Member

miri64 commented Sep 10, 2014

I think we better make a non-GCC specific implementation as in all the other types:

typedef struct __attribute__((packed)) {
    uint8_t nextheader;             /**< type of next header in this packet. */
    uint8_t hdrextlen;              /**< length of header in 8-octet units. */
    uint8_t routing_type;           /**< identify srh-variant. */
    uint8_t segments_left;          /**< remaining route segments before reaching destination. */
    uint32_t cmpr_i_e_pad_res;      /**< 4+4 bit, expressing prefix octets from each/last segment + 
                                     *   number of octets used for padding after adresses + Reserved */
} ipv6_srh_t;

#define IPV6_SRH_CMPR_I(srh) ((srh->cmpr_i_e_pad_res & 0xf0000000) >> 28)
#define IPV6_SRH_CMPR_E(srh) ((srh->cmpr_i_e_pad_res & 0x0f000000) >> 24)
#define IPV6_SRH_PAD(srh)    ((srh->cmpr_i_e_pad_res & 0x00f00000) >> 20)
#define IPV6_SRH_RES(srh)    ((srh->cmpr_i_e_pad_res & 0x000fffff))
@miri64

This comment has been minimized.

Show comment
Hide comment
@miri64

miri64 Dec 8, 2014

Member

Can't reproduce this error anymore (even on 502fd23, which was master's HEAD when this issue was opened)

Member

miri64 commented Dec 8, 2014

Can't reproduce this error anymore (even on 502fd23, which was master's HEAD when this issue was opened)

@LudwigKnuepfer

This comment has been minimized.

Show comment
Hide comment
@LudwigKnuepfer

LudwigKnuepfer Dec 9, 2014

Member

It still exists on e.g. ubuntu-12.04.

Member

LudwigKnuepfer commented Dec 9, 2014

It still exists on e.g. ubuntu-12.04.

@LudwigKnuepfer

This comment has been minimized.

Show comment
Hide comment
@LudwigKnuepfer

LudwigKnuepfer Dec 9, 2014

Member

Ah, no, I was on the wrong branch..

Member

LudwigKnuepfer commented Dec 9, 2014

Ah, no, I was on the wrong branch..

@miri64

This comment has been minimized.

Show comment
Hide comment
@miri64

miri64 May 26, 2015

Member

Anyways: Won't fix, new network stack avoids this syntax.

Member

miri64 commented May 26, 2015

Anyways: Won't fix, new network stack avoids this syntax.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment