[PATCH] D82549: [AIX][XCOFF] parsing xcoff object file auxiliary header
Digger via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Jul 10 08:39:49 PDT 2020
DiggerLin added inline comments.
================
Comment at: llvm/tools/llvm-readobj/XCOFFDumper.cpp:486
+#define PrintAuxMember(H, S, T, X) \
+ W.print##H(S, T); \
----------------
hubert.reinterpretcast wrote:
> This macro does not operate within the confines of what a function can do with respect to its caller (it can cause the caller to return early). I do not believe that using a function-like naming style is appropriate. I also do not believe that using such a macro for control flow is desirable.
>
> You can encode a table (yes, a macro is okay for that) with much the same information:
> (format, description, pointer-to-member, offset in the table past-the-end of the member)
>
> and use that table in the place where this macro is being invoked.
for the function printNumber is a overload function. using a macro, the complie will determine which version of printNumber will be used when compile. if using a table, I think how to make the code call the correct overload version of printNumber based in the parameter type when running may be complicated.
================
Comment at: llvm/tools/llvm-readobj/XCOFFDumper.cpp:491
+ W.print##H(S, T); \
+ if ((X = X - sizeof(T)) == 0) \
+ return
----------------
hubert.reinterpretcast wrote:
> DiggerLin wrote:
> > hubert.reinterpretcast wrote:
> > > This strikes me as extremely hazardous. What if we get a length value that is reflective of a partial field?
> > thanks
> We still have to build with C++14 compilers for the time being. Assigning a large 64-bit value to a 32-bit signed type is verboten. In any case, checking the table size against the last field of the table I described above would avoid this issue.
thanks.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D82549/new/
https://reviews.llvm.org/D82549
More information about the llvm-commits
mailing list