summaryrefslogtreecommitdiffstatshomepage
path: root/src/nvim/bufwrite.c
AgeCommit message (Collapse)AuthorFiles
2026-04-21fix(messages): "progress" kind for busy messages #39280luukvbaal1
Problem: The "Scanning:" completion, bufwrite, and indent (there may be more) messages which indicate progress can use the "progress" kind for their msg_show event. Indent message does not have a kind. Solution: Emit these messages with the "progress" kind. Set the message id to the replaced kind so that a UI knows to replace it (and to provide a migration path in case a UI was distinguishing these messages for whatever reason).
2026-04-14build: update clang v21, fix warningsdundargoc1
- `src/nvim/ex_cmds_defs.h`: use "U" instead of "u" per `readability-uppercase-literal-suffix`
2026-04-07fix: don't make path empty when truncating trailing slashes (#38844)zeertzjq1
Fixes the following Coverity warning: *** CID 549779: Integer handling issues (INTEGER_OVERFLOW) /src/nvim/undo.c: 717 in u_get_undo_file_name() 711 dir_name[dir_len] = NUL; 712 713 // Remove trailing pathseps from directory name 714 char *p = &dir_name[dir_len - 1]; 715 while (vim_ispathsep(*p)) { 716 *p-- = NUL; >>> CID 549779: Integer handling issues (INTEGER_OVERFLOW) >>> Expression "dir_len--", where "dir_len" is known to be equal to 0, underflows the type of "dir_len--", which is type "size_t". 717 dir_len--; 718 } 719 720 bool has_directory = os_isdir(dir_name); 721 if (!has_directory && *dirp == NUL && !reading) { 722 // Last directory in the list does not exist, create it.
2026-02-12fix(bufwrite.c): handle invalid byte sequences #37363Kevin Goodsell1
Problem: bw_rest was used as an extra buffer to save incomplete byte sequences between calls to buf_write_bytes. Besides being unnecessarily complicated, this introduced a number of issues: 1) The bytes stored in bw_rest could still be there at the end of writing the file, never having been written, thus losing some of the file content on write. 2) bw_rest was not cleared out after the "checking_conversion" phase, leaving them to affect the written file content during the writing phase, corrupting the file. 3) bw_rest could contain extra bytes that need to be written to the output buffer during a buf_write_convert call, potentially before any bytes are consumed. But some conversions are in-place, without a separate output buffer. Writing bytes from bw_rest to the "output" buffer actually overwrote bytes from the input buffer before they were read, corrupting the data to be written. 4) The extra bytes in bw_rest that need to be written to the conversion output buffer were not originally accounted for in the size calculation for the output buffer, causing a buffer overflow (previously fixed in Vim patch 9.1.2028). Solution: Rather than maintaining a separate buffer, the unconverted bytes at the end of the buffer can just be shifted to the beginning of the buffer, and the buffer size updated. This requires a bit of refactoring, and buf_write_convert and buf_write_convert_with_iconv need to report the number of bytes they consumed so that buf_write_bytes can handle the remaining bytes. Following conversion, bw_buf can be checked for any remaining bytes. Leftover bytes in this case result in a conversion error, which is better than silently dropping them. A short section of dead code was removed from buf_write_convert, for converting a non-UTF-8 buffer to UTF-8. Neovim buffers are always UTF-8. A few additional tests for iconv conversions have been added. Vim's iconv tests are disabled in Neovim because they use unsupported values for 'encoding'.
2026-01-09refactor(fileio.c): avoid downcasting in {read,write}_eintr() (#37323)zeertzjq1
2025-12-28vim-patch:9.1.2028: [security]: Buffer-overflow with incomplete multi-byte ↵zeertzjq1
chars (#37133) Problem: Buffer overflow in buf_write() when converting incomplete multi-byte characters (Kevin Goodsell) Solution: Make the buffer slightly larger closes: vim/vim#19007 https://github.com/vim/vim/commit/f99de42a9fbc2caaac2741a275b6c25421582cf4 Co-authored-by: Christian Brabandt <cb@256bit.org>
2025-12-28vim-patch:9.1.2024: 'fsync' option cannot be set per buffer (#37129)zeertzjq1
Problem: 'fsync' option cannot be set per buffer Solution: Make 'fsync' option global-local (glepnir) closes: vim/vim#19019 https://github.com/vim/vim/commit/4d5b30372663e8ea356b25fe94334558c6ae283f Co-authored-by: glepnir <glephunter@gmail.com>
2025-12-17refactor(editor): extract backup name generation logic #37001yilisharcs1
Problem: The logic for generating backup file names is duplicated in `buf_write_make_backup` and difficult to reuse. Solution: Extract name generation logic into `buf_get_backup_name`.
2025-10-05vim-patch:8.1.1957: more code can be moved to evalvars.cJan Edmund Lazo1
Problem: More code can be moved to evalvars.c. Solution: Move code to where it fits better. (Yegappan Lakshmanan, closes vim/vim#4883) https://github.com/vim/vim/commit/da6c03342117fb7f4a8110bd9e8627b612a05a64 Co-authored-by: Bram Moolenaar <Bram@vim.org>
2025-08-27vim-patch:9.1.1688: potential buffer overrun in bufwrite.c (#35497)zeertzjq1
Problem: potential buffer overrun in bufwrite.c Solution: Use a temporary variable (John Marriott) In my Windows 11 Pro 64-bit build MAXPATHL is 1024 and IOSIZE is 1025. In my Archlinux Linux 64-bit build MAXPATHL is 4096 and IOSIZE is 1025. In funuction buf_write(): There is a check (line 713) that makes sure the length of fname is less than MAXPATHL. There is a call to STRCPY() (line 1208) which copies the string at fname into IObuff (which has size IOSIZE). For Unix builds fname is set to sfname which may or may not be shorter. However, if sfname is NULL sfname is set to fname. Therefore, in builds where MAXPATHL > IOSIZE (eg in my linux build), it is theoretically possible for the STRCPY() call to exceed the bounds of IObuff. This PR addresses this by copying fname into a local variable that has the same maximum size as fname. In addition: Given that the filename is unconditionally overwritten in the for loop, only copy the directory portion of fname. Move variable i closer to where it is used. closes: vim/vim#18095 https://github.com/vim/vim/commit/a19b019b8745f1c91e42c2b9440bddebfa67a17a Co-authored-by: John Marriott <basilisk@internode.on.net>
2025-08-14refactor(build): remove INCLUDE_GENERATED_DECLARATIONS guardsbfredl1
These are not needed after #35129 but making uncrustify still play nice with them was a bit tricky. Unfortunately `uncrustify --update-config-with-doc` breaks strings with backslashes. This issue has been reported upstream, and in the meanwhile auto-update on every single run has been disabled.
2025-06-25fix(ui)!: decouple ext_messages from message grid #27963luukvbaal1
Problem: ext_messages is implemented to mimic the message grid implementation w.r.t. scrolling messages, clearing scrolled messages, hit-enter-prompts and replacing a previous message. Meanwhile, an ext_messages UI may not be implemented in a way where these events are wanted. Moreover, correctness of these events even assuming a "scrolled message" implementation depends on fragile "currently visible messages" global state, which already isn't correct after a previous message was supposed to have been overwritten (because that should not only happen when `msg_scroll == false`). Solution: - No longer attempt to keep track of the currently visible messages: remove the `msg_ext(_history)_visible` variables. UIs may remove messages pre-emptively (timer based), or never show messages that don't fit a certain area in the first place. - No longer emit the `msg(_history)_clear` events to clear "scrolled" messages. This opens up the `msg_clear` event to be emitted when messages should actually be cleared (e.g. when the screen is cleared). May also be useful to emit before the first message in an event loop cycle as a hint to the UI that it is a new batch of messages (vim._extui currently schedules an event to determine that). - Set `replace_last` explicitly at the few callsites that want this to be set to true to replace an incomplete status message. - Don't store a "keep" message to be re-emitted.
2025-01-02feat(ui)!: emit prompt "messages" as cmdline events #31525luukvbaal1
Problem: Prompts are emitted as messages events, where cmdline events are more appropriate. The user input is also emitted as message events in fast context, so cannot be displayed with vim.ui_attach(). Solution: Prompt for user input through cmdline prompts.
2024-12-23refactor: iwyu #31637Justin M. Keyes1
Result of `make iwyu` (after some "fixups").
2024-12-10fix(messages): no message kind for :write messages #31519Tomasz N1
- Problem: cannot replace the initial bufwrite message (from `filemess`) by the final one (`"test.lua" [New] 0L, 0B written`), when using `vim.ui_attach`. - Solution: add kind to both messages.
2024-11-23refactor(options): autogenerate valid values and flag enums for options (#31089)Famiu Haque1
Problem: Option metadata like list of valid values for an option and option flags are not listed in the `options.lua` file and are instead manually defined in C, which means option metadata is split between several places. Solution: Put metadata such as list of valid values for an option and option flags in `options.lua`, and autogenerate the corresponding C variables and enums. Supersedes #28659 Co-authored-by: glepnir <glephunter@gmail.com>
2024-11-13refactor(highlight): make enum of builtin highlights start with 1bfredl1
This makes it possible to use HLF_ values directly as highlight id:s and avoids +1 adjustments especially around messages.
2024-11-08refactor(message): propagate highlight id instead of attrsLuuk van Baal1
Problem: Highlight group id is not propagated to the end of the message call stack, where ext_messages are emitted. Solution: Refactor message functions to pass along highlight group id instead of attr id.
2024-07-30refactor: collapse statements in single assignmentsLewis Russell1
Problem: Variables are often assigned multiple places in common patterns. Solution: Replace these common patterns with different patterns that reduce the number of assignments. Use `MAX` and `MIN`: ```c if (x < y) { x = y; } // --> x = MAX(x, y); ``` ```c if (x > y) { x = y; } // --> x = MIN(x, y); ``` Use ternary: ```c int a; if (cond) { a = b; } els { a = c; } // --> int a = cond ? b : c; ```
2024-07-26vim-patch:9.1.0615: Unnecessary STRLEN() in make_percent_swname()zeertzjq1
Problem: Unnecessary STRLEN() in make_percent_swname() Solution: Pass the end of "dir" to make_percent_swname() (zeertzjq) closes: vim/vim#15340 https://github.com/vim/vim/commit/242667ae142d9862a7bace82c58cb11c79fdab7a
2024-07-26vim-patch:8.2.3543: swapname has double slash when 'directory' ends in itzeertzjq1
Problem: Swapname has double slash when 'directory' ends in double slash. (Shane Smith) Solution: Remove the superfluous slash. (closes vim/vim#8876) https://github.com/vim/vim/commit/8b0e62c93b6dad5ec5b2c7558d4f7b78c46216d2 Co-authored-by: Bram Moolenaar <Bram@vim.org>
2024-06-10vim-patch:9.1.0472: Inconsistencies between functions for option flags (#29262)zeertzjq1
Problem: Inconsistencies between functions for option flags. Solution: Consistently use "unsigned int" as return type and rename get_bkc_value() to get_bkc_flags() (zeertzjq). closes: vim/vim#14925 https://github.com/vim/vim/commit/aa925eeb97bd294d4a5253a3194949a37cbc8365
2024-06-01refactor: move shared messages to errors.h #26214Justin M. Keyes1
2024-03-25refactor(backup): remove duplicate os_copy_xattr() (#28020)zeertzjq1
The first os_copy_xattr() is inside #ifdef UNIX, while the second isn't, so the first one isn't actually needed.
2024-03-25fix(backup): E1509 when writing extended attr to symlink (#28014)Razvan-Adrian Ciochina1
Problem: E1509 when writing extended attributes to a symlink. Solution: Copy the file before copying extended attributes. On Fedora, the attribute being set is "security.selinux". For normal, non-symlink files this attribute doesn't show up and that's why calling os_copy_xattr() doesn't break in that case.
2024-01-11refactor(IWYU): fix headersdundargoc1
Remove `export` pramgas from defs headers as it causes IWYU to believe that the definitions from the defs headers comes from main header, which is not what we really want.
2023-12-30refactor: follow style guidedundargoc1
2023-12-21refactor: run IWYU on entire repodundargoc1
Reference: https://github.com/neovim/neovim/issues/6371.
2023-12-21refactor(IWYU): move decor provider types to decoration_defs.h (#26692)zeertzjq1
2023-12-19refactor: use `bool` to represent boolean valuesdundargoc1
2023-12-17refactor: move non-symbols to defs.h headersdundargoc1
2023-11-30build: don't define FUNC_ATTR_* as empty in headers (#26317)zeertzjq1
FUNC_ATTR_* should only be used in .c files with generated headers. Defining FUNC_ATTR_* as empty in headers causes misuses of them to be silently ignored. Instead don't define them by default, and only define them as empty after a .c file has included its generated header.
2023-11-29refactor: move some constants out of vim_defs.h (#26298)zeertzjq1
2023-11-29refactor(IWYU): create normal_defs.h (#26293)zeertzjq1
2023-11-28refactor: fix headers with IWYUdundargoc1
2023-11-27refactor: rename types.h to types_defs.hdundargoc1
2023-11-27build(IWYU): fix includes for undo_defs.hdundargoc1
2023-11-27build(IWYU): fix includes for func_attr.hdundargoc1
2023-11-27build(IWYU): replace most private mappings with pragmas (#26247)zeertzjq1
2023-11-12build: remove PVSdundargoc1
We already have an extensive suite of static analysis tools we use, which causes a fair bit of redundancy as we get duplicate warnings. PVS is also prone to give false warnings which creates a lot of work to identify and disable.
2023-10-23build(lint): remove unnecessary clint.py rulesdundargoc1
Uncrustify is the source of truth where possible. Remove any redundant checks from clint.py.
2023-10-09refactor: the long goodbyedundargoc1
long is 32 bits on windows, while it is 64 bits on other architectures. This makes the type suboptimal for a codebase meant to be cross-platform. Replace it with more appropriate integer types.
2023-10-03refactor: the long goodbyedundargoc1
long is 32 bits on windows, while it is 64 bits on other architectures. This makes the type suboptimal for a codebase meant to be cross-platform. Replace it with more appropriate integer types.
2023-09-30vim-patch:9.0.1962: No support for writing extended attributeszeertzjq1
Problem: No support for writing extended attributes Solution: Add extended attribute support for linux It's been a long standing issue, that if you write a file with extended attributes and backupcopy is set to no, the file will loose the extended attributes. So this patch adds support for retrieving the extended attributes and copying it to the new file. It currently only works on linux, mainly because I don't know the different APIs for other systems (BSD, MacOSX and Solaris). On linux, this should be supported since Kernel 2.4 or something, so this should be pretty safe to use now. Enable the extended attribute support with normal builds. I also added it explicitly to the :version output as well as make it able to check using `:echo has("xattr")`, to have users easily check that this is available. In contrast to the similar support for SELINUX and SMACK support (which also internally uses extended attributes), I have made this a FEAT_XATTR define, instead of the similar HAVE_XATTR. Add a test and change CI to include relevant packages so that CI can test that extended attributes are correctly written. closes: vim/vim#306 closes: vim/vim#13203 https://github.com/vim/vim/commit/e085dfda5d8dde064b0332464040959479696d1c Co-authored-by: Christian Brabandt <cb@256bit.org>
2023-09-30refactor: reorganize option header files (#25437)zeertzjq1
- Move vimoption_T to option.h - option_defs.h is for option-related types - option_vars.h corresponds to Vim's option.h - option_defs.h and option_vars.h don't include each other
2023-09-27refactor(messages): rename msg_trunc_attr and msg_multiline_attr without attrbfredl1
2023-09-27refactor(messages): fold msg_attr into msgbfredl1
problem: there are too many different functions in message.c solution: fold some of the functions into themselves
2023-09-27vim-patch:8.2.3517: TextChanged does not trigger after TextChangedI (#25384)zeertzjq1
Problem: TextChanged does not trigger after TextChangedI. Solution: Store the tick separately for TextChangedI. (Christian Brabandt, closes vim/vim#8968, closes vim/vim#8932) https://github.com/vim/vim/commit/db3b44640d69ab27270691a3cab8d83cc93a0861 Co-authored-by: Christian Brabandt <cb@256bit.org>
2023-09-25refactor(options)!: graduate some more shortmess flagsbfredl1
A lot of updated places in the docs were already incorrect since long since they did not reflect the default behaviour. "[dos format]" could've been argued being better for discoverability but that ship has already sailed as it is no longer displayed by default.
2023-09-10refactor(mch): last mch_ function/macro hits the dustbfredl1
Also remove some stray comments.