• (unregistered)
    Here is a bonus WTF. It is not a real WTF because it comes from someone seeking help on a web forum rather than production code but it is entertaining all the same.

    [code language="c#"]
    <font color="#ff0000">DWORD dw = GetLastError();</font>
    switch(msg)
    {
    case WM_CREATE:
    if(!InitCommonControlsEx(NULL)){
    FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER |
    FORMAT_MESSAGE_FROM_SYSTEM,
    NULL, <font color="#ff0000">dw</font>, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
    (LPTSTR) &cadena, 0, NULL );

    wsprintf(temp,"%s",cadena);
    MessageBox(hwnd,temp,"Error",MB_OK);
    }
    [/code]
  • (unregistered)

    <font style="BACKGROUND-COLOR: #efefef">I don't get what's wrong about that code pasted. Looks straightforward and good. Now, switching between the constants is a bad practise, but that's not pasted...</font>

  • (cs)

    >>> CTR_DTE_DATA_RATE_300

    Can anyone explain what the "CTR_" prefix stands for?  If it's for "Counter" then MAYBE this makes a little sense.  It could be an index into an array or some other similar construct.

    As to why there is no comment explaining what these values represent - W(hy)TF Not!

    As to why they would use the constant in some instances and the literal in others - Well, some people just need killin' (IMO).

  • (unregistered)

    What’s the WTF?

    In the first case, constants are specified by some external (and probably hardware) interface. Of course, if the developer sometimes uses raw magic numbers, that’s worse…

    With FormatMessage, that’s exactly the way to get the text description of an error. Although maybe he is formatting the error code from a wrong API call.

    --
    Centaur

  • (unregistered) in reply to Bustaz Kool

    DTE date rates are used in serial communications. The values #defined probably represent some sort of multiplier. I dont see what the WTF is at all. Like somebody else said... If these were hidden, switched, or mis-used then post that, because as it is it is just fine.

    I also don't see the WTF in the "bonus" posted above. Whats wrong with using GetLastError() result for FormatMessage()?

  • (unregistered)

    I agree with other posters that the main code doesn't represent a WTF as it probably represents some hardware constants (they're not the PC UART values though - I just checked). The WTF is clear from Alex's second sentence though:

    How about hiding the #defines in different header files and randomly flipping between the using the constant (CTR_DTE_DATA_RATE_300) and its value (5) throughout the code.

    'cos sometimes using a #define and sometimes not is definitely a WTF!

    As for the second one, I think it's to do with picking up the result of GetLastError before the function that's going to generate the error is called. Difficult to tell from context though, as it could be an error for something else.

  • (unregistered) in reply to

    The WTF in the bonus post, IMHO, is that the call to GetLastError occurs before the call to InitCommonControlsEx, for which it reports the error.

    I don't really see the WTF for the defines, though. The names seem pretty sensible and the actual value doesn't matter. It may seem to make more sense for CTE_DTR_DATA_RATE_300 to be 300, but there may be some softtware or hardware interface that requires the value 5 instead. It'll also be easier to check for valid values. You can simply check for <font face="Courier New" size="2">param >= CTE_DTR_DATA_RATE_50 && param <=CTE_DTR_DATA_RATE_153600</font> instead of checking whether the value specified is one of the allowed values.<font face="Lucida Console, Courier" size="2"></font>

  • (unregistered)

    > What better way to give unsuspecting developers a challenge than to redefine some straightforward numeric constants to completely arbitrary values

    WTF should be wrong with that? If you have a GUI and you want to localize it e.g. language dependent, the easiest thing to do would be to initialize a String-array and to do the localization with datarate2text[datarateID] (checking boundaries of course).

    Skipping between using conants and their values is a WTF indeed.

    Regards, Lothar

  • (unregistered)

    Well the colleague could have used enum for one.

  • (unregistered) in reply to Bustaz Kool

    CTR = Clear to Receive. There's also CTS = Clear to Send.  I agree that the #define's themselves aren't much of a WTF. Interchanging the name and value through the code may be historical - the code was originally written without the #define's and the #define's were added later?

  • (cs)

    Alex Papadimoulis:

    What better way to give unsuspecting developers a challenge than to redefine some straightforward numeric constants to completely arbitrary values? How about hiding the #defines in different header files and randomly flipping between the using the constant (CTR_DTE_DATA_RATE_300) and its value (5) throughout the code. Don't you wish you were Carl Kritzinger?


    I also don't get the WTF here...
    Of course mixing those labels with the actual values in the code will be a mess and a WTF but that wasn't posted. Looking just the defines posted I can tell about the WTF'ness of this.
    It would be a lot clearer to also see where those constants were misused (or not used at all). I understand that sometimes is the context what differentiates between right or wrong but in this case I don't understand why another piece of code wasn't posted (showing the real WTF).
    Maybe the supposed WTF is in those arbitrary numbers instead of:
    #define CTR_DTE_DATA_RATE_50 50
    #define CTR_DTE_DATA_RATE_75 75... and so on.
    But we don't know if those specific values are needed for something else like an external device. Or even if they aren't needed that's hardly a WTF but just a WIBBI (wouldn't it be better if).

    About the second code posted it seems that as others already said the WTF seems to be in trying to get the error from the call before actually making the call.

  • (cs)

    Based on the subject, the implied WTF is that they are defining CTR_DTE_DATA_RATE_300 to 5, etc.  I've worked on X.25 communications software (for phone switches) before and I had to do almost exactly what you see above to interface with certain libraries.  This could be used as an offset into an array or on the UI side as an index in a dropdown box.  Now, the code shouldn't switch back and forth between constants and their values, but even then it's not a true WTF, just a WAD (What A Dumb***).  This is a pretty weak WTF.

  • (unregistered)

    The better solution would have been to use an  enum {CTR_DTE_DATA_RATE_50, ...};
    But 0, 1, etc as values makes obviously sense, as desired data rates are a small subset of the integers, and as it's very easy to use for indexing, such as
    static const char *titles[CTR_DTE_DATA_RATE_MAX]={"50 (don't use that)", ...};

  • (unregistered) in reply to Guayo
    Guayo:

    Maybe the supposed WTF is in those arbitrary numbers instead of:
    #define CTR_DTE_DATA_RATE_50 50
    #define CTR_DTE_DATA_RATE_75 75... and so on.
    But we don't know if those specific values are needed for something else like an external device. Or even if they aren't needed that's hardly a WTF but just a WIBBI (wouldn't it be better if).


    The numbers at the end of the CTR_DTE_DATA_RATE_ are all common modem data rates in bits-per-second.  (Skip down to 25 & 27 and you'll see the most common 28.8kbps & 57kbps)
  • (unregistered)

    Wow. You quote a program I was once developing. Asynch+, from Blaise Computing. It was my responsibility to add the last but one 8 entries, due to the progress in modems. We did not have 153600 those days.

    (Sorry for writing it anonymously. The name is Vlad Patryshev.)

  • (cs) in reply to
    Anonymous:

    The numbers at the end of the CTR_DTE_DATA_RATE_ are all common modem data rates in bits-per-second.  (Skip down to 25 & 27 and you'll see the most common 28.8kbps & 57kbps)


    I know that. (You could say I'm old enough to know that). 
    I just was wondering what was the supposed WTF. From the post title I guessed the WTF was the value used for the defines doesn't match the data rate. I still believe that this thing alone hardly makes a WTF and even more, those specific values could be necessary.
  • (unregistered) in reply to Guayo

    Yes, this WTF is a bit lame -- bitfields for devices' io ports (perhaps the guy who worked on the program can say if that's what they are actually for) don't always come in a logical order and don't always map sensibly to their meanings. Here is one I used in the past:

    0 = 19200 baud
    1 = 1200 baud
    2 = 4800 baud
    3 = 150 baud

    It goes up to 7, but you get the picture. The rest are just as weird. (Actually, they're in the right order if you invert the order of the 3 bits and do a NOT on the result... makes some sense, I guess.)

  • (unregistered)

    For those of you fluent in... oh... even with a basic understanding of C#:

    http://www.experts-exchange.com/Programming/Programming_Languages/C_Sharp/Q_21229714.html

  • (cs) in reply to

    That hurt my eyes when I saw it [:'(]

  • (unregistered) in reply to
    :
    As for the second one, I think it's to do with picking up the result of GetLastError before the function that's going to generate the error is called. Difficult to tell from context though, as it could be an error for something else.


    I am not sure, though. Perhaps the code is responding to some other code. It would have to preserve the error code, do some other call and then report the error.
    But it does seem a small WTF to me.
  • (unregistered)

    The comment promises a whole lot of WTF... redefining constants in different header files, randomly flipping between the using the constant and its value... but then all we're shown is the definition. Where's the code with the WTF in it?

  • (unregistered) in reply to

    Thanks, for having enlightened my day with the most awesome "hello world" program I've ever seen...

    Even if its not fair to laugh from someone asking something (we all have asked something silly at least once), its really funny !!!

  • (unregistered)

    Randomly flipping between the define and the actual value is bad. But that should have been posted, not the define table... Although enum is better, I like #define's better 'cause I think they are easier to understand..

  • (unregistered) in reply to
    :
    I agree with other posters that the main code doesn't represent a WTF as it probably represents some hardware constants (they're not the PC UART values though - I just checked).

    There are many, many other types of UART out there, though.  16550A is not even half the story.
  • (unregistered)
    Alex Papadimoulis:

    What better way to give unsuspecting developers a challenge than to redefine some straightforward numeric constants to completely arbitrary values? How about hiding the #defines in different header files and randomly flipping between the using the constant (CTR_DTE_DATA_RATE_300) and its value (5) throughout the code.

    Depending on the context, this may actually be correct. For instance, if you're programming a serial interface chip, you'll have to load "5" into one of the configuration registers to mean a 300 baud data rate; the chip won't accept the actual "300" value.
  • (cs)

    Personally, I'd store this stuff in an INI file or something similiar so that for another device, you'd be able to just reference a new INI file (or edit an existing file) w/o needing to recompile your app. In the app, I'd load it up into some sort of hash table or similiar structure, so that the values can be looked up by "Rate" to return the proper value to use with the hardware. 

    If perhaps the user can choose their speed with a drop down, defining the data in the manner presented here will make the code for that simple task quite long and complicated!

  • (unregistered)

    Maybe those values are the way they're represented in the raw hardware addresses (registers)? Then again, I don't get the wtf of this. Should have put a description up what is CTR_DTE etc, I don't get it. :(

Leave a comment on “#define 1 as 2”

Log In or post as a guest

Replying to comment #:

« Return to Article