Skip to content
  • Steinar H. Gunderson's avatar
    9b9956eb
    Bug #29453827: REPLACE HOME-GROWN INTEGER TYPEDEFS WITH STANDARD ONES · 9b9956eb
    Steinar H. Gunderson authored
    Remove the home-grown my_ulonglong type. It was meant to always be 64-bit
    and was confusingly distinct from the ulonglong type, so just replace it
    with uint64_t.
    
    Note that since it is used in mysql.h for some return functions, a fair
    amount of client software declares variables of type my_ulonglong.
    Thus, we keep a legacy typedef, so that this software will not break
    on compilation. (There is no ABI change, as we just replace one 64-bit type
    with another.)
    
    There is one more snag; since uint64_t is frequently defined to be of type
    unsigned long, which is taken to be distinct from unsigned long long
    (the old definition), certain software that takes these types and fed them
    to printf directly will need adjustment to format strings, or get a new
    compiler warnings. A quick sample over open-source software (see e.g.
    https://codesearch.debian.net/search?q=printf.*mysql.*rows) indicates that
    this pattern isn't all that common to begin with, and that most code that
    does it uses %d, which already gave a warning in the old code. Note that
    the warning is harmless and easily fixed by using PRIu64 (from C99) instead
    of llu, or a cast back to long long int (like a lot of software from the given
    sample already does).
    
    Change-Id: If49eaf6cfaf3dda874f2a465068b481216b243c6
    9b9956eb
    Bug #29453827: REPLACE HOME-GROWN INTEGER TYPEDEFS WITH STANDARD ONES
    Steinar H. Gunderson authored
    Remove the home-grown my_ulonglong type. It was meant to always be 64-bit
    and was confusingly distinct from the ulonglong type, so just replace it
    with uint64_t.
    
    Note that since it is used in mysql.h for some return functions, a fair
    amount of client software declares variables of type my_ulonglong.
    Thus, we keep a legacy typedef, so that this software will not break
    on compilation. (There is no ABI change, as we just replace one 64-bit type
    with another.)
    
    There is one more snag; since uint64_t is frequently defined to be of type
    unsigned long, which is taken to be distinct from unsigned long long
    (the old definition), certain software that takes these types and fed them
    to printf directly will need adjustment to format strings, or get a new
    compiler warnings. A quick sample over open-source software (see e.g.
    https://codesearch.debian.net/search?q=printf.*mysql.*rows) indicates that
    this pattern isn't all that common to begin with, and that most code that
    does it uses %d, which already gave a warning in the old code. Note that
    the warning is harmless and easily fixed by using PRIu64 (from C99) instead
    of llu, or a cast back to long long int (like a lot of software from the given
    sample already does).
    
    Change-Id: If49eaf6cfaf3dda874f2a465068b481216b243c6
Loading