patch 9.1.0162: problem with writing extended attributes on failure Commit: https://github.com/vim/vim/commit/14759ded57447345ba11c11a99fd84344797862c Author: Paul R. Tagliamonte <paultag@gmail.com> Date: Sun Mar 10 08:35:10 2024 +0100 patch 9.1.0162: problem with writing extended attributes on failure Problem: problem with writing extended attributes on failure Solution: Change return type to ssize_t and check listxattr's return value correctly on failure (Paul Tagliamonte) The existing logic will return when the listxattr call returns with the errno set to ENOTSUP (or a size of 0 bytes), without checking to see if listxattr actually failed. listxattr can fail with at least E2BIG, ENOTSUP, ERANGE, or anything that `stat(2)` can fail with (in my case; ENOENT from stat). The returned size is stored to a size_t, but the return type is a ssize_t. On failure, listxattr returns -1, which will get translated to size_t's MAX. If the listxattr call failed with anything other than ENOTSUP, this triggers a request for size_t MAX bytes. This means that, if the listxattr call fails with anything other than ENOTSUP on save, vim will error with `E342: Out of memory! (allocating 18446744073709551615 bytes)` (keen observers will note 18446744073709551615 is 0xffffffffffffffff) In reality, this is likely masking a different (usually filesystem?) error -- but at least it's an error being pushed to the user now, and we don't try to allocate size_t MAX bytes. I've opted to change the type that we store listxattr to from size_t to ssize_t, to match listxattr(2)'s signature, and to check for the -1 return value. Additionally, I've removed the errno check -- if we get a listxattr failure for any reason, we may as well bail without trying; it's not like we can even recover. closes: #14169 Signed-off-by: Paul Tagliamonte <paultag@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>

version: "{build}"

image: Visual Studio 2015

skip_tags: true

environment:
  matrix:
    - FEATURE: HUGE
  
    # Alternate environments, not used right now.  2022 is a lot slower.
    #
    # - job_name: VS-2015
    #   appveyor_build_worker_image: Visual Studio 2015
    #   FEATURE: HUGE

    # - job_name: VS-2017
    #   appveyor_build_worker_image: Visual Studio 2017
    #   FEATURE: HUGE

    # - job_name: VS-2019
    #   appveyor_build_worker_image: Visual Studio 2019
    #   FEATURE: HUGE

    # - job_name: VS-2022
    #   appveyor_build_worker_image: Visual Studio 2022
    #   FEATURE: HUGE

# disabled
#    - FEATURE: TINY
#    - FEATURE: NORMAL

matrix:
  fast_finish: true

before_build:
  - call ver
  - ci\appveyor.bat install

build_script:
  - ci\appveyor.bat build

test_script:
  - ci\appveyor.bat test

artifacts:
  - path: src/vim.exe
    name: vim
  - path: src/gvim.exe
    name: gvim

# vim: sw=2 sts=2 et ts=8 sr