1

https://open-watcom.github.io/open-watcom-v2-wikidocs/cguide.html explains #pragma aux default to specify default symbol name generation. For example:

/* prog.c */
#pragma aux default "__*__"
extern int mysym1;
extern int mysym2(int x);
int mysym3(void) { return mysym2(mysym1); }

Then compile:

$ owcc -c -o prog.obj prog.c
$ wdis prog.obj | grep mysym
0000                            __mysym3__:
000A  A1 00 00 00 00                    mov             eax,_mysym1
000F  E9 00 00 00 00                    jmp             __mysym2__

Please note that mysym1 didn't receive the surrounding double underscores, so it was unaffected by #pragma aux default. How can the default be changed for variables as well?

Please note that #pragma aux mysym1 "__*__" does work for a single variable, but I want to change the default for all of them.

pts
  • 80,836
  • 20
  • 110
  • 183
  • 1
    It's not clear why that doesn't work. The [documentation](https://open-watcom.github.io/open-watcom-v2-wikidocs/cguide.html#32Mbit__Alternate_Names_for_Symbols) doesn't say that this is specific to function names. – Barmar Jun 02 '23 at 20:44
  • 1
    The behavior you show is not what the documentation leads me to expect. This is probably a bug in the compiler, but possibly a bug in the docs. Either way, it makes sense to raise an issue with the project. Do note, by the way, that all GitHub "releases" of this project so far are tagged with pre-release status. This is not yet a stable product. – John Bollinger Jun 03 '23 at 00:20
  • @JohnBollinger: It's unlikely that it will become more stable suddenly. The Watcom C compiler targeting i386 has been available for purchase since the early 1990s. – pts Jun 03 '23 at 01:08
  • I don't know about *suddenly*, @pts, but the docs you have linked are for Open Watcom v2. I don't know details of its code lineage, but this is an [active project](https://github.com/open-watcom/open-watcom-v2), with 37 (pre-release) releases in the last 3 years, and multiple commits within the last week. Personally, I find it plausible that v2 is less stable at this point than some previous versions were, and less stable than it will be in the future. – John Bollinger Jun 03 '23 at 12:32
  • In any case, whether it's reasonable to expect better stability in the future is irrelevant to the question of whether you can or should accommodate instability *now*. – John Bollinger Jun 03 '23 at 12:38

0 Answers0