Announcement

Collapse
No announcement yet.

GCC Unlikely To Adopt A "-Weverything" For Exposing All Possible Code Warnings

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • zyxxel
    replied
    Originally posted by wizard69 View Post
    What a bunch of idiots! There is good reason to want to throw all warnings. Beyond that who cares what some developers need, like most compiler switches they get turned on or off based on project needs.

    Setiously it is no wonder CLang continues to see new adoption.
    Us idiots are called professional developers. Us idiots have managed to collect a bit of experience. And "all warnings on" isn't so good as "non-idiots" might think.

    Leave a comment:


  • AHSauge
    replied
    Originally posted by Weasel View Post
    This is why such HW is trash and people should stick to x86.
    Ehh...suuuure. You do realise that x86 is absolute trash for anything other than PCs, right? I deal with sub 1W devices and x86 is just simply not remotely an option. The best you can get is ARM Cortex MPUs, which for the record do have HW support for unaligned access (aka. packed structures)

    Leave a comment:


  • Weasel
    replied
    Originally posted by AHSauge View Post
    The main problem with packed structs, aside from the performance hit, is some HW don't even support it. This means that the compiler have to deal with it in software, which gives you even more performance hit. So far it's okay. However, what happens if you give someone a pointer to a member of your struct? Well, depending on your hardware you either get a performance hit, incorrect result or a crash. My daily work involves legacy code on HW where I can either choose between incorrect result or a crash. Naturally I go for the crash, and it's biting time and time again. It should be rewritten to avoid packed structures, but no time allowed for it
    This is why such HW is trash and people should stick to x86.

    Leave a comment:


  • AHSauge
    replied
    Sorry for a late reply, just logged in again, and saw this.

    Originally posted by mlau View Post
    Can you give examples? I've written countless drivers and other stuff for hardware that doesn't support unaligned accesses, but never once have I felt the need for a packed struct.
    Try communicating with third party items where they are okay with packing the structs. You'll have to choose between memcpy each field out or make a packed struct, and the copy into a non-packed struct.

    Originally posted by F.Ultra View Post

    What is the problem that you have with packed structs? I use packed structs extensively for on the wire protocols with thousands of external sources and have never once encountered a problem with packed structs in GCC and that is going back to 2.x when I begun to use GCC.

    Code:
    struct OrderbookDirectory {
    char MessageType;
    uint32_t Nanoseconds;
    uint32_t OrderbookID;
    char Symbol[32];
    char Name[32];
    char ISIN[12];
    uint8_t FinancialProduct;
    char TradingCurrency[3];
    uint16_t NumberOfDecimalsInPrice;
    uint16_t NumberOfDecimalsInNominalValue;
    uint32_t OddLotSize;
    uint32_t RoundLotSize;
    uint32_t BlockLotSize;
    uint64_t NominalValue;
    } [B]__attribute__ ((packed))[/B] __attribute__((__may_alias__));
    The main problem with packed structs, aside from the performance hit, is some HW don't even support it. This means that the compiler have to deal with it in software, which gives you even more performance hit. So far it's okay. However, what happens if you give someone a pointer to a member of your struct? Well, depending on your hardware you either get a performance hit, incorrect result or a crash. My daily work involves legacy code on HW where I can either choose between incorrect result or a crash. Naturally I go for the crash, and it's biting time and time again. It should be rewritten to avoid packed structures, but no time allowed for it

    Leave a comment:


  • Ansla
    replied
    Originally posted by xorbe View Post
    In large projects, it's basically impossible to globally throw -Wall -Wextra without a bunch of -Wno-* waivers. Because of external code that can't be changed.
    Actually, you're including the external code the wrong way. The compiler will only complain about the headers it found in paths specified using the regular `-I` argument. There is a special `-Isystem` to be used for paths containing code that can't be changed.

    Leave a comment:


  • Bsdisbetter
    replied
    Originally posted by mlau View Post
    Can you give examples? I've written countless drivers and other stuff for hardware that doesn't support unaligned accesses, but never once have I felt the need for a packed struct.
    Openvms uses them heavily.

    Leave a comment:


  • Bsdisbetter
    replied
    Originally posted by brrrrttttt View Post
    I cannot forsee myself ever using this... does anyone that actually maintains a non-trivial piece of software want this?
    Yes. on systems utilising clang we have it enforced. It is pretty much hated by all though as it exposes so much work to clean up especially on older code. Newer code is fine.

    Leave a comment:


  • brrrrttttt
    replied
    Originally posted by cybertraveler View Post

    Your comment prompted me to look for a GCC option to selectively disable warnings on a part of code. It looks like you can do it:

    https://gcc.gnu.org/onlinedocs/gcc/D...c-Pragmas.html

    So I think you could do:

    Code:
    #pragma GCC diagnostic ignored "-Wunused-parameter"
    
    void foo(int a, int b, int my_unused_display_pointer_param) {
    ...
    }
    
    #pragma GCC diagnostic warning "-Wunused-parameter"
    Note: I haven't tested that.
    Better to push diagnostics before, then pop after, so the rest of the code follows the build system flags (where diagnostics are supposed to be controlled!). So:
    Code:
    #pragma GCC diagnostic push
    #pragma GCC diagnostic ignored "-Wunused-parameter"
    
    void foo(int a, int b, int my_unused_display_pointer_param) {
    ...
    }
    
    #pragma GCC diagnostic pop
    -e- And if you wish for portability, you're going to want to surround those pragmas with some #if too.
    Last edited by brrrrttttt; 24 January 2019, 10:35 PM.

    Leave a comment:


  • carewolf
    replied
    Originally posted by cybertraveler View Post

    Can they add new types of warnings to those warning-set options or would that be considered as breaking break backwards compatibility?
    They add new warnings to them all the time. Several project I work on use -Wall -Wextra -Werror, and one the things that combination requires is maintainence fixing or silencing all the new warnings in every compiler release.

    Leave a comment:


  • Weasel
    replied
    Originally posted by carewolf View Post
    Why? Just don't name parameters you don't use.
    That works only in C++ AFAIK, not in C.

    Leave a comment:

Working...
X