Also talk about the sadness caused by low-level bugs: can you see the following bug at a glance?

Some time ago Apple reported an iOS 7.0.6 bug that caused a man-in-the-middle attack, and the source of the bug was the following:

Static Osstatus Sslverifysignedserverkeyexchange (Sslcontext *ctx, bool Isrsa, Sslbuffer Signedparams,   
    uint8_t *signature, UInt16 signaturelen) {Osstatus err;   
    .. if (err = Sslhashsha1.update (&hashctx, &serverrandom))!= 0) Goto fail;   
        if (err = Sslhashsha1.update (&hashctx, &signedparams))!= 0) Goto fail;   
    Goto fail;   
    if (err = sslhashsha1.final (&hashctx, &hashout))!= 0) Goto fail; Err = Sslrawverify (CTX, Ctx->peerpubkey, Datatosign,/   
                       * PlainText/datatosignlen, * plaintext length * * signature,   
    Signaturelen); if (err) {Sslerrorlog ("ssldecodesignedserverkeyexchange:sslrawverify" "returned%d\n"), (   
        int) err); Goto fail;   
    } fail:sslfreebuffer (&signedhashes);   
    Sslfreebuffer (&HASHCTX); return err;

A person who believes in an eagle eye can see the problem: There are two goto fail in the second if statement; Because if statements do not have curly braces, only the first goto belongs to If, and the second goto is always executed (note: This is not Python is the C language, and indentation does not mean that the statement belongs to the same statement block). In other words, even if the previous if check failed (err = = 0), will also Goto fail, a detailed analysis of this low-level bug please see Daniel Chenhao wrote the article "by Apple's low-level bug thinking of programming", it is worth reading.

That said, but which programmer hasn't had a few low-level bugs in his life? These bugs are painful for us, but they also deepen the relationship with code.

For example, yesterday, as a very careful Cheng (@ Cheng sensitive sensitive) also was a low-level bug devastated even their own holiday has not been wronged.

Look at the following code, you say will output how many "Alexia" it?

#include <stdio.h>  
      
#define CSIZE 256  
typedef unsigned char symbol_t;  
      
int main () {for  
          
    (symbol_t c = 0; c < csize C + +) {  
        printf ("Alexian");  
    }  
      
    return 0;  
}

Hey, I think the output of 256 "Alexia", of course, the fact is not so.

Note that here symbol_t is the unsigned char type, that is, the symbol_t type of variable C takes a value range of 0-255, when more than 255 will overflow, will not become 256 but truncated the highest bit back to 0, that is, c=255 after C + + when it becomes 0, So c is always less than csize, this cycle will never end, after a long time the program crashed, the solution is to symbol_t the unsigned short type.

If the program is so simple, then even if a glance does not come out, a little F10 debugging will know the location of the bug. However, it is difficult to find this low-level bug in a large project, especially for a very long statement. Speaking of this bug, actually is not, is my own later added, originally I was so defined symbol_t: typedef unsigned symbol_t; Unsigned default is unsigned int, so there will be no problem, because my project is space-sensitive, have been trying to save space, and then think of c variable can only take 0-255, why use int so large range? A c does not matter, but my project has n * 256 c,n range can be very large, so think perhaps can save a bit of space, so it is self-righteous to change it to unsigned char type, debugging for several hours, really don't spit unpleasant.

Well, yesterday adjusted a day bug, did not have a good holiday, today to make up, buy a 3.7-yuan KTV and 3.7-yuan movie tickets, afternoon to spend with the best friends ~ ~ ~

Author: csdn Blog Lanxuezaipiao