Buffer huh?



  •  It has been a while since I saw the code so I may not have it perfectly right.

    I found this a long time ago in some embedded code.  The system had the stuff from string.h, but not stdio.h  The provided print function needed a pointer to the string and its length.

    The original variable names were much worse, but this was one of the better coded part of the program.  I'm a hardware guy and I write better code then this.

    char Buffer[200];

    strcpy(&Buffer[1], "This is a really long string I want to print\n\r");
    print_string(&Buffer[1], strlen("This is a really long string I want to print\n\r"));

     Why the coder didn't want to user Buffer[0] I will never know.
     


     



  • BASIC brain damage possibly (which can be overcome with time, but not without making an effort) or a really shitty embedded toolchain (which generally isn't as easy to overcome).



  • "Shoot, why does strlen keep saying that this char buffer is 0 length sometimes, and the right length other times? Damnit! Ok, fine, I'll just dupe the string and do strlen on that! Ha! Take that, crappy compiler!"



  • A good compiler would turn strlen() of a constant string into a constant value.  If you read Buffer[0] then it may be forced to do a memory read.  Depending on how much OoO processing the CPU has, references to the Buffer[0] from two different pointers (one in the calling function & one in the strcpy routine) might cause a flush.



  • @sibtrag said:

    A good compiler would turn strlen() of a constant string into a constant value.  If you read Buffer[0] then it may be forced to do a memory read.  Depending on how much OoO processing the CPU has, references to the Buffer[0] from two different pointers (one in the calling function & one in the strcpy routine) might cause a flush.

     

    I'm not sure I quite understand you, are you saying that by not writing to the very beginning of the buffer he can make the system hold it in the data cache without doing a write flush and stalling? This seems a little bit of an extreme type of optimization, or am I missing something here?



  • @Devi said:

    @sibtrag said:

    A good compiler would turn strlen() of a constant string into a constant value.  If you read Buffer[0] then it may be forced to do a memory read.  Depending on how much OoO processing the CPU has, references to the Buffer[0] from two different pointers (one in the calling function & one in the strcpy routine) might cause a flush.

     

    I'm not sure I quite understand you, are you saying that by not writing to the very beginning of the buffer he can make the system hold it in the data cache without doing a write flush and stalling? This seems a little bit of an extreme type of optimization, or am I missing something here?

    The parent was poorly trying to explain why the WTF is doing an strlen() on the const string instead of the array (though the merit of his explanation is dubious at best).  The whole buffer[1] issue is not part of it, that's another WTF.  Regardless, I think it's safe to assume that the WTF author was not nearly clever enough to have done this as an optimization.



  • And this, of course, is the correct solution.

    const char* string_to_print = "This is a really long string I want to print\n\r";
    print_string(string_to_print, strlen(string_to_print));

    Assuming that print_string accepts a const string.



  • @Thief^ said:

    And this, of course, is the correct solution.

    const char* string_to_print = "This is a really long string I want to print\n\r";
    print_string(string_to_print, strlen(string_to_print));

    Assuming that print_string accepts a const string.

    That's what I was thinking too. The only thing I can think of is that for some bizarre reason the print_string function modifies the string as it processes it (presumably shifting each character back one space in the array).
     


Log in to reply