Consider removing "_self" as a keyword in non-DOS targets

[ArmstrongJ]

I've run into some code that is failing to build because Open Watcom defines _self as a keyword (actually a predefined macro for __self) in bld/plusplus/c/cmdln.c:204. From the docs, it appears that this keyword exists to maintain compatibility with Microsoft C, which is fine. It might be better, however, to only define the macro in cases where the compiler target is 16-bit, though, to avoid issues.

[jmalak]

__self symbol is from compiler reserved name space. What type of issue you have?

[ArmstrongJ]

Yes, double-underscore-self, __self, is in the compiler's reserved name space. I have no problem with that.

However, Open Watcom has a non-optional, predefined macro single-underscore-self, _self, that is there, according to the documentation, to provide compatibility with Microsoft C (not MSVC). The single underscore does not imply it is in the compiler's reserved namespace.

I encountered a build error working with some CPython code because a certain module defined an argument to a function as single-underscore-self, _self. Open Watcom's predefined macro mapped this to double-underscore-self, causing some truly cryptic errors.

For an example, see: http://hg.python.org/cpython/file/3.2/Modules/_io/textio.c#l259

I have submitted a patch to Python to fix this in their trunk (and it has been accepted), but Open Watcom probably should not be defining the single-underscore-self, _self, in all cases.

[jmalak]

It can not be removed by default or for any target. It must work as is for backward compatibility. But it could be managed by some new C/C++ compiler option. This option could suppress all these macros which are assigned any keyword, etc.

[ArmstrongJ]

Adding an option is also fine. I think it would be best, however, that these non-standard, single-underscore and no-underscore macros be disabled by default, especially for platforms where they are undesirable to be set. For example, reserving the words far and near for linux targets (or any 32-bit target?) is probably a bad idea these days.

My understanding is that Open Watcom likes to stick to standards. In this regard, we really shouldn't be reserving keywords or defining mandatory macros that are not in the standard or any modern, equivalent toolchain.

In the example I included above, the Python maintainers were nice enough to accept the patch, but I think it should be looked at as an exception. Basically I had to hope that they'd accept into their trunk fixes for something on an unsupported compiler. This compiler doesn't carry much weight or influence any longer, so many other large projects will probably be far more hesitant, if not entirely resistant, to accepting Open Watcom-specific patches.

I completely understand and agree with the desire to maintain compatibility. However, in this example, we're imposing a predefined macro on all platforms and targets in order to maintain compatibility with Microsoft's C compiler for DOS. As I pointed out, Visual C does not define this macro.

[jmalak]

It is true for 32-bit flat model, but as soon as you use 16 or 32-bit segmented models you need far and near. Latest Visual C++ 20xx versions are not able to generate segmented code anymore in contrast with Open Watcom. Generaly definition of these macros are used for unmodified code over any OW supported platforms without any change or conditional compilation. On platforms where it has no sense assigned keyword has no meaning. By example all "language" related keywords have no meaning on RISC platforms and represent one default language. Generaly OW use its own macros, symbols, etc. and all extensions by default. If you want standard ISO behaviour you must specify appropriate options to suppress unwonted feature. It is logic which is used by all OW tools. Anyway you can setup appropriate environment variable with your default option (WCC386, WCC, WPP386, WPP etc.) that you simplify handling of compilers options in makefiles etc.

[jmalak]

I think suitable option could be -zam to suppress all predefined macros (mostly redundant) with name incompatible with ISO standard options -za -zA and -za99 should be modified to include this functionality too Any other ideas?

[ArmstrongJ]

I think that option sounds great!

+1

[jmalak]

I added -zam option for C/C++ compilers. It disable all macros as far, near, _far, _near, cdecl, pascal, _cdecl, pascal,... It disables also compilers macros beggining with M.... These macros exist with M prefix already. meaning of -zam is "disable all predefined non-ISO extension macros"

[ArmstrongJ]

I'll pull and give it a shot.

[ArmstrongJ]

Thanks, @jmalak. Just tried a fresh build, and it now accepts single-underscore-self, _self, as a valid variable name when used with the -zam flag.