Bashing the C consonants


  • BINNED

    So, it's time to update a client's install, and I'm trying to fix this so I can upgrade all the things:

    No longer compiles. Something broke again, yay. Ok, well, start install script and see where it complains...

    /usr/src/dahdi-linux-complete-2.11.0+2.11.0/linux/drivers/dahdi/opvxg4xx/base.c:2475:15: error: ‘struct dahdi_span’ has no member named ‘manufacturer’
       myspan->span.manufacturer = "OpenVox";
    

    Huh... ok, let's see that file...

    #if (DAHDI_VER_NUM < 2600)
        myspan->span.manufacturer = "OpenVox";
    #endif //(DAHDI_VER_NUM < 2600)
    

    DAHDI_VER_NUM? And 2600? What? Oh, you mean 2.6.0.? Ok, I'm using 2.11.0 why... Huh. Ok, where is it defined?

    root@dev:/usr/src/dahdi-linux-complete-2.11.0+2.11.0# grep -R "#define DAHDI_VER_NUM"
    linux/drivers/dahdi/opvxg4xx/opvxg4xx.h:#define DAHDI_VER_NUM 2110
    

    Wait... that file is not a part of DAHDI. Oh, I guess the install script put it there. But how could it have the version number? And why is it 2110?

    NO! OH FUCK PLEASE NO!

    # From install.sh:
    
    DAHDI_VER_NUM=
    get_dahdi_version()
    {
            DAHDI_VER_STR=`cat $DAHDI_LINUX_COMPLETE_SOURCE_DIR/.version`
    
            for (( i=0; i<${#DAHDI_VER_STR}; i++ ))
            do
                    tmp=${DAHDI_VER_STR:$i:1}
    
                    if [ $tmp = "+" ]
                    then
                            break;
                    elif [ $tmp = "-" ]
                    then
                            break;
                    fi
    
                    if [ "${tmp##[0-9]*} " = " " ]
                    then
                            DAHDI_VER_NUM+=$tmp
                    fi
            done
    
            for (( i=${#DAHDI_VER_NUM}; i<4; i++ ))
            do
                    DAHDI_VER_NUM+="0"
            done
    }
    
    # snip
    
    if [ "$VIRTUAL_TTY" == "YES" ]; then
        sed -i "/#define _OPVXG4XX_H_/a#define DAHDI_VER_NUM $DAHDI_VER_NUM\n#define VIRTUAL_TTY" $OPVXG4XX_H_FILE
    else
        sed -i "/#define _OPVXG4XX_H_/a#define DAHDI_VER_NUM $DAHDI_VER_NUM" $OPVXG4XX_H_FILE
    fi
    

    Yup! So, the version number becomes 2110 for version 2.11.0. Which the C code reads as 2.1.0, so, it's ancient, we better fill in these fields that no longer exist since 2.6.0...

    :headdesk: :headdesk: :headdesk: :headdesk:


  • SockDev

    .... using SED to issue blind edits to header files?

    using bash to construct the SED replacements?


  • BINNED

    Yup. Which is also the reason that instructions on that GitHub page instruct you to create a .version file which no longer exists in regular DAHDI release. I, stupidly, didn't lie and did

    echo "2.11.0" > /usr/src/dahdi-linux-complete-2.11.0+2.11.0/.version
    

    I knocked it down to 2.9.0 now, fuck it, won't have any effect on anything past 2.6.0 anyway. Though I might have to if I want to add some #ifs of my own, there's still errors...



  • I would have tried 21100 in this scheme.

    I hate version stuff like this, but it's also why I've kept separate major / minor / patch versions for testing this sort of thing when I've needed it.


  • SockDev

    But what happens when version 3.0.0 comes out?


  • BINNED

    @boomzilla said:

    I would have tried 21100 in this scheme.

    Which will be fine and dandy, but what happens once 3.0.0 releases? No idea if there's a chance of that happening any time soon but...

    And it seems I'll have to, turns out I need to add checks for version > 2.10.1 so...



  • @RaceProUK said:

    But what happens when version 3.0.0 comes out?

    @Onyx said:

    Which will be fine and dandy, but what happens once 3.0.0 releases?

    Is it that hard? Sorry, I guess maybe I don't fully understand whose code is requiring this and where the tests are happening vs where the macro is getting defined.



  • @RaceProUK said:

    But what happens when version 3.0.0 comes out?

    @Onyx said:

    Which will be fine and dandy, but what happens once 3.0.0 releases?

    030000
    Two digits per each section. Hopefully you never need a version above 99...


  • SockDev

    99 versions should be enough for anyone?


  • SockDev

    You're assuming @onyx can control the format of the version constant



  • No? We're in a "if only it had been this way" context, not a "you should change it to be this way" context.


  • BINNED

    @boomzilla said:

    Is it that hard? Sorry, I guess maybe I don't fully understand whose code is requiring this and where the tests are happening vs where the macro is getting defined.

    I'm trying to touch as little as I can, TBQH.

    The driver is not mine, I just patched it up to work on kernel 3.10+ and, I think, DAHDI 2.9, at the time. The driver comes from OpenVox, DAHDI is a channel driver for ISDN cards in Asterisk.

    I'm not touching DAHDI with a 10-meter pole, it's staying as it is, too many possibilities for catastrophic failure there. So all I really have is one bash script and one C file to play with.

    I'm assuming that there's no version definition in DAHDI because it provides drivers for all the most common cards anyway. This GSM gateway thing is the odd duck in the setup here.



  • @Arantor said:

    99 versions should be enough for anyone?

    I wonder what Chrome and Firefox will have to say about that in a couple of years.


  • SockDev

    @loopback0 said:

    I wonder what Chrome and Firefox will have to say about that in a couple of yearsmonths.

    FTFY


  • BINNED

    Ok, so the driver was last updated in 2012 it seems. So, I have two options, I guess:

    [poll]

    1. Change the numbering scheme and modify all of the conditionals in the driver
    2. Add another "special snowflake" constant to deal with minor release numbers
      [/poll]

    I guess I should bite the bullet and do the first option. But have a poll anyway.



  • Oh, that's easy. Version 100 becomes version C and then there will be a whole list of subversions named after catsfoodhow about asteroids? do asteroids work? nobody's using those already?.



  • @LB_ said:

    Two digits per each section. Hopefully you never need a version above 99...

    Version 9a or A0. Who said it wasn't base 36 or 62 and they were skipping whole chunks of it...



  • String manipulation is the devil.


  • BINNED

    Oh, good, I accidentally clicked on the poll and can't remove my vote now.



  • If we're going down that route, I suggest @Onyx take a look at [RFC 2550] (https://tools.ietf.org/html/rfc2550) for inspiration.


  • BINNED

    Oh, this looks like something we talked about recently:

    /*Freedom del 2011-09-01 17:26*/
    /************************************************************/
    #if 0
    static unsigned int UART0_BASE =     0x000004c0;
    static unsigned int UART1_BASE =     0x000004e0;
    static unsigned int UART2_BASE =     0x00000500;
    static unsigned int UART3_BASE =     0x00000520;
    #endif
    /************************************************************/
    

    Fuck yeah!


  • BINNED

    Update: driver compiled after doing this:

    // DAHDI 2.10.1+ now uses the standard IRQF_SHARED constant instead of its own version
    #ifndef DAHDI_IRQ_SHARED
    #define DAHDI_IRQ_SHARED IRQF_SHARED
    #endif
    

    Yes, I know how stupid that looks. I don't even care any more.

    Next up, trying to get the Asterisk module to compile for Asterisk 13. Fun sure to be had. Bringing popcorn for co-workers tomorrow, I'm sure I'll be putting on a show.

    Also, WTF highlighter, how can you not show any C code properly if there are preprocessor commands involved?



  • Well, I'm glad we were able to help you decide!


  • BINNED

    I took the third option of redefining a constant anyway, since that was the only code that failed to compile anyway.

    Looking at diffs in DAHDI source tree they just replaced every instance of DAHDI_IRQ_SHARED with IRQF_SHARED anyway, so they seem to be equivalent for the purpose. And since the DAHDI_IRQ_SHARED will be defined in older versions (if anyone even still uses those) it should cause no problems. I hope.


  • SockDev

    @Onyx said:

    it should cause no problems. I hope.

    *awaits the next instalment of Onyx's hit show What the fuck is this shit?*



  • @LB_ said:

    @Onyx said:
    Which will be fine and dandy, but what happens once 3.0.0 releases?

    030000
    Two digits per each section. Hopefully you never need a version above 99...

    I see you like octal...


  • BINNED

    This isn't JavaScript, C knows what it's doing... most of the time :stuck_out_tongue:

    As a side note, I had to dive into Asterisk source code and yup, that's what they do - version 1.3 would be 10300 while version 13 would be 130000,



  • @Onyx said:

    This isn't JavaScript, C knows what it's doing... most of the time :stuck_out_tongue:

    :wtf: you talking about man?

    @Onyx said:

    As a side note, I had to dive into Asterisk source code and yup, that's what they do - version 1.3 would be 10300 while version 13 would be 130000,

    Either that or bit shifting:

     $ grep KERNEL_VERSION /usr/include/linux/version.h
         #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
    

  • BINNED

    @OffByOne said:

    :wtf: you talking about man?

    Oh, that, yeah, sorry. No, leading zeros are not included.

    At this point I'm blindly passing NULLs around the freaking place. If this crashes Asterisk I'll probably have to rewrite half the fucking driver. Hopefully there are checks in place and it won't drop calls or something...



  • @Onyx said:

    Also, WTF highlighter, how can you not show any C code properly if there are preprocessor commands involved?

    Because you mispelled cpp?

    // DAHDI 2.10.1+ now uses the standard IRQF_SHARED constant instead of its own version
    #ifndef DAHDI_IRQ_SHARED
    #define DAHDI_IRQ_SHARED IRQF_SHARED
    #endif
    

    .. perhaps not...

    As you were.


  • SockDev

    why the hell were you expecting Discourse to get something right?



  • @anotherusername said:

    Oh, that's easy. Version 100 becomes version C and then there will be a whole list of subversions named after catsfoodhow about asteroids? do asteroids work? nobody's using those already?.

    Why not just split the difference and use catfood for version names?

    AndroidOSXDAHDI Meow Mix.


  • Discourse touched me in a no-no place

    @OffByOne said:

    I see you like octal

    HAHAHAHAH!



  • @FrostCat said:

    HAHAHAHAH!

    Translation: o12o12o12o12oNOT

    Btw, weren't the version subnumbers ceiliing'd by 9999 somewhere sometime?


  • BINNED

    More pretty:

    #if (ASTERISK_VERSION_NUM >= 100000)
    #else
        .capabilities = AST_FORMAT_SLINEAR | AST_FORMAT_ULAW | AST_FORMAT_ALAW,
    #endif
    

    Because < is for n00bz!



  • There is no >= operator in Cool. You'll have < and <= and like it!

    There are no comparison operators in BIT. There is only a "branch if jump register equals constant bit", and if you don't provide that, the program terminates.


  • Discourse touched me in a no-no place

    @ben_lubar said:

    Cool. You'll [...] like it!

    I most certainly will not.


  • SockDev

    But it's cool to limit operator types, right? :trolleybus:



  • @powerlord said:

    catfood for version names?

    There is a small problem with that. After the two most common options (house mouse and common vole) you'd have to get into the specialities that only few cat have access to (like various kinds of ground squirrels).


  • SockDev


  • Discourse touched me in a no-no place

    Nah. There's bats, and shrews, and chipmunks, all of which I've had cats bring into the house, sometimes still alive.

    Opening the door to go in after being out shopping and having a bat fly out of the house will wake you right the hell up.


  • Discourse touched me in a no-no place

    Real Cat food: liver, heart, kidney, bird, squirrel, manky old takeaway pizza, stolen barbecued chicken…



  • Is this code messing directly with the kernel a :barrier: to docker it?


  • BINNED

    What? I'm not putting it in Docker! WhyTF would I? I have a simple install script that does the setup for me rather nicely. As insane as this setup might sound if I explained it all it's basically just Asterisk, a service written in C++ and a web app written in PHP and using Postgres as a storage engine. A single 100ish line bash script does most of the installation (most of the lines are just split up aptitude installs for readability purposes), the rest is handled on service launch.

    Right now I'm backporting some of the new code in the said service to Asterisk 11. It's too much of a pain to fix the Asterisk module now, don't have the time. The driver works nicely with latest DAHDI and kernel on Debian stable.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.