After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 64714 - [PATCH] glib-mkenums parse error
[PATCH] glib-mkenums parse error
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gobject
1.3.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2001-11-16 17:57 UTC by Mark McLoughlin
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Mark McLoughlin 2001-11-16 17:57:28 UTC
with an enum defined as such

typedef enum {
        BLAH,
        BLAH1
}   /* the newline causes the problem */
blahenum;

glib-mkenums fails with a parse error ...

the following patch fixes it.

May I commit?

Index: glib-mkenums.in
===================================================================
RCS file: /cvs/gnome/glib/gobject/glib-mkenums.in,v
retrieving revision 1.3
diff -u -p -r1.3 glib-mkenums.in
--- glib-mkenums.in	2001/10/29 16:13:36	1.3
+++ glib-mkenums.in	2001/11/16 17:56:39
@@ -27,6 +27,7 @@ sub parse_trigraph {
 sub parse_entries {
     my $file = shift;
     my $file_name = shift;
+    my $looking_for_name = 0;
     
     while (<$file>) {
 	
@@ -46,6 +47,13 @@ sub parse_entries {
 	next if m@^\s*$@;
 	
 #	print STDERR "xxx $_\n";
+
+	if ($looking_for_name) {
+	    if (/^\s*(\w+)/) {
+		$enumname = $1;
+		return 1;
+	    }
+	}
 	
 	# Handle include files
 	if (/^\#include\s*<([^>]*)>/ ) {
@@ -74,6 +82,12 @@ sub parse_entries {
 	    return 1;
 	}
 	
+	if (/^\s*\}/) {
+	    $enumindex++;
+	    $looking_for_name = 1;
+	    next;
+	}
+
         if (m@^\s*
               (\w+)\s*                   # name
               (?:=(                      # value
Comment 1 Owen Taylor 2001-11-17 21:16:40 UTC
Well, this isn't the most elegant way of handling this ...
I'd probably try to unify the handling of this with
the handling of the normal close. But looks like
it will work. Go ahead and commit.
Comment 2 Mark McLoughlin 2001-11-18 17:56:24 UTC
No, its certainly not elegant - its a passable quick fix :-)

I've committed anyway.

Oh, and if you're wondering why I didn't just fix my headers, the
problem occurs generating enums from orbit-idl generated headers ...

And the problem there is not orbit-idl, its indent .. :/