m-schmoock / lcpp

A Lua C PreProcessor

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Infinite loop on certain input

ayourtch opened this issue · comments

Processing the below .h file (synthesized from real-world sequence of includes from the fd.io) with lcpp results in an infinite loop.

Using anything other than a single underscore for the macro definition in the last part, e.g. two underscores, results in successful processing.

/*
 * Copyright (c) 2015 Cisco and/or its affiliates.
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at:
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
/*
  Copyright (c) 2001, 2002, 2003 Eliot Dresselhaus

  Permission is hereby granted, free of charge, to any person obtaining
  a copy of this software and associated documentation files (the
  "Software"), to deal in the Software without restriction, including
  without limitation the rights to use, copy, modify, merge, publish,
  distribute, sublicense, and/or sell copies of the Software, and to
  permit persons to whom the Software is furnished to do so, subject to
  the following conditions:

  The above copyright notice and this permission notice shall be
  included in all copies or substantial portions of the Software.

  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
  MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
  LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
  OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
  WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/

#ifndef included_clib_vec_bootstrap_h
#define included_clib_vec_bootstrap_h

#define _vec_find(v)    ((vec_header_t *) (v) - 1)

#define _vec_len(v)     (_vec_find(v)->len)

#define vec_len(v)      ((v) ? _vec_len(v) : 0)


/* ALU function definition macro for functions taking two bitmaps. */
#define _(name, body, check_zero)                               \
always_inline uword *                                           \
clib_bitmap_##name (uword * ai, uword * bi)                     \
{                                                               \
  bi_len = vec_len (bi);                                        \
  for (i = 0; i < vec_len (ai); i++)                            \
    {                                                           \
      do { body; } while (0);                                   \
    }                                                           \
  if (check_zero)                                               \
    _vec_len (ai) -= n_trailing_zeros;                          \
  return ai;                                                    \
}
/* ALU functions: */
_ (and, a = a & b, 1)
_ (andnot, a = a &~ b, 1)
_ (or,  a = a | b, 0)
_ (xor, a = a ^ b, 1)
#undef _

#endif /* included_clib_vec_bootstrap_h */

A further reduced testcase for this issue:

#define SOMEMACRO(v)    (YYYYY)

#define _(a) SOMEMACRO (bi);  _SOMEMACRO(ai);

_ (foo)

The parentheses around YYYYY are essential - if they are not there, the problem does not happen.

The problem is within the definition of the function that does the macro substitution - it matches on name that ends with a name of a macro that is already defined.

This patch seems to be taking care of it, I need to test it more extensively, I am not sure "^%w_" is the right class to match. But it gives the idea:

@@ -1268,9 +1301,13 @@ local function parseFunction(state, input)

        -- build macro funcion
        local func = function(input)
-               return input:gsub(name.."%s*(%b())", function (match)
+                local f1 = function (match)
                        return replaceArgs(match, repl)
-               end)
+               end
+               local f2 = function (match)
+                       return match:sub(1,1)..replaceArgs(match:sub(2), repl)
+               end
+               return input:gsub("^"..name.."%s*(%b())", f1):gsub("[^%w_]"..name.."%s*(%b())",f2)
        end

        return name, func, repl

Cool, can you make a PR including the testcase?

Yeah, let me debug bit more, together with other fixes (I think it might add a regression), I will get the fixes for them in once I get lcpp to fully process my monster header correctly. Thanks!