Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

windres-wrapper does not support macros in strings #140

Closed
driver1998 opened this issue Jul 27, 2020 · 4 comments
Closed

windres-wrapper does not support macros in strings #140

driver1998 opened this issue Jul 27, 2020 · 4 comments

Comments

@driver1998
Copy link

driver1998 commented Jul 27, 2020 •
edited
Loading

Test file

#include <windows.h>

#define WORLD "world"

STRINGTABLE DISCARDABLE
BEGIN
    2048 "Hello " WORLD
END

Result

$ i686-w64-mingw32-windres -i test.rc -o test.res
llvm-rc: Error parsing file: expected '-', '~', integer or '(', got "world"
i686-w64-mingw32-windres: error: llvm-rc failed
@driver1998 driver1998 changed the title windres-wrapper does not support macros in STRINGTABLE windres-wrapper does not support macros in strings Jul 27, 2020
@Biswa96
Copy link

Biswa96 commented Jul 27, 2020

Agreed. For example, I have tried to compile 86Box and llvm-rc shows that error. Maybe this is a llvm bug/absent feature.

@mstorsjo
Copy link
Owner

Thanks for the reduced testcase!

This is not a bug with macros themselves, but with concatenation. If you remove the space between "Hello" and WORLD, it builds fine.

So the testcase can be reduced into

STRINGTABLE DISCARDABLE
BEGIN
    2048 "Hello" "world"
END

This is a bit tricky, as 2048 and the rest should be considered separate args (you can have an optional comma inbetween), while "Hello" and "world" aren't two separate arguments but should be concatenated into one string.

@mstorsjo
Copy link
Owner

This is not a bug with macros themselves, but with concatenation. If you remove the space between "Hello" and WORLD, it builds fine.

Actually, it might build fine in that case, but it actually ends up different/wrong in that case. That expands to "Hello""world", which gets unescaped into Hello"world, which isn't what was expected.

@mstorsjo
Copy link
Owner

mstorsjo commented Aug 4, 2020

I posted a patch that should fix this issue at https://reviews.llvm.org/D85183.

hanswinderix pushed a commit to hanswinderix/llvm-project that referenced this issue Aug 5, 2020
@mstorsjo
[llvm-rc] Allow string table values split into multiple string literals
a7b4843 
This can practically easily be a product of combining strings with
macros in resource files.

This fixes mstorsjo/llvm-mingw#140.

As string literals within llvm-rc are handled as StringRefs, each
referencing an uninterpreted slice of the input file, with actual
interpretation of the input string (codepage handling, unescaping etc)
done only right before writing them out to disk, it's hard to
concatenate them other than just bundling them up in a vector,
without rearchitecting a large part of llvm-rc.

This matches how the same already is supported in VersionInfoValue,
with a std::vector<IntOrString> Values.

MS rc.exe only supports concatenated string literals in version info
values (already supported), string tables (implemented in this patch)
and user data resources (easily implemented in a separate patch, but
hasn't been requested by any end user yet), while GNU windres supports
string immediates split into multiple strings anywhere (e.g. like
(100 ICON "myicon" ".ico"). Not sure if concatenation in other
statements actually is used in the wild though, in resource files
normally built by GNU windres.

Differential Revision: https://reviews.llvm.org/D85183
zmodem pushed a commit to llvm/llvm-project that referenced this issue Aug 5, 2020
@mstorsjo @zmodem
[llvm-rc] Allow string table values split into multiple string literals
0835988 
This can practically easily be a product of combining strings with
macros in resource files.

This fixes mstorsjo/llvm-mingw#140.

As string literals within llvm-rc are handled as StringRefs, each
referencing an uninterpreted slice of the input file, with actual
interpretation of the input string (codepage handling, unescaping etc)
done only right before writing them out to disk, it's hard to
concatenate them other than just bundling them up in a vector,
without rearchitecting a large part of llvm-rc.

This matches how the same already is supported in VersionInfoValue,
with a std::vector<IntOrString> Values.

MS rc.exe only supports concatenated string literals in version info
values (already supported), string tables (implemented in this patch)
and user data resources (easily implemented in a separate patch, but
hasn't been requested by any end user yet), while GNU windres supports
string immediates split into multiple strings anywhere (e.g. like
(100 ICON "myicon" ".ico"). Not sure if concatenation in other
statements actually is used in the wild though, in resource files
normally built by GNU windres.

Differential Revision: https://reviews.llvm.org/D85183

(cherry picked from commit b989fcb)
arichardson pushed a commit to arichardson/llvm-project that referenced this issue Mar 22, 2021
@mstorsjo @arichardson
[llvm-rc] Allow string table values split into multiple string literals
6603631 
This can practically easily be a product of combining strings with
macros in resource files.

This fixes mstorsjo/llvm-mingw#140.

As string literals within llvm-rc are handled as StringRefs, each
referencing an uninterpreted slice of the input file, with actual
interpretation of the input string (codepage handling, unescaping etc)
done only right before writing them out to disk, it's hard to
concatenate them other than just bundling them up in a vector,
without rearchitecting a large part of llvm-rc.

This matches how the same already is supported in VersionInfoValue,
with a std::vector<IntOrString> Values.

MS rc.exe only supports concatenated string literals in version info
values (already supported), string tables (implemented in this patch)
and user data resources (easily implemented in a separate patch, but
hasn't been requested by any end user yet), while GNU windres supports
string immediates split into multiple strings anywhere (e.g. like
(100 ICON "myicon" ".ico"). Not sure if concatenation in other
statements actually is used in the wild though, in resource files
normally built by GNU windres.

Differential Revision: https://reviews.llvm.org/D85183
ajohnson-uoregon pushed a commit to ajohnson-uoregon/clang-rewrite-only that referenced this issue Jul 17, 2022
@mstorsjo @zmodem
[llvm-rc] Allow string table values split into multiple string literals
66fdcdf 
This can practically easily be a product of combining strings with
macros in resource files.

This fixes mstorsjo/llvm-mingw#140.

As string literals within llvm-rc are handled as StringRefs, each
referencing an uninterpreted slice of the input file, with actual
interpretation of the input string (codepage handling, unescaping etc)
done only right before writing them out to disk, it's hard to
concatenate them other than just bundling them up in a vector,
without rearchitecting a large part of llvm-rc.

This matches how the same already is supported in VersionInfoValue,
with a std::vector<IntOrString> Values.

MS rc.exe only supports concatenated string literals in version info
values (already supported), string tables (implemented in this patch)
and user data resources (easily implemented in a separate patch, but
hasn't been requested by any end user yet), while GNU windres supports
string immediates split into multiple strings anywhere (e.g. like
(100 ICON "myicon" ".ico"). Not sure if concatenation in other
statements actually is used in the wild though, in resource files
normally built by GNU windres.

Differential Revision: https://reviews.llvm.org/D85183

(cherry picked from commit 1a8f3a1)
mem-frob pushed a commit to draperlaboratory/hope-llvm-project that referenced this issue Oct 7, 2022
@mstorsjo
[llvm-rc] Allow string table values split into multiple string literals
9b29371 
This can practically easily be a product of combining strings with
macros in resource files.

This fixes mstorsjo/llvm-mingw#140.

As string literals within llvm-rc are handled as StringRefs, each
referencing an uninterpreted slice of the input file, with actual
interpretation of the input string (codepage handling, unescaping etc)
done only right before writing them out to disk, it's hard to
concatenate them other than just bundling them up in a vector,
without rearchitecting a large part of llvm-rc.

This matches how the same already is supported in VersionInfoValue,
with a std::vector<IntOrString> Values.

MS rc.exe only supports concatenated string literals in version info
values (already supported), string tables (implemented in this patch)
and user data resources (easily implemented in a separate patch, but
hasn't been requested by any end user yet), while GNU windres supports
string immediates split into multiple strings anywhere (e.g. like
(100 ICON "myicon" ".ico"). Not sure if concatenation in other
statements actually is used in the wild though, in resource files
normally built by GNU windres.

Differential Revision: https://reviews.llvm.org/D85183
@mstorsjo mstorsjo mentioned this issue Oct 12, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mstorsjo @driver1998 @Biswa96