Age | Commit message (Collapse) | Author |
|
|
|
The copyright was a historical remnant of diameter's roots prior to its
inclusion in OTP.
Thanks to Anatolie Golovco.
|
|
|
|
|
|
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.
|
|
This is an encoding that didn't exist at the time of the previous
commit, but which was added in commit 83b6daef. Use it to restrict
stringification to lists containing printable ascii.
|
|
That is, preprocessed forms that can be passed to compile:forms/1,2.
|
|
In particular, make codec/2 flexible as to what's generated, the formats
(erl, hrl, parse, forms and beam) being passed in the options list and
defaulting to [erl, hrl]. The 'parse' format is the internal format to
which dictionaries are parsed, which can be manipulated by flatten/1
before being passed back to codec/2 or format/1.
Remove the (undocumented) dict/1,2 since codec/2 now subsumes it with
the 'parse' option.
|
|
Function can now take a literal dictionary as input, instead of a path,
and can return results instead of writing them to the filesystem.
|
|
Didn't matter before diameter_make since the module was only called from
diameterc(1).
|
|
Instead of being output as a consequence of a debug option.
|
|
|
|
In preparation for allowing return instead of write.
|
|
"spec" is an old term the internal representation of a dictionary. The
new extensions are in the style or those that compile(3) can generate.
|
|
|
|
The workaround (commit 57d5564f) was to dialyzer only understanding
nowarn_unused_function on individual functions. This is no longer the
case as of R15B01 (commit 477fd95a).
|
|
Depending on the dictionary, generated dictionary modules may contain
unused functions included from diameter_gen.hrl. There may still be
warnings however since even used functions can contain code that
isn't reached for a given dictionary.
It would be useful for diameter to generate spec attributes for
a dictionary's generated records but the format of these is currently
undocumented.
|
|
Didn't quite interpret '*' as RFC 3588 dictates. In particular, the
interpretation depends on what's being qualified, a required, optional
or fixed AVP.
|
|
Writing a dictionary to file failed.
|
|
A value is required to be the same as any specified with
@avp_vendor_id but otherwise the two locations are equivalent.
Both possibilities are allowed since @avp_vendor_id is required
for AVPs of types other than Grouped (modulo it not really needing
to exist at all: see commit 943266c9) and since the grammar parsed
in @grouped (from RFC 3588) allows it.
|
|
|
|
@vendor is only required if the id is actually needed. That is, if
there is a locally defined AVP whose V flag is set and which does
not have a vendor id set by @avp_vendor_id.
Also, in the case of an inherited AVP, fix avp_name/2 in a generated
dictionary module defaulting vendor id from @vendor in the inheriting
dictionary but avp_header/1 defaulting it from the inherited dictionary.
In both cases the vendor id now defaults from @vendor in the inherited
dictionary.
Note that @avp_vendor_id from the inherited dictionary is
ignored: any changes from @vendor have to be explicit in the
inheriting dictionary. A better alternative to @avp_vendor_id
is to simply inherit from dictionaries setting the appropriate
@vendor but this was previously somewhat broken so @avp_vendor_id
was needed to set the id of an AVP whose definition was copied
from another source into a dictionary that only inherited from
the common dictionary (which doesn't set V on any AVPs).
|
|
|
|
The section simply results in generated macros and has nothing
specifically to do with result codes. It's still not documented,
and neither are the macros generated from @enum, since the generated
names are typically so long as to be impractical/unreadable in source.
Better to use numeric values with a comment or define your own
shorter macros as the need arises.
|
|
|
|
* anders/diameter/augment_inherited_enums/OTP-9469:
Allow @enum when AVP is defined in an inherited dictionary.
|
|
3GPP standards (for one) extend the values allowed for RFC 3588
AVP's of type Enumerated. Previously, extending an AVP was only
possible by completely redefining the AVP.
|
|
@id defines an application identifier and this is used only when sending
or receiving messages. A dictionary can define only AVP's however,
to be included by other dictionaries using @inherits, in which case it
makes no sense to require @id.
Note that message definitions are not inherited with @inherits, only
AVP's
|
|
The application provides an implementation of the Diameter protocol
as defined in RFC 3588.
|