Hi!
On Sep 06, Alexey Kopytov wrote:
> On Thursday 06 September 2007, Sergei Golubchik wrote:
> >On Jul 17, Alexey Kopytov wrote:
> >> ChangeSet@stripped, 2007-07-17 20:13:28+04:00, kaa@stripped +2 -0
> >> This patch is a part of work on bug #5731 "key_buffer_size not properly
> >> restricted to 4GB".
> >>
> >> The patch limits read_buffer_size and read_rnd_buffer_size by 2 GB on
> >> all platforms for the following reasons:
> >>
> >> --- 1.619/sql/mysqld.cc 2007-02-14 16:51:46 +03:00
> >> +++ 1.620/sql/mysqld.cc 2007-07-17 20:13:24 +04:00
> >> @@ -6195,7 +6195,7 @@ The minimum value for this variable is 4
> >> (gptr*) &global_system_variables.read_buff_size,
> >> (gptr*) &max_system_variables.read_buff_size,0, GET_ULONG,
> >> REQUIRED_ARG, - 128*1024L, IO_SIZE*2+MALLOC_OVERHEAD, SSIZE_MAX,
> >> MALLOC_OVERHEAD, IO_SIZE, + 128*1024L, IO_SIZE*2+MALLOC_OVERHEAD,
> >> INT_MAX, MALLOC_OVERHEAD, IO_SIZE,
> >
> >Wouldn't INT32_MAX be safer ?
>
> Hm, practically either way is equally safe, unless there is a
> supported by us platform where sizeof(int) != sizeof(int32). I am
> not aware of any such platform.
>
> Theoretically, the right constant depends on what data type is used in the
> code. If the code uses int32 which we hardcode to be 32-bit, then INT_MAX32
> would be the right choice. If the code uses the platform 'int' type, then
> using platform-provided constant INT_MAX looks more 'logical' to me. The code
> in mf_iocache.c and my_{read,write}.c uses the 'native' int/uint types, not
> the hardcoded ones, hence INT_MAX. The Windows POSIX API also defines
> read()/write() to return int. What do you think?
But you wrote in the changeset comment "limits ... by 2 GB on all
platforms". Using INT_MAX32 you force 2GB limit even when sizeof(int) >
4. As the intention is to limit by 2GB, not by max int, I think it's
better to specify the value explicitly.
Regards / Mit vielen Grüssen,
Sergei
--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@stripped>
/ /|_/ / // /\ \/ /_/ / /__ Principal Software Developer
/_/ /_/\_, /___/\___\_\___/ MySQL GmbH, Dachauer Str. 37, D-80335 München
<___/ Geschäftsführer: Kaj Arnö - HRB
München 162140
