🚀 go-pugleaf

    In the gcc/g++ manual, it says 

     `-pedantic' does not cause warning messages for use of the
     alternate keywords whose names begin and end with `__'.  Pedantic
     warnings are also disabled in the expression that follows
     `__extension__'.  However, only system header files should use
     these escape routes; application programs should avoid them.
     *Note Alternate Keywords::.

  Neither of these alternatives will work for accessing gcc's "long
  long" facility if you are compiling with -pedantic; there is no
  underscored version of "long long" and the "__extension__" keyword
  only works before primary expressions.  A minor modification to the
  parser will allow the use of __extension__ to enable "long long"s,
  at least in the global scope; the following is an example from the
  g++ 2.7.1 parser in the rules for the "extdef" tag:

*** ../../link/src/gcc_2_7_1/cp/parse.y      Fri Dec 01 18:36:22 1995
--- cp/parse.y  Mon Dec 16 11:44:12 1996
***************
*** 349,354 ****
--- 349,362 ----
                 { if (pending_inlines) do_pending_inlines (); }
         | datadef
               { if (pending_inlines) do_pending_inlines (); }
+        /* Allow datadef with a precedigin __extension__ to turn
+          off -pedantic.  This specifically gives a way to use
+           "long long"s.  */
+   | EXTENSION
+            { $<itype>1 = pedantic;
+                  pedantic = 0; }
+        datadef
+              { pedantic = $<itype>1; }
       | template_def
                  { if (pending_inlines) do_pending_inlines (); }
         | overloaddef


  This allows data definitions (including typedefs) to be declared
  long long at the top level, which allows use of long longs in
  -pedantic compiler programs.  Possibly creation of a __longlong__
  keyword would be more appropriate; certainly a complete fix would be
  preferable (i.e. the same modification in gcc as well as allowing
  long longs in function arguments and local variables).  But based on
  my understanding of the manual, some variation on this change would
  be appropriate; it might even be reasonable (though I know I'm
  stretching here) to consider it's lack a bug.

						-- Randy