[Gerry Kan]

Howdy Folks:

I just want to get a sense of what your opinions are ...

The project I am working on, any code with unused identifiers will fail the regression test. Normally it's a good thing, but I now have to make function calls to a third-party .so file that is not part of the project. The presence of this .so file is optional, so if it is not there, I will replace them with placeholder function calls that do nothing.

But here comes the problem. For the placeholder version of these functions, I need to introduce placeholder arguments to match the function prototypes in the .so. Since these arguments also do nothing, my code will not the pass regression test, because they are now seen as unused identifiers.

The question is, how should I go about this issue? I could just have statements like a = a in the placeholder function implementations to trick the compiler, but I am looking for something more elegant than this?

Thanks in advance, Gerry.

[sbaffini]

In my opinion this is something that should have been decided when the rule to fail the regression test was devised, despite seeing where that rule comes from (and how it could have underlooked possible non trivial scenarios).

For the same reason, however, this is also such a corner case that you can also avoid overthinking it. Self assignment seems to be weird enough to highlight the situation.

But maybe I would prefer defining some parameters, specifically dedicated to this, like NULL_INTEGER_INITIALIZATION, NULL_REAL_INITIALIZATION, etc., with all the necessary comments where they are used and defined. In particular, defining them in a dedicated module would even more help you track these pieces of code where this happens.

[Gerry Kan]

Paolo:

Thanks. Looks like the self-assignment is the most reasonable solution in this case. Like you said, I am going to set up #ifdef blocks to section up the normal and placeholder sections of the code in the same module. Nothing more.

Gerry.

P.S. - Don't even get me started about some of the code maintainers' great ideas about project management. These people have obviously never worked in a production environment before in their lives, let alone seeing one. On one hand, they have a lot of disposable time to implement these "continuous improvements" on their own initiative, and on the other hand, these "continuous improvements" change your workflow and code base just enough you spend more time "continuously" adapting to their "improvements" than getting things done.