Have fun setting up OpenVPN tray icon, sucker



  • Alright fine, the CL #pragmas are better than the GCC #pragmas in every respect.

    Even Discourse agrees:


  • Discourse touched me in a no-no place

    @tar said:

    That's right, because maintenance isn't a thing. Any code I would ever look at would have been written by me.

    #include <iostream>
    
    using namespace std;
    
    void main()
    {
        int i;
    
        cout << i << endl;
    }
    
    D:\Temp>cl /EHsc s.cpp
    Microsoft (R) C/C++ Optimizing Compiler Version 18.00.31101 for x64
    Copyright (C) Microsoft Corporation.  All rights reserved.
    
    s.cpp
    d:\temp\s.cpp(9) : warning C4700: uninitialized local variable 'i' used
    Microsoft (R) Incremental Linker Version 12.00.31101.0
    Copyright (C) Microsoft Corporation.  All rights reserved.
    
    /out:s.exe
    s.obj
    
    D:\Temp>
    

    What's that?

    d:\temp\s.cpp(9) : warning C4700: uninitialized local variable 'i' used
    

    Ooh, a description of the warning along with the number. Besides, the person before you probably already disabled it. If you really wanted to know, you could temporarily turn the warning back on.


  • Discourse touched me in a no-no place

    @tar said:

    Alright fine, the CL #pragmas are better than the GCC #pragmas in every respect.

    Victory is mine!



  • My point being, if I unearth something while I'm looking through some dark and forgotten corner of some dusty corporate codebase, and it's sprinkled with #pragma warning disables, those warning numbers aren't necessarily going to mean a lot to me without needing to go off and do some further research (or comment out the pragmas and see what happens, but if I do that and there's still no warning, then I'm none the wiser as to the original programmer's intent...)

    With #pragma GCC diagnostic ignored "-Winvalid-offsetof", I can at least guess what that's trying to do (and then have a look for offsetofs in the code...)



  • @tar said:

    gcc --help -v 2>&1 | grep \-W

    yields:

    $ gcc --help -v 2>&1 | grep \-W
    grep: invalid option -- 'W'
    Usage: grep [OPTION]... PATTERN [FILE]...
    Try 'grep --help' for more information.
    

    This works though:

    $ gcc --help -v 2>&1 | grep -- -W
      -Wa,<options>            Pass comma-separated <options> on to the assembler
      -Wp,<options>            Pass comma-separated <options> on to the preprocessor
      -Wl,<options>            Pass comma-separated <options> on to the linker
    Options starting with -g, -f, -m, -O, -W, or --param are automatically
     other options on to these processes the -W<letter> options must be used.
     /usr/lib/gcc/x86_64-linux-gnu/4.8/cc1 -quiet -v -imultiarch x86_64-linux-gnu help-dummy -quiet -dumpbase help-dummy -mtune=generic -march=x86-64 -auxbase help-dummy -version --help -fstack-protector -Wformat -Wformat-security -o /tmp/cceGrIxu.s
      -Wcast-result               Warn about casts that will produce a null or nil
      -Waliasing                  Warn about possible aliasing of dummy arguments
      -Walign-commons             Warn about alignment of COMMON blocks
      -Wampersand                 Warn about missing ampersand in continued
    [...]
    

  • area_deu

    @tar said:


    What. The. Fuck.


  • ♿ (Parody)

    @tar said:

    What are you going to do if you're trying to fix your code on a plane, where you don't have internet, eh?

    As long as you weren't fixing python on the motherfucking plane, it should all be OK.


  • Discourse touched me in a no-no place

    Yup.



  • Timely joke. That movie is just at the cusp of public awareness.


  • ♿ (Parody)

    You're wrong.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    Timelyless joke. The original line was quite memorable.

    FTFY.



  • Interesting*. I did write the second one out but I shortened it as it seemed to work equally as well. I assume you're not running it on Windows?

    *. In the sense of "not really that interesting at all..."



  • @tar said:

    Interesting*. I did write the second one out but I shortened it as it seemed to work equally as well. I assume you're not running it on Windows?

    You assume correctly.

    -- causes (my) grep to parse the remainder of the command line as strings instead of parameters to grep. Using \-W causes the shell to escape the -, which is a no-op since it's not a special character to the shell and passes -W as a parameter to grep.

    Your grep probably does things a little differently. Out of curiosity, what do you get when you run gcc --help -v 2>&1 | grep -W?

    * NMF


  • Discourse touched me in a no-no place

    @FrostCat said:

    Doesn't GCC have a #pragma or something to suppress a particular warning/error for a range or compilation unit?

    Indeed it does.

    #pragma GCC diagnostic ignored "-Wdeprecated-declarations"
    

    And I've just committed that to the file in question. 😃 (That particular file doesn't ever need to build with anything other than gcc or clang, both of which know that pragma. I tested.)


  • Discourse touched me in a no-no place

    @dkf said:

    (That particular file doesn't ever need to build with anything other than gcc or clang, both of which know that pragma. I tested.)

    What does GCC do with unrecognized pragmas? VC just throws a warning (C4068 unknown pragma).


  • :belt_onion:

    Which you then suppress with
    #pragma warning (disable:4068)


  • Discourse touched me in a no-no place

    Well, yeah, but if I said that I wouldn't have an excuse for another post.

    Also, GCC probably doesn't recognize that pragma, so you actually need two pragmas, one for each compiler, and all that's going to do is guarantee one or the other compiler will throw a warning about not recognizing the other compiler's pragma


  • :belt_onion:

    We require additional standardization


  • Discourse touched me in a no-no place

    @sloosecannon said:

    We require additional standardization

    I want a video camera streaming that discussion.


  • :belt_onion:

    What Could Go Wrong? (the livestream), now playing on an Internet near you


  • Discourse touched me in a no-no place



  • I have a very special place in my heart for failed early 90's animal mascots.



  • @sloosecannon said:

    We require additional standardization

    The 'trick' is to make a header called "compiler.h" which has a contents something like this:

    #if defined(__GNUC__)
    #include "compiler/gcc.h"
    #elif defined(_MSVC)
    #include "compiler/cl.h"
    #endif//...
    

    And then you can put all your compiler-specific #pragmas in the appropriate header...


  • :belt_onion:

    That's... That's actually a really good idea.


  • Discourse touched me in a no-no place

    @FrostCat said:

    What does GCC do with unrecognized pragmas?

    Don't know. I don't care in this case: it works with the compilers that that particular file will be fed into (since it's platform-specific code to integrate with the lower levels of the OSX dynamic loader, I can be sure that what happens with VC doesn't matter; that platform has a different platform-specific file).



  • @tar said:

    the GCC #pragma has a slight edge on the CL #pragma because you don't have to go on the internet to look up the warning code

    It also has the advantage that every non-GCC compiler is going to ignore #pragma GCC anything-at-all rather than misinterpreting it as a pragma of its own, which is good for portability, even if it does cause (suppressable) warnings. Namespaces ftw!



  • The global namespace of, uh, anything is reserved for Microsoft to put their stuff in, isn't it?



  • @PleegWat said:

    IMO, -Werror is an important tool

    And then you get codebases that are clusterfucks of total madness, but you can't comment out a line for debugging because some fucker decided to start the code improvements from the ass-end and you get slapped with "Warning as Error: Variable is not used" disclaimer: VS, C#, also probably not the exact message.

    Treating warnings as errors should be in the developers' mindset. It's like that "@accalia turning off i++" thing - your problem is people.


  • Java Dev

    Yup. Hence the rest of that post - you don't want to be bothered by stuff like that while you're debugging. But you want to enforce no warnings in main/head/trunk/whatever



  • Frankly, I don't see the point of enforcing it on the build/test level either. Committing crappy code is an offense no matter whether the compiler picks up on this or not, and seeing how I can just slap a warning-disabling pragma in like three seconds anyway...


  • Java Dev

    I'll see your warning-disabling pragma during review, and can decide if it's properly scoped.

    I probably wouldn't see the warning until I try to make some changes and can't spot oversights in my code (like a variable that is not initialized in all codepaths) because of all the spurious warnings your code is generated.



  • Huh? If you see my warning-disabling pragma during review, you'll also see my warnings I pushed to source control during review. Or even before the review. And then you come up to me and tell me to fucking fix my code.

    Unless your code review doesn't involve running a build?


    Filed under: obviously not "me" me, my code is flawless and every warning is a feature


  • FoxDev

    @Maciejasjmj said:

    my code is flawless and every warning is a feature

    You should be a Discodev 😜


  • Java Dev

    Code review is typically a readthrough, checking if your approach is good, and if you might have missed any weird edge cases. If at any point I suspect it won't compile, wouldn't pass tests, or hasn't been functionally verified by you otherwise you're getting it straight back.

    If you merge stuff with warnings I'll find out after tonight's build fails, and that'll be on your plate first thing tomorrow morning. Or I'll revert your checkin myself, if you give me reason not to trust you.



  • Don't build systems generally offer a build summary to view? You'll see those warning pretty fast. Except they won't break the build outright and can be prioritized.


  • Java Dev

    Miswording. THe build overview is shit and there's nothing we can do about it. But there's a test cycle, which includes ~80 tests, among which is the 'compile' test, which runs 2 compiles, one normal one debug both -Werror. If you cause a failure in any test, you'll get a bug for it and it'll be prioritized - at development priority 1. Which is the highest development priority.



  • I'm not a PM (damn it, Jim!), but it still rings a bit silly. Say you have a new version rollout in $short_time, and you're frantically fixing bugs - wouldn't it make sense to take some technical debt and schedule the refactor post-rollout?

    If I got a DEFCON 1 bug report about some warning in such situation, I'd probably just slap a pragma on it - and then promptly forget about it.


  • Java Dev

    I'm glad you're not on our team then, because people on our team don't merge that shit to begin with.

    And there's the eternal threat of the 'mergereq' system to keep everyone in line. That is a mandatory approval chain which enforces successful review and test cycles, QA and relman approval before you are allowed to merge your code. Thus far, it is disabled. In products where it is enabled, a 24h additional delay time before you can merge is common.



  • @PleegWat said:

    I'm glad you're not on our team then, because people on our team don't merge that shit to begin with.

    What part of "my code is perfect" did you not understand?

    And if you have a good enough team to follow good practices of not merging in shitty code and still delivering on time, what do you need those policies for? I mean it's not like a bug that you can miss - those warnings are right there when you build.


  • Java Dev

    I wrote that test because I got tired of having to fix the debug build before I could use it. I slapped in the normal build as well because it was zero extra effort.



  • @Maciejasjmj said:

    wouldn't it make sense to take some technical debt and schedule the refactor post-rollout?

    Yeah, like that ever happens... (or is allowed to happen). New features are always more important (to certain people) than a refactor the end-user will never notice.


  • Discourse touched me in a no-no place

    @dcon said:

    New features are always more important (to certain people) than a refactor the end-user will never notice.

    They're right. They are more important. Refactoring is just something you've got to do anyway in order to keep being able to deliver new features. It's like how you've got a car and going places in it is far more important than keeping the oil changed. But if you never get an oil change, after a while you won't be going anywhere…



  • Well, yes. But as we all know, the new release goes out in X time. All the new features will take X+Y time. So refactoring is never allowed. And we all know that features never get cut. But the date may get pulled up. (work weekends? Hell no. I'm not paid enough for that. No amount is enough for that.)

    And yes, I've seen projects crash/burn because the cruft built up too much (we warned them, they wouldn't listen). Thankfully, where I am now isn't too bad... And our PM and manager listen to us.


  • BINNED

    All this refactoring talk is really tempting me... I was working on some code that could desperately use some refactoring just yesterday. The worst bit is something I should be able to at least improve considerably in a day...

    Maybe, just maybe I try to do that today. I'm at home and nobody is going to bother me and keep asking which new feature I'm working on...



  • @dcon said:

    But as we all know, the new release goes out in X time. All the new features will take X+Y time. So refactoring is never allowed.

    Dunno where you work, but we do occasionally spend time refactoring. Damn, we'd even bill a client for that.

    Granted, we'd also bill a client to add a column to their report every year because our software sucks so badly it's impossible to automate it. But hey.



  • Isn't technical debt analysis part of your story/pbi decomposition during sprint planning????



  • The only chance of getting rid of technical debt on this project is to get a time machine and erase all the previous developers from this timeline.

    We patch things here and there during downtime, we have rewritten a few things, but to actually make this thing clean and working would take far more time than we'll ever be able to sideline in a CR estimate.

    Did I mention it runs only in IE? In compatibility mode? Targeting IE7? And any attempt to fix it would be pointless, because the offending JS can come from any layer, be it a code file, a string concatenated in backend code, some auxiliary module, or even a DB stored procedure? Yeah, we ain't touching that.


Log in to reply