[vim/vim] Fix get_winbuf_options on big-endian systems (#1060)
James McCoy
The value for an option in struct vimoption is defined as char_u. However, long and int values are stored in memory for P_NUM and
*var;
P_BOOL values, respectively.
When get_winbuf_options attempts to retrive the value of a P_NUM option,
it simply dereferences the char_u* and passes that value through the
varnumber_T parameter of dict_add_nr_str. Now that varnumber_T is a
64-bit value, this plain dereference of the char_u pointer passes along
the high (zero) byte of the option's value.
Casting the char_u* to a long* first and then dereferencing that, as is
already done by get_option_value, passes along the value of the entire
long instead of just one byte of it.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/1060
Commit Summary
- Fix get_winbuf_options on big-endian systems
File Changes
- M src/option.c (2)
Patch Links:
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
James McCoy
I'll verify this later today for both P_NUM and P_BOOL options, once I get back to where I have access to big-endian systems for testing. I just wanted to get the PR up for review/comment, since I had already done some investigation when I saw Ismail's email to the list.
Bram Moolenaar
James McCoy wrote:
> The value for an option in struct vimoption is defined as `char_u
> *var;`. However, long and int values are stored in memory for P_NUM and
> P_BOOL values, respectively.
>
> When get_winbuf_options attempts to retrive the value of a P_NUM option,
> it simply dereferences the char_u* and passes that value through the
> varnumber_T parameter of dict_add_nr_str. Now that varnumber_T is a
> 64-bit value, this plain dereference of the char_u pointer passes along
> the high (zero) byte of the option's value.
>
> Casting the char_u* to a long* first and then dereferencing that, as is
> already done by get_option_value, passes along the value of the entire
> long instead of just one byte of it.
an int, not long. That matters if int and long differ in size.
Also, this should have a test. Hmm, on a little endian system I think
'foldlevel' is the only option that can have a value that doesn't fit in
a byte.
--
hundred-and-one symptoms of being an internet addict:
254. You wake up daily with your keyboard printed on your forehead.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///