Asserting that they reinvented the wheel



  • Ok, I don't program much, but I stumbled upon this in SDL's source when integrating SDL_Mixer into my codebase:



    [code]/* Make sure the types really have the right sizes */

    #define SDL_COMPILE_TIME_ASSERT(name, x) <br/>
    typedef int SDL_dummy_ ## name[(x) * 2 - 1]



    {...}



    typedef enum {

    DUMMY_ENUM_VALUE

    } SDL_DUMMY_ENUM;



    #ifndef NDS

    SDL_COMPILE_TIME_ASSERT(enum, sizeof(SDL_DUMMY_ENUM) == sizeof(int));

    #endif[/code]



    Score 1 for inventing an assert clone that produces a false error message (negative array length) and score 2 for failing when short enums are enabled.



    EDIT:
    In fact, the entire of SDL_stdinc.h is comedy gold. Apparently dissatisfied with the performance of the cstdlib, they've implemented their own ASM memcpy/memset/etc. and some custom string handling macros that imitate toupper(), etc. just in case they don't exist.

    [code]#define SDL_memset4(dst, val, len) <br/>
    do { <br/>
    int u0, u1, u2; <br/>
    asm volatile ( <br/>
    "cld\n\t" <br/>
    "rep ; stosl\n\t" <br/>
    : "=&D" (u0), "=&a" (u1), "=&c" (u2) <br/>
    : "0" (dst), "1" (val), "2" ((Uint32)(len)) <br/>
    : "memory" ); <br/>
    } while(0)[/code]



  • Honestly, that's pretty tame as far as WTFs go.

    • The advantage of this assert is that it works at compile time, yet can check things the preprocessor can't (type sizes mostly).
    • If the array name is descriptive enough it doesn't matter the error message is wrong.
    • It's a pity SDL came to depend on enums being the same size as int, but at least this assert documents it.
    • As for reinventing the wheel, consider that SDL comes from the gaming world where this is common, plus the need to support a shitload of platforms (even on those where enums are variable, since enums-always-int is typically only a compiler option away; that makes this kind of thing a major pain in the keister to manage since the code as a result is ABI incompatible with libraries not compiled with this flag, but apparently it's common in games to have everything compiled in a non-standard ABI if required. Maybe that's TRWTF).
    • Plus, SDL_memset4 is a bad example of "reinventing the wheel" since it allows the repeating of 32-bit values/patterns instead of bytes (which is what memset does).


    1. This is the only way to have compile time assert in C (and C89 at that, e.g. Visual C++ still does not implement C99), so point 1 is invalid.
    2. The memory format is obviously important in some places, so there are two choices: check that the implementation-defined representation of enums is indeed int as all compilers do by default, or not use enums. I wouldn't call choosing the first option a WTF. (Note, that the third option, enums with specified storage are not an option, because major compilers like Visual C++ still don't support C99)
    3. The library has quite long history and has been ported to all kinds of platforms not compliant with this or that. These things were probably written when testing in some, possibly obscure, environment where the standard library did have performance issues (we are talking about manipulating bitmaps, so it's on order of megabytes and used very often) and missing symbols. The problems may or may not be gone now, but I definitely don't think they wrote these just in case.


  • @Bulb said:

    Visual C++ still does not implement C99

    It's funny how Microsoft always seems to find time to do everything except their job. This is an organization that emits (purported) paradigm shifts as if doing so were some sort of bodily function, but takes 22+ years to get "C" right.

    Since 1989, we have had all of the following foisted upon us:

    COM

    Win32

    .NET

    MFC

    WPF / Silverlight

    ASP.NET

    ASP.NET "MVC"

    And now, some sort of perverse, HTML5-based programming model that seems to me to be "Active Desktop Revisited"

    Each of these has been delivered with Earth-shattering, "hey-you're-doing-it-wrong" machismo.

    I bet some of those flight simulator programmers they fired for no reason (other than being smarter than Scott Guthrie) could have implemented C99.



  • Slashdot's that way ---->


  • Discourse touched me in a no-no place

    @bridget99 said:

    @Bulb said:

    Visual C++ still does not implement C99

    It's funny how Microsoft always seems to find time to do everything except their job. This is an organization that emits (purported) paradigm shifts as if doing so were some sort of bodily function, but takes 22+ years to get "C" right.

    They're not even trying - they even 'deprecate' standard functions which they shouldn't be doing.


  • @PJH said:

    @bridget99 said:

    @Bulb said:

    Visual C++ still does not implement C99

    It's funny how Microsoft always seems to find time to do everything except their job. This is an organization that emits (purported) paradigm shifts as if doing so were some sort of bodily function, but takes 22+ years to get "C" right.

    They're not even trying - they even 'deprecate' standard functions which they shouldn't be doing.

     

    You mean you wouldn't rather use super_safe_sprintf_EX_we_promise_this_is_the_last_one() instead of plain old sprintf?? Dude, slashdot's that way!

    Life with Microsoft is a colostomy grab-bag. You never know what kind of crap is going to pop up.


  • Discourse touched me in a no-no place

    @bridget99 said:

    You mean you wouldn't rather use super_safe_sprintf_EX_we_promise_this_is_the_last_one() instead of plain old sprintf?
    I'd rather use snprintf() to either of those two.



  • @blakeyrat said:

    Slashdot's that way ---->

    So the message here is that Microsoft WTFs are off limits?



  • @PJH said:

    @bridget99 said:
    You mean you wouldn't rather use super_safe_sprintf_EX_we_promise_this_is_the_last_one() instead of plain old sprintf?
    I'd rather use snprintf() to either of those two.

    Well, as Werner Erhard said to the Quaker, "I hear thee."

    Personally, I would rather use sprintf(), and use it on a system whose architecture and function are so far off the metaphorical beaten path (i.e. the Internet) that security, other than physical security, is a non-issue.



  • @boomzilla said:

    @blakeyrat said:
    Slashdot's that way ---->

    So the message here is that Microsoft WTFs are off limits?

    Ok it was a little harsh. I was mostly responding to the WTF of saying that Microsoft introducing new development tools/languages is a bad thing. Which is stupid. "What is this crappy .net stuff? We should be writing programs like it's 1973, damnit! GET OFF MY LAWN!"

    The WTF about not supporting C standards is valid.



  • @boomzilla said:

    @blakeyrat said:
    Slashdot's that way ---->
    So the message here is that Microsoft WTFs are off limits?

    I have definitely made that complaint before. Typographical errors in obscure Linux "man" pages prompt raucous knee-slapping here, but Earth-shattering stupidity on Microsoft's part (e.g. sacrificing the Flight Simulator team) provokes only snide remarks about Slashdot.

    Incidentally, I've never even read Slashdot. If I browsed to it, it was accidental.



  • @blakeyrat said:

    I was mostly responding to the WTF of saying that Microsoft introducing new development tools/languages is a bad thing. Which is stupid. "What is this crappy .net stuff? We should be writing programs like it's 1973, damnit! GET OFF MY LAWN!"

    The WTF about not supporting C standards is valid.

    Actually, I think his point was very similar to ones you bring up about old Mozilla bugs (or whatever) that have been ignored in favor of new shiny development. In this case, of course, not supporting C99 is a bigger deal than some icon in a print dialog. But I suppose someone with a sensitive disposition could have easily missed that point and saw it as standard issue MS hate.


  • @blakeyrat said:

    @boomzilla said:
    @blakeyrat said:
    Slashdot's that way ---->
    So the message here is that Microsoft WTFs are off limits?
    Ok it was a little harsh. I was mostly responding to the WTF of saying that Microsoft introducing new development tools/languages is a bad thing. Which is stupid. "What is this crappy .net stuff? We should be writing programs like it's 1973, damnit! GET OFF MY LAWN!"

    The WTF about not supporting C standards is valid.

    My point is not so much that we should be writing programs like it's 1973, but that one should fix one's 1973-vintage bugs before loudly attempting to change the whole world for the better.

    Isn't anyone else tired of the relentless paradigm-shifting that characterizes technology product releases? If Windows 1,000 is really that much better than Windows 999, what does that say about Windows 999, Windows 998, etc.? What does it say about Microsoft's product development process... and if Windows 999 is now crap, but was once relentlessly hyped, then what does that say about the veracity and relevance of Microsoft's marketing and documentation? (Nothing positive, I believe.)

    If I am really "doing things wrong," it's only because the Microsoft of five minutes ago said to do things that way. And why should I trust them now when they told me to do everything wrong before?

    The old saw about building a better mousetrap has been abandoned. Instead, manufacturers chide us for ever even worrying about anything so pedestrian and un-enterprisey as a rodent.

    BTW, I heard that Scott Guthrie build a better Gerbil-trap. But that's a WHOLE different topic...



  • @bridget99 said:

    My point is not so much that we should be writing programs like it's 1973, but that one should fix one's 1973-vintage bugs before loudly attempting to change the whole world for the better.

    As it turns out, Microsoft's not just one guy in the garage. If you have a beef with the C team, take it up with the C team. That has nothing to do with the MVC team, the .Net team, the COM+ team, etc. Those are all different people.

    @bridget99 said:

    If I am really "doing things wrong," it's only because the Microsoft of five minutes ago said to do things that way. And why should I trust them now when they told me to do everything wrong before?

    Joel Spolsky had an article where he claimed this was a conspiracy theory (seriously) to keep Microsoft competitors wasting their time porting products instead of building good software. I can look up the URL if someone wants it...



  • @blakeyrat said:

    @bridget99 said:
    My point is not so much that we should be writing programs like it's 1973, but that one should fix one's 1973-vintage bugs before loudly attempting to change the whole world for the better.

    As it turns out, Microsoft's not just one guy in the garage. If you have a beef with the C team, take it up with the C team. That has nothing to do with the MVC team, the .Net team, the COM+ team, etc. Those are all different people.

    My issue is that Microsoft misallocates resources to reinvent-the-whole-world projects instead of more useful nuts-and-bolts projects. Those "teams" you describe are staffed and purposed by Microsoft. They're not some kind of organic truth that Microsoft has to accept.

    @blakeyrat said:

    @bridget99 said:
    If I am really "doing things wrong," it's only because the Microsoft of five minutes ago said to do things that way. And why should I trust them now when they told me to do everything wrong before?

    Joel Spolsky had an article where he claimed this was a conspiracy theory (seriously) to keep Microsoft competitors wasting their time porting products instead of building good software. I can look up the URL if someone wants it...

    I have read that column, and I agree with it wholeheartedly. Microsoft benefits from the chaos they create. Everyone else is busy re-writing MS-DOS into Win16 into Win32 into MFC into WinForms into Silverlight into HTML5. If there were really any point to it, then Microsoft would at least port their own code to these awesome new technologies (e.g. DirectX, which is COM, and Office automation, which is COM, and the rest of Windows, which is C). They don't... but we still have to use the wrapper (e.g. .NET, with its lame Office "PIAs") or we're knuckle-dragging Luddites. The fact that they've gotten away with this is a testament to the stupidity of Management as a field-of-work and of Capitalism and Democracy as economic systems.



  • @nexekho said:



    Score 1 for inventing an assert clone that produces a false error message (negative array length) and score 2 for failing when short enums are enabled.

    As pointed out, 1 is invalid because that is the bog-standard C idiom for a compile-time assertion,and 2 is invalid, because that's the whole point of that code: to make sure short enums are not enabled.  Why did you ignore the immediately-preceding comment?

    @SDL_stdinc.h said:

    [code]/** @name Enum Size Check
    * Check to make sure enums are the size of ints, for structure packing.
    * For both Watcom C/C++ and Borland C/C++ the compiler option that makes
    * enums having the size of an int must be enabled.
    * This is "-b" for Borland C/C++ and "-ei" for Watcom C/C++ (v11).
    */[/code]

    @nexekho said:

    EDIT: In fact, the entire of SDL_stdinc.h is comedy gold. Apparently dissatisfied with the performance of the cstdlib, they've implemented their own ASM memcpy/memset/etc. and some custom string handling macros that imitate toupper(), etc. just in case they don't exist.

    <font face="Lucida Console" size="2">#define SDL_memset4(dst, val, len)
    do {
    int u0, u1, u2;
    __asm__ __volatile__ (
    "cld "
    "rep ; stosl "
    : "=&D" (u0), "=&a" (u1), "=&c" (u2)
    : "0" (dst), "1" (val), "2" ((Uint32)(len))
    : "memory" );
    } while(0)</font>

    That differs from the library memset in a significant way: it guarantees that the accesses are done in word-sized units.



  • @PJH said:

    @bridget99 said:
    You mean you wouldn't rather use super_safe_sprintf_EX_we_promise_this_is_the_last_one() instead of plain old sprintf?
    I'd rather use snprintf() to either of those two.
    But snprintf doesn't clear the buffer before writing to it, and is vulnerable to side-channel timing leaks, and doesn't sanitize invalid UTF-8 sequences or validate the source address or ask for a password! That means every single instance of snprintf in your program is a huge gaping security hole! Even the ones that never see user input!


  • Discourse touched me in a no-no place

    @lolwtf said:

    @PJH said:
    @bridget99 said:
    You mean you wouldn't rather use super_safe_sprintf_EX_we_promise_this_is_the_last_one() instead of plain old sprintf?
    I'd rather use snprintf() to either of those two.
    But snprintf doesn't clear the buffer before writing to it, and is vulnerable to side-channel timing leaks, and doesn't sanitize invalid UTF-8 sequences or validate the source address or ask for a password!
    Neither does super_safe_sprintf_EX_we_promise_this_is_the_last_one(). super_safe_sprintf_EX_we_promise_this_is_the_last_one_ex() might though.



  • @ZPedro said:

    It's a pity SDL came to depend on enums being the same size as int, but at least this assert documents it.
    Likely that’s its C heritage, where [code]enum[/code]s [i]are[/i] [code]int[/code]s.


Log in to reply
 

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