Remove unnecessary checks before calls of the function “free”

2022-10-29 Thread Markus Elfring
Hello,

The function “free” is documented in the way that no action shall occur for
a passed null pointer. It is therefore not needed that a function caller
repeats a corresponding check.
https://stackoverflow.com/questions/18775608/free-a-null-pointer-anyway-or-check-first

This issue can be fixed also by using the software “Coccinelle 1.1.1”.

Regards,
Markus
diff --git a/bashline.c b/bashline.c
index c85b05b6..81010b68 100644
--- a/bashline.c
+++ b/bashline.c
@@ -1670,8 +1670,7 @@ attempt_shell_completion (text, start, end)
   char *n;
 
   /* XXX - don't free the members */
-  if (prog_complete_matches)
-	free (prog_complete_matches);
+  free (prog_complete_matches);
   prog_complete_matches = (char **)NULL;
 
   os = start;
@@ -1991,8 +1990,7 @@ command_word_completion_function (hint_text, state)
 
   if (dequoted_hint && dequoted_hint != hint)
 	free (dequoted_hint);
-  if (hint)
-	free (hint);
+  free (hint);
 
   mapping_over = searching_path = 0;
   hint_is_dir = CMD_IS_DIR (hint_text);
@@ -2056,8 +2054,7 @@ command_word_completion_function (hint_text, state)
 	}
 	  hint_len = strlen (hint);
 
-	  if (filename_hint)
-	free (filename_hint);
+	  free (filename_hint);
 
 	  fnhint = filename_hint = savestring (hint);
 
@@ -2093,14 +2090,12 @@ command_word_completion_function (hint_text, state)
   /* Initialize the variables for each type of command word. */
   local_index = 0;
 
-  if (varlist)
-	free (varlist);
+  free (varlist);
 
   varlist = all_visible_functions ();
 
 #if defined (ALIAS)
-  if (alias_list)
-	free (alias_list);
+  free (alias_list);
 
   alias_list = all_aliases ();
 #endif /* ALIAS */
@@ -2273,8 +2268,7 @@ globword:
 
   if (fnhint && fnhint != filename_hint)
 	free (fnhint);
-  if (filename_hint)
-	free (filename_hint);
+  free (filename_hint);
 
   filename_hint = sh_makepath (current_path, hint, 0);
   /* Need a quoted version (though it doesn't matter much in most
@@ -2409,8 +2403,7 @@ command_subst_completion_function (text, state)
 
   if (state == 0)
 {
-  if (filename_text)
-	free (filename_text);
+  free (filename_text);
   orig_start = text;
   if (*text == '`')
 	text++;
@@ -2421,8 +2414,7 @@ command_subst_completion_function (text, state)
   rl_completion_suppress_quote = 1;
   start_len = text - orig_start;
   filename_text = savestring (text);
-  if (matches)
-	free (matches);
+  free (matches);
 
   /*
* At this point we can entertain the idea of re-parsing
@@ -2491,8 +2483,7 @@ variable_completion_function (text, state)
 
   if (!state)
 {
-  if (varname)
-	free (varname);
+  free (varname);
 
   first_char_loc = 0;
   first_char = text[0];
diff --git a/builtins/common.c b/builtins/common.c
index 19b00c4d..b047c44d 100644
--- a/builtins/common.c
+++ b/builtins/common.c
@@ -434,8 +434,7 @@ shift_args (times)
 
   while (times-- > 0)
 {
-  if (dollar_vars[1])
-	free (dollar_vars[1]);
+  free (dollar_vars[1]);
 
   for (count = 1; count < 9; count++)
 	dollar_vars[count] = dollar_vars[count + 1];
diff --git a/builtins/mkbuiltins.c b/builtins/mkbuiltins.c
index f505ebde..350d8bbd 100644
--- a/builtins/mkbuiltins.c
+++ b/builtins/mkbuiltins.c
@@ -261,8 +261,7 @@ main (argc, argv)
 	{
 	  int len;
 
-	  if (error_directory)
-	free (error_directory);
+	  free (error_directory);
 
 	  error_directory = xmalloc (2 + strlen (argv[arg_index]));
 	  strcpy (error_directory, argv[arg_index]);
@@ -448,9 +447,7 @@ void
 array_free (array)
  ARRAY *array;
 {
-  if (array->array)
-free (array->array);
-
+  free (array->array);
   free (array);
 }
 
@@ -695,8 +692,7 @@ free_defs (defs)
   register int i;
   register BUILTIN_DESC *builtin;
 
-  if (defs->production)
-free (defs->production);
+  free (defs->production);
 
   if (defs->lines)
 array_free (defs->lines);
diff --git a/examples/loadables/csv.c b/examples/loadables/csv.c
index 75b37725..de7564a2 100644
--- a/examples/loadables/csv.c
+++ b/examples/loadables/csv.c
@@ -96,8 +96,7 @@ csvsplit (csv, line, dstring)
 }
   while (delim == *dstring);
 
-  if (xbuf)
-free (xbuf);
+  free (xbuf);
 
   return (rval = ind);/* number of fields */
 }
diff --git a/examples/loadables/dsv.c b/examples/loadables/dsv.c
index 70e59cbc..187ef685 100644
--- a/examples/loadables/dsv.c
+++ b/examples/loadables/dsv.c
@@ -156,8 +156,7 @@ dsvsplit (dsv, line, dstring, flags)
 }
   while (delim == *dstring);
 
-  if (xbuf)
-free (xbuf);
+  free (xbuf);
 
   return (rval = ind);/* number of fields */
 }
diff --git a/execute_cmd.c b/execute_cmd.c
index e5c6b9ab..b3b0aa31 100644
--- a/execute_cmd.c
+++ b/execute_cmd.c
@@ -5527,8 +5527,7 @@ execute_builtin_or_function (words, builtin, var, redirects,
   nfifo = num_fifos ();
   if (nfifo > ofifo)
 close_new_fifos (ofifo_list, osize);
-  if (ofifo_list)
-free 

Checking evolution of information about required symbols

2022-10-19 Thread Markus Elfring
Hello,

Some information was published with the subject “Bash-5.2 Release available”
on 2022-09-26.
https://lists.gnu.org/archive/html/bug-bash/2022-09/msg00056.html
https://www.mail-archive.com/info-gnu@gnu.org/msg03096.html

“…
Bash can be linked against an already-installed Readline library rather
than the private version in lib/readline if desired.  Only readline-8.1 and
later versions are able to provide all of the symbols that bash-5.2 requires;
…”

Would you like to recheck and reconsider such information in more detail?

On how many symbols does this program revision depend?

I got the impression that some of them became generally available only with
the change “readline-8.2 distribution sources and documentation” on 2022-09-26.
https://git.savannah.gnu.org/cgit/readline.git/commit/readline.h?id=f7a382fd09319b20ef4435b9b554183b605468c1
https://lists.gnu.org/archive/html/bug-readline/2022-09/msg00010.html
https://www.mail-archive.com/info-gnu@gnu.org/msg03097.html

How do you think about related searches for appropriate solutions?

Examples:
* 2022-10-02
  shells/bash: bash-5.2_2 is marked as broken: ld: error: undefined symbol: 
rl_trim_arg_from_keyseq
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266762

* 2022-10-15
  Fix the availability of the symbol “rl_trim_arg_from_keyseq” (for “bash 
5.2.2”)
  https://bugzilla.opensuse.org/show_bug.cgi?id=1204336

* 2022-10-18
  Checking ABI adjustments once more
  https://lists.gnu.org/archive/html/bug-readline/2022-10/msg00017.html


Regards,
Markus



Re: Checking executability for asynchronous commands

2020-12-29 Thread Markus Elfring
>…, is not a winning argument.

I got further development ideas according to the usage of wait function calls
and better error reporting for asynchronous commands.


>The OP seems to think that "people will occasionally forget to run `wait`",

This happens for various reasons.


> and wants to know if we "care" that people will forget …

The attention varies for this implementation aspect.


> Why should we care?

Would you like to care for proper management of system resources
(including process identifications)?


>The official advice is to run `wait`

How do you think about any additional guidance for such a programming interface?

Regards,
Markus



Re: Checking executability for asynchronous commands

2020-12-27 Thread Markus Elfring
>> Would you care if waiting on such identifications for background processes
>> will occasionally be forgotten?
>>
>> How many efforts would you invest to add potentially missing wait function 
>> calls?
>
> It's axiomatic: if you want to make a decision based on the exit status of
> any asynchronous process, you need to use `wait' to obtain the status of
> that process.
>
> I don't think "I don't want to do it that way" is a good reason to provide
> a different method.

I got another programming concern:
Process identifications are a system resource.
The exit status is preserved until this information will eventually be used
for corresponding data processing.
How many processes can a selected system configuration handle?

Regards,
Markus



Re: Checking executability for asynchronous commands

2020-12-27 Thread Markus Elfring
> If you have the pid of an asynchronous command -- and the easiest way to get 
> that pid
> is by referencing $! after it was started -- you can call `wait' with that pid
> to retrieve the status, even if it's already terminated.

Would you care if waiting on such identifications for background processes
will occasionally be forgotten?

How many efforts would you invest to add potentially missing wait function 
calls?

Regards,
Markus



Re: Checking executability for asynchronous commands

2020-12-26 Thread Markus Elfring
> If you want the exit status of the child process, add `wait $!'

Thanks for this information.

Is there a need then to point the aspect out that exit values can be determined
for child processes even if they terminated before a wait command would be 
performed?

Regards,
Markus



Re: Checking executability for asynchronous commands

2020-12-25 Thread Markus Elfring
> Are you maybe saying
>
>   cmd &
>
> should be a special case?

I got special imaginations according to such a command variant.

Regards,
Markus



Checking executability for asynchronous commands

2020-12-25 Thread Markus Elfring
Hello,

I am looking for another bit of clarification according to an implementation 
detail.

The manual is providing the following information.
https://git.savannah.gnu.org/cgit/bash.git/tree/doc/bash.1?id=76404c85d492c001f59f2644074333ffb7608532#n627

“…
   If  a command is terminated by the control operator &, the shell 
executes the command in the background in a subshell.  The shell does not wait 
for the command to finish, and the
   return status is 0.
…”


Thus I observe a behaviour like the following for a simple test with the
software “bash 5.0.18-3.1” according to a “program” which does not exist here.

elfring@Sonne:~> xy &
[1] 4063
xy: Befehl nicht gefunden
[1]+  Exit 127xy


I imagine that it can be occasionally helpful to determine the execution failure
in the synchronous way.
Would it make sense to configure the error reporting for selected asynchronous
commands so that they would become background processes only after the required
check for executability?

Regards,
Markus



Re: Bash-4.3-beta2: reserved identifier violation

2013-10-26 Thread Markus Elfring
 ftp://ftp.cwru.edu/pub/bash/bash-4.3-beta2.tar.gz

Hello,

I would like to point out that identifiers like _ARRAY_H_ and _PARSER_H_ do
not fit to the expected naming convention of the C language standard.
https://www.securecoding.cert.org/confluence/display/seccode/DCL37-C.+Do+not+declare+or+define+a+reserved+identifier#DCL37-C.Donotdeclareordefineareservedidentifier-NoncompliantCodeExample%28HeaderGuard%29

Would you like to adjust your selection for unique names?

Regards,
Markus