Manually



  • Am working on a rather old software component that needs to be ported to another platform. Looking for issues, I stumbled upon this

        
        /*(void) memcpy( is_it_present + block_size, &false, sizeof(bool));*/
        /* memcpy does not work, so we set the value of the XXX to false, manually*/
        is_it_present[3]=FALSE;
    

    Too bad for me that most of the time memcpy does work...



  • I have a vague feeling that "&false" part might be the problem. I mean, really?



  • For those who don't know c, the issue here is that the author should have used memset instead of memcpy.



  • @Weps said:

    Am working on a rather old software component that needs to be ported to another platform. Looking for issues, I stumbled upon this

        
        /*(void) memcpy( is_it_present + block_size, &false, sizeof(bool));*/
        /* memcpy does not work, so we set the value of the XXX to false, manually*/
        is_it_present[3]=FALSE;
    

    Too bad for me that most of the time memcpy does work...

    I work with a way senior developer, friend of my boss, who is always saying things like "Perforce isn't working" or "Java is returning the wrong time value" or "MySQL has locked the table"; when he's especially egregious I put the headphones on and crank up music to keep from strangling him.

    In  the OP, the commented-out line of memcpy() that presumably is what "does not work" is scary.  "is_it_present + block_size" is the address just past block_size.  Not necessarily wrong, but it could be.

    But the craziness is &false. Most likely the preprocessor turns it into something like &(0) -- I'm surprised it compiled. 



  • @rstinejr said:

    I work with a way senior developer, friend of my boss, who is always saying things like "Perforce isn't working" or "Java is returning the wrong time value" or "MySQL has locked the table"; when he's especially egregious I put the headphones on and crank up music to keep from strangling him.

    When one is developing new software, or solutions, and one hits an issue, one has two choices:

    1. Blame your new untested code, or integration that you've just put together
    2. Blame the 10-year-old library code, or released software, which you're using and 1000s of other people are using successfully.
    It's amazing how often people choose 2.

     



  • @rstinejr said:



    I work with a way senior developer, friend of my boss, who is always saying things like "Perforce isn't working" or "Java is returning the wrong time value" or "MySQL has locked the table"; when he's especially egregious I put the headphones on and crank up music to keep from strangling him.


    I work with one that calls the IT service department to crank up/turn down the heating if all he has to do is stretch his arm and turn a knob....But ok, senior just means older and in my case...

    @rstinejr said:

    In  the OP, the commented-out line of memcpy() that presumably is what "does not work" is scary.  "is_it_present + block_size" is the address just past block_size.  Not necessarily wrong, but it could be.

    But the craziness is &false. Most likely the preprocessor turns it into something like &(0) -- I'm surprised it compiled. 



    is_it_present is a pointer to an array of booleans (...) block_size is the size of the header and is_it_present in the memcpy line presumably first pointed to the start of the header. Still, it would have set the first bool to false, not the last one.

    And of course &false and FALSE, but really, either the author had the intention to warn his followers not to use memcpy, or, he tried to use it (since everywhere else memcpy is used) and failed, just to come up with the obvious.This line already cost me more time with that comment than it would have without...





  • @Weps said:

    Am working on a rather old software component that needs to be ported to another platform. Looking for issues, I stumbled upon this

        
        /*(void) memcpy( is_it_present + block_size, &false, sizeof(bool));*/
        /* memcpy does not work, so we set the value of the XXX to false, manually*/
        is_it_present[3]=FALSE;
    

    Too bad for me that most of the time memcpy does work...

     

     

    I will name this variable "is_it_present" -- that way it will be clear for any maintenance work

     

     



  • It doesn't work if you do: #define false 0, but: int false = 0 compiles and runs:

    #include <stdio.h>
    int main(int argc, char **argv) {
      int false = 0;
      int *x = (int*) malloc(3*sizeof(int));
      x[2] = false;
      memset(&(x[1]),false, sizeof(false));
      memcpy(x, &false, sizeof(false));
      printf("x[0]=%d x[1]=%d x[2]=%d\n",*x,*(x+1), *(x+2));
      return 0;
    }

    -> x[0]=0 x[1]=0 x[2]=0



  • @snoofle said:

    int false = 0 compiles and runs

    It does in C of course because &false in that context means "the address of the (integer) variable 'false'" which can be dereferenced (by memcpy) to 0.

    However, in (forte) C++, where false is a reserved word:

    >CC -o false false.cc
    "false.cc", line 7: Error: The "&" operator can only be applied to a variable or other l-value.

     From:

    1 : #include <iostream>
    2 : int main(int argc, char **argv) {
    3 :    int x[3];
    4 :    memset(x, 0, sizeof(x));
    5 : 
    6 :   memset(x + 1, false, sizeof(false));
    7 :    memcpy(x, &false, sizeof(false));
    8 :    std::cout << "x[0]="
    9 :              << x[0]
    10:              << " x[1]="
    11:              << x[1]
    12:              << " x[2]="
    13:              << x[2];
    14:   
    15:    return 0;
    16:}


     



  • @pure said:

    @rstinejr said:

    I work with a way senior developer, friend of my boss, who is always saying things like "Perforce isn't working" or "Java is returning the wrong time value" or "MySQL has locked the table"; when he's especially egregious I put the headphones on and crank up music to keep from strangling him.

    When one is developing new software, or solutions, and one hits an issue, one has two choices:

    1. Blame your new untested code, or integration that you've just put together
    2. Blame the 10-year-old library code, or released software, which you're using and 1000s of other people are using successfully.
    It's amazing how often people choose 2.

     

    I agree. I used to be a DBA and frequently developers would say that there is a bug in Oracle because "transactions don't work properly" or "the wrong record gets updated". Most of the time the problem ended up being a slightly suboptimal homemade DAL class.

    It's like playing Scrabble with annoying people who disagree with the dictionary and ask what year he's been published.


  • Trolleybus Mechanic

    @Weps said:

    I work with one that calls the IT service department to crank up/turn down the heating if all he has to do is stretch his arm and turn a knob....
     

    ... and fill out an Office Change form, explain the difference in temp. to his supervisor, allocate credits from his department's Carbon Footprint allowance, and ultimately take responsibility for any and all ills, chills and emotional trauma that his co-workers experience from a shift in their familiar surroundings.

    OR he can call IT and make them responsible for all of it.



  • @pure said:

    When one is developing new software, or solutions, and one hits an issue, one has two choices:

    1. Blame your new untested code, or integration that you've just put together
    2. Blame the 10-year-old library code, or released software, which you're using and 1000s of other people are using successfully.
    It's amazing how often people choose 2.
    Sometimes 2 is right.  I was once present when a program that had performed faithfully corrupted the entire database.  The bug had sat, untriggered, for seven years, and was so deeply inherent in the design that I found it easier to rewrite the entire program (without a computer, on a yellow pad) than try to patch the flawed approach.  After one compile run to catch the keying errors it was ready to go into production and has worked without a hitch for over a decade.

     



  • @da Doctah said:

    Sometimes 2 is right. I was once present when a program that had performed faithfully corrupted the entire database. The bug had sat, untriggered, for seven years, and was so deeply inherent in the design that I found it easier to rewrite the entire program (without a computer, on a yellow pad) than try to patch the flawed approach. After one compile run to catch the keying errors it was ready to go into production and has worked without a hitch for over a decade.

    Now because of your one post you've given support to a million dumbshits all howling, "it's no my fault! the API is broken! Look at this da Doctah guy who had the same problem!"

    You've caused us all irreparable harm. Your post is bad and you should feel bad.



  • @blakeyrat said:

    @da Doctah said:
    Sometimes 2 is right. I was once present when a program that had performed faithfully corrupted the entire database. The bug had sat, untriggered, for seven years, and was so deeply inherent in the design that I found it easier to rewrite the entire program (without a computer, on a yellow pad) than try to patch the flawed approach. After one compile run to catch the keying errors it was ready to go into production and has worked without a hitch for over a decade.

    Now because of your one post you've given support to a million dumbshits all howling, "it's no my fault! the API is broken! Look at this da Doctah guy who had the same problem!"

    You've caused us all irreparable harm. Your post is bad and you should feel bad.

    I feel bad for the people who dont know the meaning of the word Sometimes.

     



  • @da Doctah said:

    @blakeyrat said:

    @da Doctah said:
    Sometimes 2 is right. I was once present when a program that had performed faithfully corrupted the entire database. The bug had sat, untriggered, for seven years, and was so deeply inherent in the design that I found it easier to rewrite the entire program (without a computer, on a yellow pad) than try to patch the flawed approach. After one compile run to catch the keying errors it was ready to go into production and has worked without a hitch for over a decade.

    Now because of your one post you've given support to a million dumbshits all howling, "it's no my fault! the API is broken! Look at this da Doctah guy who had the same problem!"

    You've caused us all irreparable harm. Your post is bad and you should feel bad.

    I feel bad for the people who dont know the meaning of the word Sometimes.

     

    Everybody think that they will never get a STD or that they don't need seat belts because accidents only happen to other people. For some reason with "buggy" APIs it's the opposite: many developers feel that unlike other people their situation falls under the "sometimes" umbrella. There is no cure for that except an internship in the helpdesk department where developers can experience first hand how annoying it is when people accuse Windows of deleting files by itself or blame hackers for injecting p0rn in internet browsing history.



  • @speakerphone dude - yes. It is staggering how often the computer forgets people's passwords over the weekend.


  • :belt_onion:

    @pure said:

    @speakerphone dude - yes. It is staggering how often the computer forgets people's passwords over the weekend.
    That happened to you too? Amazing coincidence


  • Trolleybus Mechanic

    @da Doctah said:

    I feel bad for the people who dont know the meaning of the word Sometimes.
     

    So do I, but only sometimes.


Log in to reply