[Rpm-maint] [rpm-software-management/rpm] New rpmExpandMacrosAt API with location information. (#494)

[Jeff Johnson]

Abstracting location information is perfectly sound (but there's no need for the reserved fields).
All that is minimally needed is a string and an integer, but perhaps a prefix could be added for speshully spiffy error output.

Drilling an extra argument everywhere is a non-starter for multiple reasons. In fact the 3-5 locations that call expandMacro() with a buffer on stack need to be eliminated in favor of always returning a malloc'd string, and stop exporting the symbol.

(aside)
this code dates back to 1998 when the glibc malloc() was known to have fragmentation issues and rpm went to some absurd lengths to avoid malloc. The replacement interfaces are obviously there, just not used consistently. I and everyone else since sanely followed a "Don't fix what isn't broken" policy ideveloping rpm code.

I think you are going to find that the line no information is not what you expect because rpmbuild used to expand per buffer, pairing curlies/parens/quotes to ensure that an entire expression resided in a static buffer that was expanded in place. But perhaps someone has repaired that hackery since added when lua was added.

Instead of adding an extra argument, I'd add methods to associate location info with both the macro context and the macro item, using the macro item location (typically set from a file and line no when initializing) first, and the location info of the context if the item is being defined dynamically (your case). A wrapper to append __FILE__, __LINE__ will handle programmatic defines through a new interface, which can also be called with whatever string and integer one wishes (with appropriate obvious defaults of NULL, 0 meaning not defined.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/494#issuecomment-410339633
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20180803/31d09fa1/attachment.html>