tvb_get_string(). (Some versions of the spec speak of ISO 8859-15
strings as well as UTF-8 strings, but we don't appear to try to handle
those.)
Update spec URL.
svn path=/trunk/; revision=54910
be misreading Q.2630.3, as it seems to indicate that the addresses are
BCD, not ASCII, speaking as it does of "hexadecimal digit[s] of
address[es]".
svn path=/trunk/; revision=54909
http://web.archive.org/web/20080308233204/http://dev.aol.com/aim/oscar/#SNAC
"In general strings are not NULL terminated and are encoded using UTF8."
It also says
Authentication
Over the years, the AIM backend has supported several different
methods for authentication. ...
When a client collects the loginId and password for the user it
should not normalize them in any manner. It also should not
prevent the user from entering certain characters as the AIM
name space is constantly changing. For example, currently the
AIM name space is ASCII based, but in the future that may
change. In general, the client should not perform input
checking and instead allow the backend to reject bad values.
which also suggests not assuming ASCII.
So use ENC_UTF_8 in most cases.
For actual messages, it says:
An IM can be encoded in the following different forms:
Name Value Notes
ASCII 0 ANSI ASCII -- ISO 646
UNICODE 2 ISO 10646.USC-2 Unicode
LATIN_1 3 ISO 8859-1
so, if that's the case, the dissector should choose beween
ENC_ASCII|ENC_NA, ENC_UCS_2|ENC_appropriate_ENDIAN, and
ENC_ISO_8859_1|ENC_NA.
Use tvb_get_string_enc() with an encoding rather than tvb_get_string().
svn path=/trunk/; revision=54908
XXX - if we supported various MacXXX character encodings, we could use
those; that might require a preference to specify the encoding.
svn path=/trunk/; revision=54906
v1.1: Personal Information Exchange Syntax:
http://www.emc.com/emc-plus/rsa-labs/pkcs/files/h11301-wp-pkcs-12v1-1-personal-information-exchange-syntax.pdf
"When password integrity mode is used to protect a PFX PDU, a password
and salt are used to derive a MAC key. As with password privacy mode,
the password is a Unicode string, and the salt is a byte string."
So, not having found any other references to salts as text strings, copy
it with tvb_memdup(), not tvb_get_string().
svn path=/trunk/; revision=54893
as a string if every byte in it is a printable ASCII character, it's
ASCII. Use tvb_get_string_enc() with an appropriate encoding.
svn path=/trunk/; revision=54889
willing to read or that's bigger than will fit in the file format;
instead, report an error.
For the "I can't write a packet of that type in that file type" error,
report the file type in question.
svn path=/trunk/; revision=54882
better.
We don't need eventlog_get_unicode_string_length() in the eventlog
dissector, either - tvb_unicode_strsize() does the job just as well.
svn path=/trunk/; revision=54874
the only reason not to check it is if we've already gotten a write error
and another write error would be superfluous (either "you got two of the
same error" or "you got an I/O error *and* you ran out of disk
space/disk quota" is of limited interest).
Discard the return value of wtap_dump_close() in the case where we've
already gotten a write error, in the hopes of squelching a Coverity
warning.
svn path=/trunk/; revision=54872
- "Once-only" test not needed in proto_reg_handoff..();
- Set COL_PROTOCOL, clear COL_INFO at the begining of the dissector
before fetching data from the tvb;
- Use tvb_reported_length;
- Use col_set_str/col_append_str where appropriate;
- Zigbee --> lwm;
- Fix typo;
- Reformat some whitespace for consistency.
ToDo:
- Review use of col_...() and expert...() under 'if (tree)';
- Review use of col_clear(..., COL_INFO) after text already added to COL_INFO;
- Review certain tvb fetches to ensure no fetches using a negative offset;
svn path=/trunk/; revision=54871
UTF-8 strings.
Add that mapping for null-terminated ASCII strings.
Factor out some common parts of comments about string routines, and
clean up some other comments.
svn path=/trunk/; revision=54868
Guy Harris