diff options
author | Anders Svensson <[email protected]> | 2014-09-12 16:31:24 +0200 |
---|---|---|
committer | Anders Svensson <[email protected]> | 2014-09-12 17:10:21 +0200 |
commit | 8e5e66b66cf318722e5b128c1b690fa2d080f1db (patch) | |
tree | 9ea5f8fb75a3baaafdc4dbed08d0dcaa1e755fcb /lib/snmp/examples | |
parent | 0f9cdbaf4d7fde93d319be7789dd4119092d91c6 (diff) | |
download | otp-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