Details
Diff Detail
Event Timeline
llvm/lib/DebugInfo/DWARF/DWARFDebugAddr.cpp | ||
---|---|---|
55–75 | @labath another instance of this 32/64 length parsing/error dance and subsequent "isValid" checking following it that'd be great to tidy up with a common utility for parsing the length and returning a length-constrained DWARFDataExtractor for further use. |
llvm/lib/DebugInfo/DWARF/DWARFDebugAddr.cpp | ||
---|---|---|
68 | Thanks! I'll change the name, as well as for the other similar instances. | |
159 | Could you explain why unsinged is better than int here? Note that according to http://www.cplusplus.com/reference/cstdio/printf/,
Not "an unsigned integer value". |
- Update to reflect changes in parent revisions.
- TmpLength -> DiagnosticLength.
- Added a test for insufficient space for an extended length field.
llvm/lib/DebugInfo/DWARF/DWARFDebugAddr.cpp | ||
---|---|---|
57 | IIRC, the DataExtractor class provides an optional second argument to its get... methods that can be used to specify an Error to pass any problems back in, including reading past the end. Would it make some sense to use that instead of the isValid... checks? | |
71–74 | Maybe errc::not_supported? | |
159 | I find the following link tends to be more precise and accurate in its wording: https://en.cppreference.com/w/cpp/io/c/fprintf
I don't have a copy of the standard to see whether the type is explicitly mentioned, but that quote definitively says int. |
llvm/lib/DebugInfo/DWARF/DWARFDebugAddr.cpp | ||
---|---|---|
159 | Cool, I wasn't aware of that. |
llvm/lib/DebugInfo/DWARF/DWARFDebugAddr.cpp | ||
---|---|---|
159 | Oh, that reference is great. They even have a sample with a negative value for field width. |
llvm/lib/DebugInfo/DWARF/DWARFDebugAddr.cpp | ||
---|---|---|
159 | Huh, I didn't notice that, nor did I realise that left-justification was even possible! |
llvm/lib/DebugInfo/DWARF/DWARFDebugAddr.cpp | ||
---|---|---|
57 | Can't say I like that because the resulting diagnostic messages might not be that informative as with the current approach. |
- Updated to reflect changes in parent revisions.
- Changed errc::invalid_argument to errc::not_supported for the message for a reserved unit length value.
IIRC, the DataExtractor class provides an optional second argument to its get... methods that can be used to specify an Error to pass any problems back in, including reading past the end. Would it make some sense to use that instead of the isValid... checks?