update to 4.9

Signed-off-by: yixiangzhike <yixiangzhike007@163.com>

backport-sed-c-flag.patch

@@ -19,26 +19,26 @@ index c5f07cc..4e5f5b3 100644
        if (strcmp (in_place_extension, "*") != 0)
          {
            char *backup_file_name = get_backup_file_name (target_name);
--          ck_rename (target_name, backup_file_name, input->out_file_name);
+-          ck_rename (target_name, backup_file_name);
 +          if (copy_instead_of_rename)
 +          {
 +            ck_fccopy (target_name, backup_file_name, input->out_file_name);
 +          }
 +          else
 +          {
-+            ck_rename (target_name, backup_file_name, input->out_file_name);
++            ck_rename (target_name, backup_file_name);
 +          }
            free (backup_file_name);
          }
  
--      ck_rename (input->out_file_name, target_name, input->out_file_name);
+-      ck_rename (input->out_file_name, target_name);
 +      if (copy_instead_of_rename)
 +      {
 +        ck_fcmove (input->out_file_name, target_name, input->out_file_name);
 +      }
 +      else
 +      {
-+        ck_rename (input->out_file_name, target_name, input->out_file_name);
++        ck_rename (input->out_file_name, target_name);
 +      }
        cancel_cleanup ();
        free (input->out_file_name);
@@ -135,7 +135,7 @@ index 9576dd1..371d5a9 100644
 +#include <fcntl.h>
  
  #include "binary-io.h"
- #include "unlocked-io.h"
+ #include "eloop-threshold.h"
 @@ -400,7 +401,92 @@ ck_rename (const char *from, const char *to, const char *unlink_if_fail)
    panic (_("cannot rename %s: %s"), from, strerror (errno));
  }
@@ -236,7 +236,7 @@ index 47a029e..0aba107 100644
 @@ -40,6 +40,8 @@ size_t ck_getdelim (char **text, size_t *buflen, char buffer_delimiter,
  FILE * ck_mkstemp (char **p_filename, const char *tmpdir, const char *base,
                     const char *mode) _GL_ARG_NONNULL ((1, 2, 3, 4));
- void ck_rename (const char *from, const char *to, const char *unlink_if_fail);
+ void ck_rename (const char *from, const char *to);
 +void ck_fccopy (const char *from, const char *to, const char *unlink_if_fail);
 +void ck_fcmove (const char *from, const char *to, const char *unlink_if_fail);
  

backport-sed-handle-very-long-execution-lines-tiny-change.patch

@@ -1,56 +0,0 @@
-From 61b5e58f18f152636a77c872dc39281bfb8bf90d Mon Sep 17 00:00:00 2001
-From: Tobias Stoeckmann <tobias@stoeckmann.org>
-Date: Fri, 17 Jan 2020 20:49:33 +0100
-Subject: [PATCH] sed: handle very long execution lines (tiny change)
-
-If sed is called with an excessively long execution line, then it is
-prone to an out of bounds memory access.
-
-The problem is that the length of the execution line, which is a
-size_t, is temporarily stored in an int. This means that on systems
-which have a 64 bit size_t and a 32 bit int (e.g. linux amd64) an
-execution line which exceeds 2 GB will overflow int. If it is just
-slightly larger than 2 GB, the negative int value is used as an
-array index to finish the execution line string with '\0' which
-therefore triggers the out of bounds access.
-
-This problem is probably never triggered in reality, but can be
-provoked like this (given that 'e' support is compiled in):
-
-$ dd if=/dev/zero bs=1M count=2049 | tr '\0' e > e-command.txt
-$ sed -f e-command.txt /etc/fstab
-Segmentation fault (core dumped)
-
-Also adjust another int/size_t conversion, even though it is a
-purely cosmetic change, because it can never be larger than 4096.
-
-* sed/execute.c (execute_program) [case 'e']: Declare cmd_length
-to be of type size_t, not int.  Likewise for "n" just below.
-* NEWS (Bug fixes): Mention it.
-This addresses https://bugs.gnu.org/39165
----
- sed/execute.c | 4 ++--
- 1 files changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/sed/execute.c b/sed/execute.c
-index c5f07cc..8f43f2e 100644
---- a/sed/execute.c
-+++ b/sed/execute.c
-@@ -1347,7 +1347,7 @@ execute_program (struct vector *vec, struct input *input)
-               panic (_("`e' command not supported"));
- #else
-               FILE *pipe_fp;
--              int cmd_length = cur_cmd->x.cmd_txt.text_length;
-+              size_t cmd_length = cur_cmd->x.cmd_txt.text_length;
-               line_reset (&s_accum, NULL);
- 
-               if (!cmd_length)
-@@ -1367,7 +1367,7 @@ execute_program (struct vector *vec, struct input *input)
- 
-               {
-                 char buf[4096];
--                int n;
-+                size_t n;
-                 while (!feof (pipe_fp))
-                   if ((n = fread (buf, sizeof (char), 4096, pipe_fp)) > 0)
-                     {

backport-sed-handle-very-long-input-lines-with-R-tiny-change.patch

@@ -1,55 +0,0 @@
-From acabfdb582330345c05e0500d302e9e99f3eb5e9 Mon Sep 17 00:00:00 2001
-From: Tobias Stoeckmann <tobias@stoeckmann.org>
-Date: Fri, 17 Jan 2020 21:28:28 +0100
-Subject: [PATCH] sed: handle very long input lines with R (tiny change)
-
-It is possible to trigger an out of bounds memory access when
-using the sed command R with an input file containing very long
-lines.
-
-The problem is that the line length of parsed file is returned as
-a size_t by ck_getdelim, but temporarily stored in an int and
-then converted back into a size_t. On systems like amd64, on which
-this problem can be triggered, size_t and int have different sizes.
-
-If the input line is longer than 2 GB (which is parseable on amd64
-or other 64 bit systems), this means that the temporarily stored
-int turns negative. Converting the negative int back into a size_t
-will lead to an excessively large size_t, as the conversion leads to
-a lot of leading 1 bits.
-
-Eventually ck_fwrite is called with this huge size_t which in turn
-will lead to an out of bounds access on amd64 systems -- after all
-the parsed text was just a bit above 2 GB, not near SIZE_MAX.
-
-You can trigger this issue with GNU sed on OpenBSD like this:
-
-$ dd if=/dev/zero bs=1M count=2049 | tr '\0' e > long.txt
-$ sed Rlong.txt /etc/fstab
-Segmentation fault (core dumped)
-
-I was unable to trigger the bug on a Linux system with glibc due to
-a bug in glibc's fwrite implementation -- it leads to a short write
-and sed treats that correctly as an error.
-
-* sed/execute.c (execute_program) [case 'R']: Declare result
-to be of type size_t, not int.
-* NEWS (Bug fixes): Mention it.
-This addresses https://bugs.gnu.org/39166
----
- sed/execute.c | 2 +-
- 1 files changed, 1 insertions(+), 1 deletion(-)
-
-diff --git a/sed/execute.c b/sed/execute.c
-index 8f43f2e..f94b125 100644
---- a/sed/execute.c
-+++ b/sed/execute.c
-@@ -1518,7 +1518,7 @@ execute_program (struct vector *vec, struct input *input)
-                   struct append_queue *aq;
-                   size_t buflen;
-                   char *text = NULL;
--                  int result;
-+                  size_t result;
- 
-                   result = ck_getdelim (&text, &buflen, buffer_delimiter,
-                                         cur_cmd->x.inf->fp);

sed.spec

@@ -1,6 +1,6 @@
 Name:	 sed
-Version: 4.8
+Version: 4.9
-Release: 2
+Release: 1
 Summary: non-interactive command-line text editor
 
 License: GPLv3+
@@ -8,8 +8,6 @@ URL:	 https://www.gnu.org/software/sed/
 Source0: http://ftp.gnu.org/gnu/sed/%{name}-%{version}.tar.xz
 
 Patch1:  backport-sed-c-flag.patch
-Patch2:  backport-sed-handle-very-long-execution-lines-tiny-change.patch
-Patch3:  backport-sed-handle-very-long-input-lines-with-R-tiny-change.patch
 
 BuildRequires: gzip automake autoconf gcc
 BuildRequires: glibc-devel libselinux-devel libacl-devel perl-Getopt-Long
@@ -51,6 +49,12 @@ make %{?_smp_mflags}
 %{_mandir}/man1/*.1.gz
 
 %changelog
+* Sat Jan 28 2023 yixiangzhike<yixiangzhike007@163.com> - 4.9-1
+- Type:enhancement
+- ID:NA
+- SUG:NA
+- DESC:upgrade software to v4.9
+
 * Mon Feb 8 2021 yangzhuangzhuang<yangzhuangzhuang1@huawei.com> - 4.8-2
 - Type:bugfix
 - ID:NA