1. 24 Jun, 2010 1 commit
  2. 22 Jun, 2010 1 commit
    • Alexey Kopytov's avatar
      Bug#54477: Crash on IN / CASE with NULL arguments · 07e95b39
      Alexey Kopytov authored
      Incorrect handling of NULL arguments could lead to a crash on
      the IN or CASE operations when either NULL arguments were
      passed explicitly as arguments (IN) or implicitly generated by
      the WITH ROLLUP modifier (both IN and CASE).
      
      Item_func_case::find_item() assumed all necessary comparators
      to be instantiated in fix_length_and_dec(). However, in the
      presence of WITH ROLLUP modifier, arguments could be
      substituted with an Item_null leading to an "unexpected"
      STRING_RESULT comparator being invoked.
      
      In addition to the problem identical to the above,
      Item_func_in::val_int() could crash even with explicitly passed
      NULL arguments due to an optimization in fix_length_and_dec()
      leading to NULL arguments being ignored during comparators
      creation.
      07e95b39
  3. 21 Jun, 2010 3 commits
  4. 18 Jun, 2010 1 commit
  5. 17 Jun, 2010 3 commits
  6. 15 Jun, 2010 11 commits
  7. 14 Jun, 2010 4 commits
  8. 12 Jun, 2010 2 commits
  9. 11 Jun, 2010 12 commits
  10. 10 Jun, 2010 2 commits
    • Davi Arnaut's avatar
      Bug#42733: Type-punning warnings when compiling MySQL -- · 53b88296
      Davi Arnaut authored
                  strict aliasing violations.
      
      One somewhat major source of strict-aliasing violations and
      related warnings is the SQL_LIST structure. For example,
      consider its member function `link_in_list` which takes
      a pointer to pointer of type T (any type) as a pointer to
      pointer to unsigned char. Dereferencing this pointer, which
      is done to reset the next field, violates strict-aliasing
      rules and might cause problems for surrounding code that
      uses the next field of the object being added to the list.
      
      The solution is to use templates to parametrize the SQL_LIST
      structure in order to deference the pointers with compatible
      types. As a side bonus, it becomes possible to remove quite
      a few casts related to acessing data members of SQL_LIST.
      53b88296
    • Davi Arnaut's avatar
      Bug#42733: Type-punning warnings when compiling MySQL -- · bb036c93
      Davi Arnaut authored
                 strict aliasing violations.
      
      Essentially, the problem is that large parts of the server were
      developed in simpler times (last decades, pre C99 standard) when
      strict aliasing and compilers supporting such optimizations were
      rare to non-existent. Thus, when compiling the server with a modern
      compiler that uses strict aliasing rules to perform optimizations,
      there are several places in the code that might trigger undefined
      behavior.
      
      As evinced by some recent bugs, GCC does a somewhat good of job
      misoptimizing such code, but on the other hand also gives warnings
      about suspicious code. One problem is that the warnings aren't
      always accurate, yet we can't afford to just shut them off as we
      might miss real cases. False-positive cases are aggravated mostly
      by casts that are likely to trigger undefined behavior.
      
      The solution is to start a cleanup process focused on fixing and
      reducing the amount of strict-aliasing related warnings produced
      by GCC and others compilers. A good deal of noise reduction can
      be achieved by just removing useless casts that are product of
      historical cruft and are likely to trigger undefined behavior if
      dereferenced.
      bb036c93