• Spectre (unregistered) in reply to Lingerance
    Lingerance:
    BK:
    trivial. It's a vtable implementation in C and these NULLs are pointers to (abstract) virtual functions. Someone must have hated C++ so much they decided to rewrite it in C.

    Implementing your own vtable in C is stupid since you almost always get a C++ compiler to go with your C compiler.

    Dude, I don't know about that. I think your stupid for begging the question that C++ is a superior language.

  • Mike (unregistered)

    For those who say it's not a WTF, you are wrong. Sure it looks like a vtable, but how the hell do you maintain code where data is floating in a sea of NULLs?

    Here's a maintainable implementation. I assume here that there are constants for what the offsets mean, but that's probably optimistic.

    memset( vtable, 0, sizeof( vtable ) ); vtable[METHOD_START] = &start_diagnostic_session; vtable[METHOD_READ_ECU] = &read_ecu_identification; vtable[METHOD_READ_DATA] = &rd_data_by_common_identifier; vtable[METHOD_SECURITY] = &security_access; vtable[METHOD_WRITE_DATA] = &wr_data_by_common_identifier;

  • (cs) in reply to Spectre
    Spectre:
    Lingerance:
    BK:
    trivial. It's a vtable implementation in C and these NULLs are pointers to (abstract) virtual functions. Someone must have hated C++ so much they decided to rewrite it in C.

    Implementing your own vtable in C is stupid since you almost always get a C++ compiler to go with your C compiler.

    Dude, I don't know about that. I think your stupid for begging the question that C++ is a superior language.

    My old college teacher said C++ is only superior to C if you consider amount of documents produced by it.

  • Smitty (unregistered) in reply to Mike
    Mike:
    For those who say it's not a WTF, you are wrong. Sure it looks like a vtable, but how the hell do you maintain code where data is floating in a sea of NULLs?

    Here's a maintainable implementation. I assume here that there are constants for what the offsets mean, but that's probably optimistic.

    memset( vtable, 0, sizeof( vtable ) ); vtable[METHOD_START] = &start_diagnostic_session; vtable[METHOD_READ_ECU] = &read_ecu_identification; vtable[METHOD_READ_DATA] = &rd_data_by_common_identifier; vtable[METHOD_SECURITY] = &security_access; vtable[METHOD_WRITE_DATA] = &wr_data_by_common_identifier;

    I don't like the superfluous memset. What's wrong with this?
    static void (*const SID[MAX_NUM_SERVICE_IDENTIFIERS])
                ( const u8 *data, const u16 bytes ) = {0};
    vtable[METHOD_START] = &start_diagnostic_session;
    vtable[METHOD_READ_ECU] = &read_ecu_identification;
    vtable[METHOD_READ_DATA] = &rd_data_by_common_identifier;
    vtable[METHOD_SECURITY] = &security_access;
    vtable[METHOD_WRITE_DATA] =  &wr_data_by_common_identifier;
    
  • (cs) in reply to Abso
    Abso:
    ¢ÃƒÆ’ƒâ€Ãâ€:
    Nagesh:
    It would be so easy, if everyone registered. This unregistered commentating is driving up the troll ratio.

    For the record, I am not against trolls if they happen to be witty. One troll who has tried to be witty from time to time is hoodacticus.

    If you are going to troll, be an entertaining troll. Don't be stick in mud garden vareity troll.

    No, Nagesh, you are not an entertaining troll. Stop wishing that you could be a "good" troll.

    But he's registered, so clearly he's not part of the problem at all.

    That is exactly right.

    If you're not part of problem, you end up being part of the solution provider.

    ...Martin Luthor King.

  • NOT the original, ORIGINAL by (unregistered) in reply to Nagesh
    Nagesh:
    Abso:
    ¢ÃƒÆ’ƒâ€Ãâ€:
    Nagesh:
    It would be so easy, if everyone registered. This unregistered commentating is driving up the troll ratio.

    For the record, I am not against trolls if they happen to be witty. One troll who has tried to be witty from time to time is hoodacticus.

    If you are going to troll, be an entertaining troll. Don't be stick in mud garden vareity troll.

    No, Nagesh, you are not an entertaining troll. Stop wishing that you could be a "good" troll.

    But he's registered, so clearly he's not part of the problem at all.

    That is exactly right.

    If you're not part of problem, you end up being part of the solution provider.

    ...Martin Luthor King.

    Nagesh, please stop posting... I still have a ringing in my ears from reading your posts. I think I'm going to write up something in Greasemonkey to visually block his posts from my screen.

  • ¢ÃƒÆ’Æâ€à (unregistered) in reply to Nagesh
    Nagesh:
    All Females:
    hoodaticus:
    boog:
    Nagesh:
    One troll who has tried to be witty from time to time is hoodacticus.
    Tried and succeeded. Good job hoodie! (btw, can I call you hoodie? how about hoodarino?)
    Thanks, boog! You're one of my few favorites on here, and you can call me whatever you want.
    *gag*

    You win "The lamest handle in WTF." award.

    Nagesh, it doesn't count when you give yourself the award.
  • (cs) in reply to Nagesh
    Nagesh:
    My old college teacher said C++ is only superior to C if you consider amount of documents produced by it.
    Who cares?
  • PJH (unregistered) in reply to hoodaticus
    hoodaticus:
    Nagesh:
    My old college teacher said C++ is only superior to C if you consider amount of documents produced by it.
    Who cares?

    I do.
    Dear Internets,

    Please post all of your stories about old teachers, bosses, and parents on this thread.

    Sincerely, TDWTF HiveMind(tm)

  • SP (unregistered) in reply to Mike
    Mike:
    For those who say it's not a WTF, you are wrong. Sure it looks like a vtable, but how the hell do you maintain code where data is floating in a sea of NULLs?

    Here's a maintainable implementation. I assume here that there are constants for what the offsets mean, but that's probably optimistic.

    memset( vtable, 0, sizeof( vtable ) ); vtable[METHOD_START] = &start_diagnostic_session; vtable[METHOD_READ_ECU] = &read_ecu_identification; vtable[METHOD_READ_DATA] = &rd_data_by_common_identifier; vtable[METHOD_SECURITY] = &security_access; vtable[METHOD_WRITE_DATA] = &wr_data_by_common_identifier;

    That's very nice. But in small embedded systems -- which this presumably is -- we tend to favour storing things in program memory (i.e., flash or ROM) rather than in RAM. Firstly RAM's a precious resource (you might have, say, 512K of Flash and only 16K or RAM) so you don't want to waste it on non-varying things. And secondly you want to try and ensure that your code doesn't get corrupted (by cosmic rays or errant pointers elsewhere), and storing your lookup table in flash helps with this -- remember that your system may reset very rarely, perhaps only when the battery is disconnected.

    Incidentally you don't need the ampersand. Some coding standards rule against it. Also, on many automotive systems the standard library (e.g., memset) is not available or its usage is discouraged. Oh yes, and null pointers are not guaranteed to be "all bits zero", so that's going to need a deviation against MISRA-C.

    The original code isn't the tidiest I've ever seen, but it's fairly typical automotive code. The requirements, standards and development principles for this stuff are very different to what is state of the art for non-embedded applications software, but its no WTF.

  • (cs) in reply to fruits
    fruits:
    Nagesh:
    It would be so easy, if everyone registered. This unregistered commentating is driving up the troll ratio.

    ...

    If you are going to troll, be an entertaining troll. Don't be stick in mud garden vareity troll.

    The comedy here is so sweet, I think I'll be skipping lunch today

    That sounds... familiar. Yeah, familiar.

    Addendum (2011-02-23 17:14): But I wholeheartedly agree and approve.

  • Katy GaGa (unregistered) in reply to Behold
    Behold:
    Interestingly, this is pretty much how you write Python modules in C (that is, bindings to C code for Python). Except I think the array is even larger there.
    Pretty similar, except that in Python you'd write "spam" instead of "null."
  • Nagesh (unregistered) in reply to Katy GaGa

    Someone has stolen my account here! The impostor has posting in my account and defiling the name of my namesake. I did not notice until now because I was inspire by today's code. I am implementing it in code I am writing for big client, they will be very happy with this. I have shared this code with all my colleagues here in Hyderabad, we all agree this is the best code written. I do not know why you post this code on your site, there is no WTF in it at all. Thanks, Daily WTF!

  • ¢ÃƒÆâ₠(unregistered) in reply to Nagesh
    Nagesh:
    Someone has stolen my account here! The impostor has posting in my account and defiling the name of my namesake. I did not notice until now because I was inspire by today's code. I am implementing it in code I am writing for big client, they will be very happy with this. I have shared this code with all my colleagues here in Hyderabad, we all agree this is the best code written. I do not know why you post this code on your site, there is no WTF in it at all. Thanks, Daily WTF!
    Nagesh is TRWTF.

    And you call us racist for saying outsourced code from India sucks?

  • (cs) in reply to SP
    SP:
    Mike:
    For those who say it's not a WTF, you are wrong. Sure it looks like a vtable, but how the hell do you maintain code where data is floating in a sea of NULLs?

    Here's a maintainable implementation. I assume here that there are constants for what the offsets mean, but that's probably optimistic.

    memset( vtable, 0, sizeof( vtable ) ); vtable[METHOD_START] = &start_diagnostic_session; vtable[METHOD_READ_ECU] = &read_ecu_identification; vtable[METHOD_READ_DATA] = &rd_data_by_common_identifier; vtable[METHOD_SECURITY] = &security_access; vtable[METHOD_WRITE_DATA] = &wr_data_by_common_identifier;

    That's very nice. But in small embedded systems -- which this presumably is -- we tend to favour storing things in program memory (i.e., flash or ROM) rather than in RAM. Firstly RAM's a precious resource (you might have, say, 512K of Flash and only 16K or RAM) so you don't want to waste it on non-varying things. And secondly you want to try and ensure that your code doesn't get corrupted (by cosmic rays or errant pointers elsewhere), and storing your lookup table in flash helps with this -- remember that your system may reset very rarely, perhaps only when the battery is disconnected.

    Incidentally you don't need the ampersand. Some coding standards rule against it. Also, on many automotive systems the standard library (e.g., memset) is not available or its usage is discouraged. Oh yes, and null pointers are not guaranteed to be "all bits zero", so that's going to need a deviation against MISRA-C.

    The original code isn't the tidiest I've ever seen, but it's fairly typical automotive code. The requirements, standards and development principles for this stuff are very different to what is state of the art for non-embedded applications software, but its no WTF.

    Thank you for explaining that. I couldn't for the life of me figure out why this code is the way it is.

    A quibble, though. If size is the issue, and the vtable is not dynamic, why the hell would there be nulls?

  • ........................... (unregistered) in reply to Nagesh
    Nagesh:
    boog:
    I'm pretty sure I would have strangled the penguin before I got to the 4th NULL.

    What is strangling the penguin? Is this a BATMAN reference?

    Maybe it's something like choking the chicken but more linuxey way?

  • Nagesh (unregistered) in reply to ¢ÃƒÆââ‚Â
    ¢ÃƒÆââ‚Â:
    Nagesh is TRWTF.

    And you call us racist for saying outsourced code from India sucks?

    You are TWRTF and you are racist. Our code is much better than any USA code you can name, I dare you to prove different. Our last client paid lots of money for our code and they were so happy they got a faster server to run our code. I also wrote 6 thousand lines of code yesterday. I would have coded more but my keyboard is not working well, the keys do not always work so I ut and paste with the mouse.

  • The Web is the Root of All Info (unregistered) in reply to SnatchThePebblesFromMyHand
    SnatchThePebblesFromMyHand:
    "Assemblies" in 1998? You're not fooling me, young grasshopper.
    It was *originally* in VB6 (around ~1998), then got ported to VB.Net.

    The free online book on how to do this: http://msdn.microsoft.com/en-us/vbasic/ms788236

  • Mike (unregistered) in reply to SP
    SP:
    But in small embedded systems -- which this presumably is -- we tend to favour storing things in program memory (i.e., flash or ROM) rather than in RAM. Firstly RAM's a precious resource (you might have, say, 512K of Flash and only 16K or RAM) so you don't want to waste it on non-varying things. And secondly you want to try and ensure that your code doesn't get corrupted (by cosmic rays or errant pointers elsewhere), and storing your lookup table in flash helps with this -- remember that your system may reset very rarely, perhaps only when the battery is disconnected.
    Fair enough. It's unfortunate that C doesn't have better ways of specifying table layouts than buffer stuffing.
  • (cs) in reply to JamesCurran

    [quote user="JamesCurran" Well, I'd agree with you -- if they filled the array. For five entries, they'd be far better off with a different method. How 'bout 5 if()s :

         if(op == OP_START_DIAGNOSTIC)
            start_diagnostic_session(len, dataptr);
    

    Way more clear as to what it's doing, and a helluva lot smaller that wasting 512 (or 1024, depending on function pointer size) bytes on the sparely populated array. [/quote]

    What you (and a bunch of other here are forgetting is there is a world of difference between compile time constants [stored in ROM] and runtime (even startup) calculation [stored in RAM]

    I recendly did an embedded system, 256KB of ROM [Mask, not prom,eerom,etc.] and 2K RAM [radiation hardened RAM is EXPENSIVE].

    There was one class which required about 40 bytes per instance, and had about 500 possible states (valid combinations of the members). Instead of using a conventional implmentation of fields in the clas holding the values, we stored ALL of the possible states in ROM [20KB], and each instance contained a single pointer to the appropriate state. When a calculation was performed on an instance, a "full" version was reconstituted in RAM, then calculations performed, and a search (optimized) of all of the possible values performed to find the appropriate match, we then retained just a "freeze dried" version.

  • An alternate explanation (unregistered) in reply to Childish
    Childish:
    C3PO:
    Obviously, Brian does not understand C. He probably thinks it's like Java™, where references new arrays are initialized to [n]null[/b] or 0 (depending on type) automatically. In C, if you initialize a structure, it is filled with random bits and bytes. This could be a sparse array or a fixed-state machine, which should in either case contain a valid base-case value.

    I would think that a "real" C programmer would just use 0 here, but maybe that is TRWTF?

    A real C programmer would use memset() here.

    void *memset(void *s, int c, size_t n);

    /* set buff buffer to zeroes. */ memset(buff, 0, sizeof(buff));

    In that case the real developer might have introduced a bug. It is not safe to memset pointers because a null pointer don't have to be numeric 0(All bits 0).

  • (cs) in reply to TheCPUWizard
    TheCPUWizard:
    What you (and a bunch of other here are forgetting is there is a world of difference between compile time constants [stored in ROM] and runtime (even startup) calculation [stored in RAM]

    I recendly did an embedded system, 256KB of ROM [Mask, not prom,eerom,etc.] and 2K RAM [radiation hardened RAM is EXPENSIVE].

    There was one class which required about 40 bytes per instance, and had about 500 possible states (valid combinations of the members). Instead of using a conventional implmentation of fields in the clas holding the values, we stored ALL of the possible states in ROM [20KB], and each instance contained a single pointer to the appropriate state. When a calculation was performed on an instance, a "full" version was reconstituted in RAM, then calculations performed, and a search (optimized) of all of the possible values performed to find the appropriate match, we then retained just a "freeze dried" version.

    I have this nagging suspicion that, if you take the enire inheritance hierarchy for this class and superimpose their vtables on overhead projector transparencies (pretending that NULL is just invisible), they all go to the same places. I think they're using vtables to selectively hide base class members. I don't think that's real inheritance, and I don't see why they would need a vtable if the classes they need to dispatch on are so violently different. They could just write separate classes for them and be done with it.

    Or I could be wrong, and they used a random number generator to decide where to put their base class members in the vtable.

  • (cs) in reply to Nagesh
    Nagesh:
    ¢ÃƒÆââ‚Â:
    Nagesh is TRWTF.

    And you call us racist for saying outsourced code from India sucks?

    You are TWRTF and you are racist. Our code is much better than any USA code you can name, I dare you to prove different. Our last client paid lots of money for our code and they were so happy they got a faster server to run our code. I also wrote 6 thousand lines of code yesterday. I would have coded more but my keyboard is not working well, the keys do not always work so I ut and paste with the mouse.
    I almost lost bladder control from laughing so hard you asshole!

  • (cs) in reply to ¢ÃƒÆââ‚Â
    Â)¢ÃƒÆ’Æâ₠(1718 hours):
    Nagesh (unregistered) (1713 hours + immediate:
    Someone has stolen my account here! The impostor has posting in my account and defiling the name of my namesake. I did not notice until now because I was inspire by today's code. I am implementing it in code I am writing for big client, they will be very happy with this. I have shared this code with all my colleagues here in Hyderabad, we all agree this is the best code written. I do not know why you post this code on your site, there is no WTF in it at all. Thanks, Daily WTF!
    Nagesh is TRWTF.

    And you call us racist for saying outsourced code from India sucks?

    How many Nageshes are you, honestly? +10 if you answer, "We are Legion."

  • (cs) in reply to Mike
    Mike:
    For those who say it's not a WTF, you are wrong. Sure it looks like a vtable, but how the hell do you maintain code where data is floating in a sea of NULLs?

    Here's a maintainable implementation. I assume here that there are constants for what the offsets mean, but that's probably optimistic.

    memset( vtable, 0, sizeof( vtable ) ); vtable[METHOD_START] = &start_diagnostic_session; vtable[METHOD_READ_ECU] = &read_ecu_identification; vtable[METHOD_READ_DATA] = &rd_data_by_common_identifier; vtable[METHOD_SECURITY] = &security_access; vtable[METHOD_WRITE_DATA] = &wr_data_by_common_identifier;

    Dude, you just added like, 20 to 30 bytes to the size of the .text section with those stupid assignment instructions. And you caused the vtable to now have to exist in writable memory, which is at a premium on most embedded systems, instead of living on a cheap ROM. You fail.

    Ever read that paper, "Incompetent and Unaware of it?"

  • (cs) in reply to hoodaticus
    hoodaticus:
    Or I could be wrong, and they used a random number generator to decide where to put their base class members in the vtable.

    Based on the code, I see no evidence that it is a vtable (i.e. a methodology for dispatching calls for an overridable method in a class). In fact, there is no evidence of any object oriented elements. It is a simple function dispatch table.

    Looking back at the comments, it is quite likely that "vtable' was brought of more as an analogy than as a proper usage of the term.

  • Mr Automotive Man (unregistered)

    This is clearly (at least to me) a KWP2000 (Keyword Protocol) dispatcher from an automotive ECU.

    My company usually buys this part of the system from a third party supplier either in the form of source code or a precompiled library, which comes along with a code generator which generates ROM tables like this. This specific table is used to map the SIDs or service IDs (a standard term from the relevant ISO standard) which come in the fist byte of the request message to the function that handles that specific service. Normally this part of the code is generated automatically and is part of the third party module, and it is calling functions in the device specific code (written by us).

    The benefit of writing the SIDs table like this is obviously faster lookup at the expense of a bit of extra ROM being used. Different ECUs would have more services defined so the table would be less sparse. Fortunately the third party solutions that we use are a little smarter and have two columns, one for the service ID and the other for the function pointer!

  • Mike (unregistered) in reply to smxlong
    smxlong:
    Dude, you just added like, 20 to 30 bytes to the size of the .text section with those stupid assignment instructions. And you caused the vtable to now have to exist in writable memory, which is at a premium on most embedded systems, instead of living on a cheap ROM. You fail.

    Ever read that paper, "Incompetent and Unaware of it?"

    Do you know the RAM budget on this project? If it's megabytes, you're prematurely optimizing. If it's kilobytes, you are right: it makes sense to sacrifice some readability. Where I work, the highest cost is paying developers - hardware is dirt cheap in comparison. In this environment, maintainable code is more valuable by many orders of magnitude than 290 bytes of RAM.

  • Alexander (unregistered)

    I don't see a WTF here. This is a lookup table to choose functionality based on an opcode. They initialize everything they know at compile time with the real values and everything else cleanly with null. Of course you could write that in a loop, but why waste precious runtime if you can do it at compile time? Computers weren't always as fast as they are now.

  • Not of this Earth (unregistered) in reply to boog

    Umm... Where am I? Oh, not so much WTFs in articles as in the comments...

  • Bert Glanstron (unregistered)

    I have NULLed your array. Pray I don't NULL it further.

  • aks (unregistered)

    I also don't see the WTF. A function pointer dispatch table is anyday better than a giant fugly switch(){ case : } or a huge if () else if(). Not to mention better maintainablity and way way way more faster than those comparisions can ever dream of becoming (think pipelining on ARMs). Plus I doubt that somebody wrote that by hand, it probably was generated using a tool (or Excel, which is excellent for maintaining such arrays and readability). I guess that the author has not found the tool (or the excel sheet) to do so and is bitching about it.

  • Guest (unregistered)

    It really is like I'm looking at the Win32 API!

  • (cs)

    Sing along... "99 NULLs in the method call, 99 NULLs in the call. You take one down - pass it around, 98 NULLs in the method call..."

  • (cs) in reply to Lingerance
    Lingerance:
    BK:
    trivial. It's a vtable implementation in C and these NULLs are pointers to (abstract) virtual functions. Someone must have hated C++ so much they decided to rewrite it in C.

    Implementing your own vtable in C is stupid since you almost always get a C++ compiler to go with your C compiler.

    Dude, considering the function prototype starts with the word static (aren't all functions in C static, variables are a different story, but functions...), I don't think he's working with a vanilla C compiler, and this thing is really as misguided as it looks.

    Addendum (2011-02-24 08:35):

    Lingerance:
    BK:
    trivial. It's a vtable implementation in C and these NULLs are pointers to (abstract) virtual functions. Someone must have hated C++ so much they decided to rewrite it in C.

    Implementing your own vtable in C is stupid since you almost always get a C++ compiler to go with your C compiler.

    Well, it may seem so, however if you're developing for an embedded environment, without a file system, then it may well be considered best practice.
  • __moz (unregistered) in reply to aks
    aks:
    I also don't see the WTF. A function pointer dispatch table is anyday better than a giant fugly switch(){ case : } or a huge if () else if(). Not to mention better maintainablity and way way way more faster than those comparisions can ever dream of becoming (think pipelining on ARMs). Plus I doubt that somebody wrote that by hand, it probably was generated using a tool (or Excel, which is excellent for maintaining such arrays and readability). I guess that the author has not found the tool (or the excel sheet) to do so and is bitching about it.

    Imagine that. Some hotshot knowitall developer submitted something that extends beyond his limited firsthand experience as a WTF.

  • (cs) in reply to funluvncriminal

    [quote user="funluvncriminalDude, considering the function prototype starts with the word static (aren't all functions in C static, variables are a different story, but functions...), I don't think he's working with a vanilla C compiler, and this thing is really as misguided as it looks.[/quote]

    You need to go learn C.... elements at File Scope can be either extern (visible to other compile units) or static (available only within the compilation unit). In this regard there is no difference between C and C++.

  • (cs) in reply to Nagesh
    Nagesh:
    ¢ÃƒÆââ‚Â:
    Nagesh is TRWTF.

    And you call us racist for saying outsourced code from India sucks?

    You are TWRTF and you are racist. Our code is much better than any USA code you can name, I dare you to prove different. Our last client paid lots of money for our code and they were so happy they got a faster server to run our code. I also wrote 6 thousand lines of code yesterday. I would have coded more but my keyboard is not working well, the keys do not always work so I ut and paste with the mouse.

    Why you force client to buy new server? OUr client still running our super fast quick code on 486 and Pentium machine. He never complain. Truly good code is one that runs on less resources.

  • Lingerance (unregistered) in reply to Nagesh
    Nagesh:
    Nagesh:
    ¢ÃƒÆââ‚Â:
    Nagesh is TRWTF.

    And you call us racist for saying outsourced code from India sucks?

    You are TWRTF and you are racist. Our code is much better than any USA code you can name, I dare you to prove different. Our last client paid lots of money for our code and they were so happy they got a faster server to run our code. I also wrote 6 thousand lines of code yesterday. I would have coded more but my keyboard is not working well, the keys do not always work so I ut and paste with the mouse.

    Why you force client to buy new server? OUr client still running our super fast quick code on 486 and Pentium machine. He never complain. Truly good code is one that runs on less resources.

    I'm still not sure why we let Indians write code anyway. Is it some sort of reparations? Isn't giving casinos to you enough?
  • World Traveler (unregistered) in reply to hoodaticus
    hoodaticus:
    Â)¢ÃƒÆ’Æâ₠(1718 hours):
    Nagesh (unregistered) (1713 hours + immediate:
    Someone has stolen my account here! The impostor has posting in my account and defiling the name of my namesake. I did not notice until now because I was inspire by today's code. I am implementing it in code I am writing for big client, they will be very happy with this. I have shared this code with all my colleagues here in Hyderabad, we all agree this is the best code written. I do not know why you post this code on your site, there is no WTF in it at all. Thanks, Daily WTF!
    Nagesh is TRWTF.

    And you call us racist for saying outsourced code from India sucks?

    How many Nageshes are you, honestly? +10 if you answer, "We are Legion."
    Ever visit India? It's impossible to park your car without running over 5 or 6 guys who answer to "Nagesh."

  • (cs) in reply to Lingerance
    Lingerance:
    Nagesh:
    Nagesh:
    ¢ÃƒÆââ‚Â:
    Nagesh is TRWTF.

    And you call us racist for saying outsourced code from India sucks?

    You are TWRTF and you are racist. Our code is much better than any USA code you can name, I dare you to prove different. Our last client paid lots of money for our code and they were so happy they got a faster server to run our code. I also wrote 6 thousand lines of code yesterday. I would have coded more but my keyboard is not working well, the keys do not always work so I ut and paste with the mouse.

    Why you force client to buy new server? OUr client still running our super fast quick code on 486 and Pentium machine. He never complain. Truly good code is one that runs on less resources.

    I'm still not sure why we let Indians write code anyway. Is it some sort of reparations? Isn't giving casinos to you enough?

    What casinos? Gambling is illegal in India.

    True story from Mahabharat. Look up Yudishthira, Draupadi, Gambling, Dice, Shakuni, Pandav.
  • Daniel (unregistered) in reply to Mr Automotive Man

    Definitely KWP2000. I don't see what's really that wrong with the code - maybe it could have been initialised a little more clearly but it's obvious to anyone who's been in the vehicle/automotive/machine control industry for more than 5 minutes what it is and what it does.

  • (cs) in reply to NOT the original, ORIGINAL by
    NOT the original:
    Nagesh:
    Abso:
    ¢ÃƒÆ’ƒâ€Ãâ€:
    Nagesh:
    It would be so easy, if everyone registered. This unregistered commentating is driving up the troll ratio.

    For the record, I am not against trolls if they happen to be witty. One troll who has tried to be witty from time to time is hoodacticus.

    If you are going to troll, be an entertaining troll. Don't be stick in mud garden vareity troll.

    No, Nagesh, you are not an entertaining troll. Stop wishing that you could be a "good" troll.

    But he's registered, so clearly he's not part of the problem at all.

    That is exactly right.

    If you're not part of problem, you end up being part of the solution provider.

    ...Martin Luthor King.

    Nagesh, please stop posting... I still have a ringing in my ears from reading your posts. I think I'm going to write up something in Greasemonkey to visually block his posts from my screen.

    You have failed! Why make so much noise about writing some script?

    You limp wristed, lack of moral fiber, noise making hypocrite cannot ignore me. That's true WTF.

    We are legion... There I said it.. hoodarino.
  • Daniel (unregistered) in reply to Daniel

    Forgot to mention: not necessarily precisely ISO 14230 Keyword Protocol 2000 but possibly a harmonised spec such as Swedish Implementation Standard (SSF) 14230. Either way, it's the same thing in different clothes.

  • jcsalomon (unregistered) in reply to boog
    boog:
    It looks like more work from this guy. But today's code appears to be a step up from the other method. That is, at least he's not using a case statement
    Behold:
    Interestingly, this is pretty much how you write Python modules in C (that is, bindings to C code for Python). Except I think the array is even larger there.
    In C99, this would look entirely reasonable:
    static void (*const SID[MAX_NUM_SERVICE_IDENTIFIERS])
                ( const u8 *data, const u16 bytes ) =
    {
        [SERV_DIAG /* or whatever identifier they’re using */] = &start_diagnostic_session,
        […] = &read_ecu_identification,
        […] = &rd_data_by_common_identifier,
        […] = &security_access,
        […] = &wr_data_by_common_identifier,
    };
    TRWTF is how long it’s taken for compiler to implement this.
  • (cs) in reply to TheCPUWizard
    TheCPUWizard:
    hoodaticus:
    Or I could be wrong, and they used a random number generator to decide where to put their base class members in the vtable.

    Based on the code, I see no evidence that it is a vtable (i.e. a methodology for dispatching calls for an overridable method in a class). In fact, there is no evidence of any object oriented elements. It is a simple function dispatch table.

    Looking back at the comments, it is quite likely that "vtable' was brought of more as an analogy than as a proper usage of the term.

    Okay, now it makes way more sense and doesn't seem like a WTF to me. Those nulls are either truly empty or invalid in the pre-computed context that this array serves. Gotcha.

  • (cs) in reply to Nagesh
    Nagesh:
    Lingerance:
    Nagesh:
    Nagesh:
    ¢ÃƒÆââ‚Â:
    Nagesh is TRWTF.

    And you call us racist for saying outsourced code from India sucks?

    You are TWRTF and you are racist. Our code is much better than any USA code you can name, I dare you to prove different. Our last client paid lots of money for our code and they were so happy they got a faster server to run our code. I also wrote 6 thousand lines of code yesterday. I would have coded more but my keyboard is not working well, the keys do not always work so I ut and paste with the mouse.

    Why you force client to buy new server? OUr client still running our super fast quick code on 486 and Pentium machine. He never complain. Truly good code is one that runs on less resources.

    I'm still not sure why we let Indians write code anyway. Is it some sort of reparations? Isn't giving casinos to you enough?

    What casinos? Gambling is illegal in India.

    True story from Mahabharat. Look up Yudishthira, Draupadi, Gambling, Dice, Shakuni, Pandav.
    His use of "Indian" was a play on words. He meant MY kind of Indian, not your kind of Indian. Your kind of Indian is what Christopher Columbus was looking for when he discovered America for the Europeans. MY kind of Indian is what the Europeans actually found when they got here.

    You're East Indian. I'm West Indian (part Cherokee). Both are swarthy heathens, but your kind didn't chop the scalps off of the invading British horde for trophies. You also probably didn't eat entire British colonies, which is my educated guess as to what happened to Jamestown.

    I bet they were delicious.

  • derp (unregistered) in reply to Mike
    Mike:
    smxlong:
    Dude, you just added like, 20 to 30 bytes to the size of the .text section with those stupid assignment instructions. And you caused the vtable to now have to exist in writable memory, which is at a premium on most embedded systems, instead of living on a cheap ROM. You fail.

    Ever read that paper, "Incompetent and Unaware of it?"

    Do you know the RAM budget on this project? If it's megabytes, you're prematurely optimizing. If it's kilobytes, you are right: it makes sense to sacrifice some readability. Where I work, the highest cost is paying developers - hardware is dirt cheap in comparison. In this environment, maintainable code is more valuable by many orders of magnitude than 290 bytes of RAM.

    This code is obviously going into a million+ units of embedded car ECUs, so they can't just shit out fifteen minutes worth of Python code and tell the customer to spend more on hardware.

    This just in: sometimes optimization is actually necessary!

    Besides, it's just a sparse array of function pointers forming a dispatch table. I'd consider some common C++ "idioms" far less maintainable.

  • (cs) in reply to hoodaticus
    hoodaticus:
    Nagesh:
    Lingerance:
    Nagesh:
    Nagesh:
    ¢ÃƒÆââ‚Â:
    Nagesh is TRWTF.

    And you call us racist for saying outsourced code from India sucks?

    You are TWRTF and you are racist. Our code is much better than any USA code you can name, I dare you to prove different. Our last client paid lots of money for our code and they were so happy they got a faster server to run our code. I also wrote 6 thousand lines of code yesterday. I would have coded more but my keyboard is not working well, the keys do not always work so I ut and paste with the mouse.

    Why you force client to buy new server? OUr client still running our super fast quick code on 486 and Pentium machine. He never complain. Truly good code is one that runs on less resources.

    I'm still not sure why we let Indians write code anyway. Is it some sort of reparations? Isn't giving casinos to you enough?

    What casinos? Gambling is illegal in India.

    True story from Mahabharat. Look up Yudishthira, Draupadi, Gambling, Dice, Shakuni, Pandav.
    His use of "Indian" was a play on words. He meant MY kind of Indian, not your kind of Indian. Your kind of Indian is what Christopher Columbus was looking for when he discovered America for the Europeans. MY kind of Indian is what the Europeans actually found when they got here.

    You're East Indian. I'm West Indian (part Cherokee). Both are swarthy heathens, but your kind didn't chop the scalps off of the invading British horde for trophies. You also probably didn't eat entire British colonies, which is my educated guess as to what happened to Jamestown.

    I bet they were delicious.

    In that he should have just used the term "Red Indian". That's we Indians usually understand very quickly. Thanks for the clarification, though.

    Columbus sailed the ocean blue, (forget the rest)

  • (cs) in reply to Nagesh
    Nagesh:
    hoodaticus:
    His use of "Indian" was a play on words.
    In that he should have just used the term "Red Indian". That's we Indians usually understand very quickly.
    Then it wouldn't have been a play on words. </duh>

Leave a comment on “The Interface”

Log In or post as a guest

Replying to comment #:

« Return to Article