Do not have calls with side effects from macro calls.

[Kurt Schwehr]

e.g. The ++ in the EQUAL is scary:

​https://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogr_srs_validate.cpp?rev=36139#L1194

    while( papszAliasGroupList[iGroup] != NULL )
    {
        if( EQUAL(papszAliasGroupList[iGroup++], pszParm2) )
            return TRUE;
    }

    return FALSE;

We can either move the change to variable outside of the macro and/or make things like EQUAL be inline functions for C++.

Where EQUAL is:

​https://trac.osgeo.org/gdal/browser/trunk/gdal/port/cpl_port.h?rev=36139#L587

#define STRCASECMP(a,b)         (strcasecmp(a,b))
#define EQUAL(a,b)              (STRCASECMP(a,b)==0)

In this particular case, I think the C++ EQUAL should be something like this with no macros:

// Explain what should happen if s1 and/or s2 are nullptr.
inline bool EQUAL( const char *s1, const char *s2 )
{
   // TODO(schwehr): Do we need to do anything if one or both of s1, s2 are nullptr?
#if defined(WIN32)
    return stricmp(s1, s2) == 0;
#else
    return strcasecmp(s1, s2) == 0;
#endif
}

[Even Rouault]

I'd vote to move the ++ out of the comparison

[Kurt Schwehr]

I would vote for both moving things like ++ out of calls and for changing macros to inline functions

[Even Rouault]

In 41734:

Avoid ++ operator in comparison (refs #6717)

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.