[hackers] [scc] [cc1] Remove undefined behaviour in specifier || Roberto E. Vargas Caballero

From: <git_AT_suckless.org>
Date: Fri, 27 May 2016 17:09:49 +0200 (CEST)

commit 541fffb698465fbdb961b0212fdfe22f484bacf9
Author: Roberto E. Vargas Caballero <k0ga_AT_shike2.com>
AuthorDate: Fri May 27 17:08:32 2016 +0200
Commit: Roberto E. Vargas Caballero <k0ga_AT_shike2.com>
CommitDate: Fri May 27 17:08:32 2016 +0200

    [cc1] Remove undefined behaviour in specifier
    
    Variables local to loops are created and destroy in every iteration
    of the loop, and it means that they (logically) does not retain
    the value from the previous iteration. In the case of long long
    we were using the value of the previous iteration (the iteration
    of the first long), and it was working because moderm compilers
    does not create/destroy the variables in this case. It was possible
    to create strange results with something like:
    
            long int long
    
    because in this case p was pointing to type and not to the size.
    This patch fixes the problem setting the value of p to NULL in
    every iteration and explicitily setting the value of p in the case
    of long long. If the value of p is not set to the correct value
    we will have a segmentation fault and e will discover the error
    as soon as possible.

diff --git a/cc1/decl.c b/cc1/decl.c
index c77238e..0bffb41 100644
--- a/cc1/decl.c
+++ b/cc1/decl.c
_AT_@ -371,7 +371,7 @@ specifier(int *sclass, int *qualifier)
         spec = qlf = sign = type = cls = size = 0;
 
         for (;;) {
- unsigned *p;
+ unsigned *p = NULL;
                 Type *(*dcl)(void) = NULL;
 
                 switch (yytoken) {
_AT_@ -415,7 +415,6 @@ specifier(int *sclass, int *qualifier)
                                 if (size == LONG) {
                                         yylval.token = LLONG;
                                         size = 0;
- break;
                                 }
                         case SHORT:
                                 p = &size;
Received on Fri May 27 2016 - 17:09:49 CEST