aboutsummaryrefslogtreecommitdiffstats
path: root/lib/snmp/examples
diff options
context:
space:
mode:
authorAnders Svensson <[email protected]>2014-09-12 16:31:24 +0200
committerAnders Svensson <[email protected]>2014-09-12 17:10:21 +0200
commit8e5e66b66cf318722e5b128c1b690fa2d080f1db (patch)
tree9ea5f8fb75a3baaafdc4dbed08d0dcaa1e755fcb /lib/snmp/examples
parent0f9cdbaf4d7fde93d319be7789dd4119092d91c6 (diff)
downloadotp-8e5e66b66cf318722e5b128c1b690fa2d080f1db.tar.gz
otp-8e5e66b66cf318722e5b128c1b690fa2d080f1db.tar.bz2
otp-8e5e66b66cf318722e5b128c1b690fa2d080f1db.zip
Fix ?MODULE in preprocessed dictionary forms
By replacing literal diameter_gen_relay atoms in forms extracted from that module by the name of the module in question. This has been wrong for some time, but only became noticable when the parent commit started using ?MODULE as more than a process dictionary key or tag to match on. In particular, the function dict/1 in diameter_gen.hrl (included by every dictionary module) can now return ?MODULE, which is (not surprisingly) expected to be the name of the dictionary module in question. It wasn't in the case of a module compiled from forms: it was diameter_gen_relay, since that's the module the forms were extracted from. The fix only affects dictionaries compiled from forms, as returned by diameter_make:codec/2. In particular, dictionaries compiled from Erlang source returned by this function, or by diameterc(1), are unaffected.
Diffstat (limited to 'lib/snmp/examples')
0 files changed, 0 insertions, 0 deletions