Syntax error in r_things.c

[Michael Bäuerle]

Since SVN r1746 my GCC 10 again has problems with a label that is not part of a statement:

r_things.c: In function 'R_AddSpriteDefs':
r_things.c:909:9: error: a label can only be part of a statement and a declaration is not a statement
  909 |         int fnd_count = R_AddSingleSpriteDef ( sprname, &sprites[sprindx], wadnum, ln1, ln2);
      |         ^~~

--- r_things.c.orig     2025-04-11 10:35:37.018924659 +0200
+++ r_things.c  2025-04-11 12:00:45.073314356 +0200
@@ -905,23 +905,25 @@
         continue;

      add_this_sprname:
-        // Load sprites from lumps with sprname.
-        int fnd_count = R_AddSingleSpriteDef ( sprname, &sprites[sprindx], wadnum, ln1, ln2);
-        if( fnd_count )
         {
-            if( verbose )
+            // Load sprites from lumps with sprname.
+            int fnd_count = R_AddSingleSpriteDef ( sprname, &sprites[sprindx], wadnum, ln1, ln2);
+            if( fnd_count )
             {
+                if( verbose )
+                {
 #ifdef ENABLE_DEH_REMAP
-                if( remap_index && (verbose > 1) )
-                    GenPrintf( EMSG_debug, "  Found remap sprite: %s\n", sprname );
+                    if( remap_index && (verbose > 1) )
+                        GenPrintf( EMSG_debug, "  Found remap sprite: %s\n", sprname );
 #endif
-                GenPrintf(EMSG_debug, "Sprite %s: Wad %i, Loaded to %i\n", sprname, wadnum, sprindx );
-            }
+                    GenPrintf(EMSG_debug, "Sprite %s: Wad %i, Loaded to %i\n", sprname, wadnum, sprindx );
+                }

-            // if a new sprite was added (not just replaced)
-            addsprites++;
-            if (devparm)
-                GenPrintf(EMSG_dev, "sprite %s set in pwad %d\n", sprname, wadnum);//Fab
+                // if a new sprite was added (not just replaced)
+                addsprites++;
+                if (devparm)
+                    GenPrintf(EMSG_dev, "sprite %s set in pwad %d\n", sprname, wadnum);//Fab
+            }
         }
     }

[Wesley Johnson]

Got it.
I cannot think of a way to stop that from happening.
Was generally happy that finally found what was causing the bushes to be missing.
Caused by introducing the fnd_count, which as it ended up was not used exactly as I expected.

[Michael Bäuerle]

For C99 I have checked draft N1256:
Section 6.8 (Statements and blocks) defines a "labeled-statement" as:

labeled-statement:
       identifier : statement
       case constant-expression : statement
       default : statement

Declarations are defined in Section 6.7 (Declarations).
The block with braces forms a "compound-statement":

compound-statement:
        { block-item-list opt }
block-item-list:
        block-item
        block-item-list block-item
block-item:
        declaration
        statement

I cannot think of a way to stop that from happening.

Specify the language revision and try with GCC in pedantic mode:
gcc -std=c99 -Wpedantic

The GCC man page says:

       -Wpedantic
       -pedantic
           Issue all the warnings demanded by strict ISO C and ISO C++; reject
           all programs that use forbidden extensions, and some other programs
           that do not follow ISO C and ISO C++.  For ISO C, follows the
           version of the ISO C standard specified by any -std option used.

[Wesley Johnson]

I tried the -pedantic and it produced 100's of warnings, went on for pages and pages.
I only found two of those warnings could be fixed, and many that I could not do anything about. As we have achieved compiling without warnings, this -pedantic does not represent what the standard the code it written to.

The code was originally C89, but uses "//" comments heavily (I do not use the old commenting) .
It is also not C99, because it uses alloca, which that does not recognize.
I have been through this before, several times. The doomlegacy code is what works to compile on about six different systems, include MinGW on windows, which is probably the most demanding.
Much of that was done before 2005.

Maybe some day I will accomplish making the code to agree with some standard, but right now those standards would not help, as they do not codify reality What it was complaining about were things that any compiler should be dealing with on its own, even 20 years ago.
For instance, it wants all the enum declarations to be "signed int", as it seems it cannot cope with them being "unsigned", specifically "0x80000000", and it does not matter if I put an "L", or even "LL" on it. I am not willing to make enums into a unmaintainable kludge just to satisfy that kind of pedantic nonsense..