Dubious use of postfix increment operator (possible bug)

[Hamlet]

While analysing the warnings emitted by GCC 6, I was pointed to this piece of code in renderer/Model_lwo.cpp (comment added):

int sgetI1( unsigned char **bp )
{
   int i;

   if ( flen == FLEN_ERROR ) return 0;
   i = **bp;
   if ( i > 127 ) i -= 256;
   flen += 1;
   *bp++;       // <== warning: unused value
   return i;
}


short sgetI2( unsigned char **bp )
{
   short i;

   if ( flen == FLEN_ERROR ) return 0;
   memcpy( &i, *bp, 2 );
   BigRevBytes( &i, 2, 1 );
   flen += 2;
   *bp += 2;
   return i;
} 

Starting from the second function, sgetI2(), it appears that it receives as argument a pointer to an unsigned character, passed by reference in C style (that becomes a pointer to the pointer).

It copies two bytes in a short, swap them as needed (handling little/big endian, I suppose), then it makes the pointer *bp point after the copied data and returns the value read.

There is a sgetI4() which does the same with 4 byte data.

Back to the first quoted, I was assuming sgetI1() would do the same. GCC complains that the statement *bpp++ produces an unused value. It turns out, the postfix increment operator (a++) has the highest priority among C and C++ operators, and it gets executed before the dereference operator. That means that I would expect the code to operate like (*bp)++, equivalent to *bp += 1, similarly to sgetI2(), but I get instead a *(bp++). This means that the local variable bp (unsigned char**) is increased (while the unsigned char* pointer *bp is not), and then the value it was pointing to before the increase is taken and ignored.

All in all, it means that when it's called as sgetI1(&ptrToBuffer), it returns the value at the current value of ptrToBuffer and, on the next call, sgetI1(&ptrToBuffer), it returns again the same value, since ptrToBuffer is not increased.

 

The same construct appears in sgetU1() and in add_clip() on nclips (a simple pointer int*), where it might have more serious consequences:

   *nclips++;
   clip->index = *nclips;

since the an index is assigned from the cell of memory next to nclips (nclips is first increased).

I can't find any place where the former two are used, while add_clip() is pulled in from LoadLWO() in renderer/Model.cpp (at which point I stopped tracking).

 

I attach a trivial patch that removes these warnings by just doing the thing that would be usually expected (increase the pointed value) (it also removes the other instance of it, not mentioned in this text).

 

 

Edit: discovered that syntax highlight for C/C++ works with code type "auto", even if it does not show in the preview.

UnusedValue.patch.txt

Edited January 2, 2017 by Hamlet

[duzenko]

Is this code ever executed and does the fixed code cause any instantly visible problems?

Not sure if TDM uses LWO's anywhere?

[nbohr1more]

Yes, LWO (Lightwave Object) models are used. Sprinheel's main expertise is modeling in Lightwave.

[Hamlet]

Is this code ever executed and does the fixed code cause any instantly visible problems?

Not sure if TDM uses LWO's anywhere?

My understanding is too small to answer the first question: I learned what LWO means after reading the previous post.

I also don't know what a "clip" is.

The main reason of my post is to see if the experts have anything to add to the picture, that might predict a type of failure or to connect this to an already observed one.

I can see the dubious function being called when a ID_RIMG or ID_TIMG is found, in code that looks like a parser. The former seems related to reflection effects on a surface, the latter ends in the parameters of a texture. Maybe there might be effects related to clipping of these surfaces and textures? Just wildly guessing here.

 

About the patch: I do not claim to have tested it properly yet, and as always I personally recommend not merging it into anything official until that happens.

[nbohr1more]

Clip is a special texture that imbues a surface with physics attributes.

Plain clip is used for the collision model, playerclip keeps a the player from

entering an area, and monsterclip is used to ensure that AI can properly pathfind

by simplifying the path generation.

[NightStalker]

Hamlet,

I'm a little late with this advice, but I've just loaded a TDM map in DarkRadiant (DR) for the 1st time. And since you've already installed DR, if you extract one of mission PK4 files (I used the simplistic "Closemouthed Shadows" mission) and load the map in DR, you'll get a nice window showing various "Clip" and "Monster Clip" (etc) objects, rendered in 3D and nicely labeled.

As for your patches to address these compile-time warnings, I have not forgotten about them. I plan to look into any/all of them more sometime after the 2.05 build problems are put to rest. I think some of these changes may meet some resistance, but I still think they're worth further investigation, so I hope you haven't begun to think that I'm ignoring your patches. There's just so much to do and so little time (for me).