• Christian (unregistered) in reply to navigator

    No shell script, vi only:

    vi merchant.cfg

    3049iN<ESC>AY<ESC>:wq

    and you're done.
     

  • Think Outside the Box (unregistered) in reply to drdamour

    Why not just have a bit field in the merchant table with 1 if they're "special" and null or zero if they're not?

  • Luke (unregistered)

    Despite the other two major WTFs in this code, the first thing I thought was "if the file exists but has no bytes, this function leaves lingering filehandles all over the place".

     

  • Dale (unregistered) in reply to themagni
    themagni:
    Not the implementation, but the fact that this code even exists. This information should, nay MUST, be in the database along with all of the other DATA. There's no reason in this universe that a special field should be put outside of the rest of the data.

    Even the most perfectly coded, logical method for determining the "special" nature of the merchant would be wrong - it's not the correct place to put this sort of information!

    His code's wrong, though.
     

    He could be working in an environment there is a DBA who owns and runs the database server and this legend has to write his app around it. He asks the DBA to add a field for this and the DBA refuses. So, legend comes up with this work-around.

    But if you're going to do a bad thing, at least do it well.

  • no name (unregistered) in reply to Baughn
    Anonymous:
    Anonymous:

     

    Let me fix that for you:

     

    int is_special_merchant(int merchnum) 
    {
    size_t fln;
    char filedat[10000];
    FILE *file;

    if ((file=fopen("spcmerch.cfg","r" )) == NULL ) return(1);
    fln = fread(&filedat, 1, 10000, file) - 1;
    fclose(file);

    if (fln < merchnum) return(1);
    if(filedat[merchnum] == 'Y') return(0);

    return(1);
    }

     

     

    Let me fix that for you...

    int is_special_merchant(int merchnum) {

      FILE *file=fopen("spcmerch.cfg", "rb");

      if (file == NULL) return -1;

     

    Let me fix that for you...

    int is_special_merchant(int merchnum) {
    FILE *file=fopen("spcmerch.cfg","rb");
    if (!file) return -1;
    if (fseek(file, SEEK_SET, merchnum)) {
    fclose(file);
    return -1;
    }
    int ch=fgetc(file);
    fclose(file);
    if (ch == 'Y') return 1;
    if (ch == 'N') return 0;
    return -1;
    }
     
    That code has the dissadvantage that errors (and the not found condition) will be grouped with true if you do the obvious: if (is_special_merchant(merchnum)) which is the oppisite grouping of the previous behavoir. 
  • Mike Montana (unregistered) in reply to Bremac

    Ha ha - the real "WTF" is that this code works reliably well, when when the MerchantID is '9999'. Except when it goes into production. Most C/C++ environments will auto zero out array's for DEBUG mode, and not do the same for RELEASE code. This is the evil that we deal with on a daily basis here at my job [MSVC6]

     So, I can see the endless finger-pointing on this one. "The app crashes randomly in production when we call your function"

    "Bah - look it works perfectly well. Let me demonstrate every possible merchant ID - nothing crashes. See? Now go away Java-kid and figure out what you did wrong"
     

  • Joe D (unregistered) in reply to Artem

    FYI: it will never read 10000 bytes unless the file is that big.

    So you don't see the WTF huh?....reserving tons of memeory on the stack for no reason,  open/read/close the same file over and over (several hundred thousand times), useless variables like ab=0, blindly indexing the array with the passed merchnum... I could go on.

    Let me guess, you are Scott, aren't you?

    - Joe D

  • clayne (unregistered) in reply to Bremac

    Guess you don't use fread() that much, eh?

    RETURN VALUE fread and fwrite return the number of items successfully read or written (i.e., not the number of characters). If an error occurs, or the end-of-file is reached, the return value is a short item count (or zero).

    Noob.

  • clayne (unregistered) in reply to clayne
    Anonymous:
    Guess you don't use fread() that much, eh?

    RETURN VALUE fread and fwrite return the number of items successfully read or written (i.e., not the number of characters). If an error occurs, or the end-of-file is reached, the return value is a short item count (or zero).

    Noob.

    Original guy also flip flopped his sz and nmemb fields. Looks like drunk code. I'd have to wonder if the input is really only 23 bytes or else it would fail all the time.

  • clayne (unregistered) in reply to Think Outside the Box

    Or better yet just make it a struct field that is init'd appropriately upon load. Small file changes, reload. It's obviously not a mission critical app - because that function isn't doing anything but creating dangling file handles.

  • Jonesy29847 (unregistered)

    Wow,

    When I grow up I'm gonna be a legend in my own mind too.

  • george (unregistered)
  • eagle275 (unregistered) in reply to Anonymous
    Anonymous:
    shadowman:
    Not to mention 23 bytes for a 4-digit merchant code?  So what happens when myMerchant = 2423?
    The nice-guy inside of me says we should give the guy the benefit of the doubt and presume the 23-byte file was his "test" file to make sure his function works as coded, and he just got lazy and forgot to put in the data for the other several thousand merchants.The evil-genius inside of me says he's decent fodder for my next crusade to take over the world. 

    not really ...

    as Alex wrote : only 2% of the merchants are "special" - I strongly believe that all special merchants are covered in the first 23 merchants - why then bother with writing thousands of "N"s .. 23 bytes are fully sufficient

    all other array-indices will not yield "Y" and as the arraybuffer is reserved for 10000 merchants, the code works flawless ....

    a brillant solution - and very economical ...

Leave a comment on “Legendary Configuration”

Log In or post as a guest

Replying to comment #92948:

« Return to Article