Importing string constants in PO
Importing string constants does not work in PO. Strings from same module are shown.
It’s a know issue in PO2013. When a module M exporting a string s is imported by another module N, an object for the imported string M.s is created in the symbol table of N, with the string position (strx) of s within module M (!) is stored in the field obj.val of the generated object. However, when during compilation of the importing module N string M.s is referenced, a string item will by created via ORB.MakeStringItem which copies the string buffer from ORS.str (i.e. the strings of the importing module N = the module currently being compiled), but using the string position of the *imported* module. That’s the bug. And the reason why you are seeing the strings from the importing module. The fix would be to make string constants aware of modules. Both require rewriting the compiler. Method #1 would be to include the actual strings in the symbol files (and not just their string position). However, this would change the format of the symbol file. Method #2 would be to change the code generated for expressions containing imported strings, such that they reference external strings constants via the SB of the imported module.
Am 19.02.2018 um 21:40 schrieb Andreas Pirklbauer:
> Importing string constants does not work in PO.
Strings from same module are shown.
It’s a know issue in PO2013. When a module M exporting a string s is imported by another module N, an object for the imported string M.s is created in the symbol table of N, with the string position (strx) of s within module M (!) is stored in the field obj.val of the generated object.
However, when during compilation of the importing module N string M.s is referenced, a string item will by created via ORB.MakeStringItem which copies the string buffer from ORS.str (i.e. the strings of the importing module N = the module currently being compiled), but using the string position of the *imported* module.
That’s the bug. And the reason why you are seeing the strings from the importing module.
The fix would be to make string constants aware of modules. Both require rewriting the compiler.
Method #1 would be to include the actual strings in the symbol files (and not just their string position). However, this would change the format of the symbol file.
Method #2 would be to change the code generated for expressions containing imported strings, such that they reference external strings constants via the SB of the imported module.
Thanks for clarification. Although I think ORG.Mod should be updated to give an error when importing string constants, like I will do in my ORGx.Mod Peter Peter
Science trained persons should not ape lawers and politicians by PeeCee renaming ERRORS and PROBLEMS to ISSUES. Do other societies also have this PeeCee disease like we <Anglos> ? C. Glur. On 2/20/18, Peter Matthias <PeterMatthias@web.de> wrote:
Am 19.02.2018 um 21:40 schrieb Andreas Pirklbauer:
> Importing string constants does not work in PO.
Strings from same module are shown.
It’s a know issue in PO2013. When a module M exporting a string s is imported by another module N, an object for the imported string M.s is created in the symbol table of N, with the string position (strx) of s within module M (!) is stored in the field obj.val of the generated object.
However, when during compilation of the importing module N string M.s is referenced, a string item will by created via ORB.MakeStringItem which copies the string buffer from ORS.str (i.e. the strings of the importing module N = the module currently being compiled), but using the string position of the *imported* module.
That’s the bug. And the reason why you are seeing the strings from the importing module.
The fix would be to make string constants aware of modules. Both require rewriting the compiler.
Method #1 would be to include the actual strings in the symbol files (and not just their string position). However, this would change the format of the symbol file.
Method #2 would be to change the code generated for expressions containing imported strings, such that they reference external strings constants via the SB of the imported module.
Thanks for clarification. Although I think ORG.Mod should be updated to give an error when importing string constants, like I will do in my ORGx.Mod
Peter
Peter -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
participants (3)
-
Andreas Pirklbauer -
eas lab -
Peter Matthias