tree aca9c181f8c0643374653870e6742db51dce2a4b
parent f4a6c20c39c97214e22625764bfa80ef8e1e3147
author Pablo Neira Ayuso <pablo@netfilter.org> 1343039236 +0200
committer Pablo Neira Ayuso <pablo@netfilter.org> 1343214292 +0200

iptables-restore: move code to add_param_to_argv, cleanup (fix gcc-4.7)

This patch seems to be a mere cleanup that moves the parameter parsing
code to add_param_to_argv.

But, in reality, it also fixes iptables when compiled with gcc-4.7.

Moving param_buffer declaration out of the loop seems to resolve the
issue. gcc-4.7 seems to be generating bad code regarding param_buffer.

@@ -380,9 +380,9 @@
                        quote_open = 0;
                        escaped = 0;
                        param_len = 0;
+                       char param_buffer[1024];

                        for (curchar = parsestart; *curchar; curchar++) {
-                               char param_buffer[1024];

                                if (quote_open) {
                                        if (escaped) {

But I have hard time to apply this patch in such a way. Instead, I came
up with the idea of this cleanup, which does not harm after all (and fixes
the issue for us).

Someone in:

https://bugzilla.redhat.com/show_bug.cgi?id=82579

put some light on this:

"Yes, I ran into this too. The issue is that the gcc optimizer is
optimizing out the code that collects quoted strings in
iptables-restore.c at line 396. If inside a quotemark and it hasn't
seen another one yet, it executes

   param_buffer[param_len++] = *curchar;
   continue;

At -O1 or higher, the write to param_buffer[] never happens. It just
increments param_len and continues.

Moving the definition of char param_buffer[1024]; outside the loop
fixes it. Why, I'm not sure. Defining the param_buffer[] inside the
loop should simply restrict its scope to inside the loop."

Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>