check for valid optarg before using strdup v1 PROPOSED

Serge Ziryukin: 2
 check for valid optarg before using strdup
 remove dead assignment, spotted by clang

 2 files changed, 1 insertions(+), 1 deletions(-)

I'd prefer to keep this there.  That way, if any further fields get 
added below that one, we will not have to remember to put that line 
back.  That line should be optimized away by any good compiler anyway.

Allan

[pacman-dev] [PATCH 1/2] check for valid optarg before using strdup Export this patch

Signed-off-by: Serge Ziryukin <ftrvxmtrx@gmail.com>
---
 src/pacman/pacman.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c
index d32d4d1..206cdcf 100644
--- a/src/pacman/pacman.c
+++ b/src/pacman/pacman.c
@@ -489,6 +489,7 @@ static int parseargs(int argc, char *argv[])
 				setarch(optarg);
 				break;
 			case OP_PRINTFORMAT:
+				check_optarg();
 				config->print_format = strdup(optarg);
 				break;
 			case 'Q': config->op = (config->op != PM_OP_MAIN ? 0 : PM_OP_QUERY); break;
-- 
1.7.0.6

Allan McRae <allan@archlinux.org>

14 years ago

Looks good.  Although, in all likelihood it will rarely capture the 
missing argument:

pacman -Sp --print-format kdelibs
error: no targets specified (use -h for help)

pacman -Sp kdelibs --print-format
pacman: option '--print-format' requires an argument

Pulled to my working branch.

Allan

[pacman-dev] [PATCH 2/2] remove dead assignment, spotted by clang Export this patch

Signed-off-by: Serge Ziryukin <ftrvxmtrx@gmail.com>
---
 src/pacman/util.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/src/pacman/util.c b/src/pacman/util.c
index 5099237..c37c8b0 100644
--- a/src/pacman/util.c
+++ b/src/pacman/util.c
@@ -648,7 +648,6 @@ void print_packages(const alpm_list_t *packages)
 			string = strreplace(temp, "%s", size);
 			free(size);
 			free(temp);
-			temp = string;
 		}
 		printf("%s\n",string);
 		free(string);
-- 
1.7.0.6

Allan McRae <allan@archlinux.org>

14 years ago

I'd prefer to keep this there.  That way, if any further fields get 
added below that one, we will not have to remember to put that line 
back.  That line should be optimized away by any good compiler anyway.

Allan