Ethereal-dev: Re: SV: [Ethereal-dev] New dissector for content type multipart/mixed
On Jan 9, 2004, at 4:47 PM, Anders Broman wrote:
packet-multipart_mixed.c:146:60: warning: multi-character character
constant
Not fixed as I'm unshure how the line would end when it's unquoted
' ' CRLF or .. help appreciated.
The problem has nothing to do with that; the problem is that it should
be '\t', not '/t'.
packet-multipart_mixed.c: In function `dissect_multipart_mixed':
packet-multipart_mixed.c:126: warning: unused variable `next_offset'
packet-multipart_mixed.c:129: warning: unused variable `found_match'
packet-multipart_mixed.c: In function `dissect_header_and_body':
packet-multipart_mixed.c:248: warning: `found_match' might be used
uninitialized in this function
Fixed I hope as the don't show up on my box.
I'll see how that works.
Also, it's using "tvb_offset_exists()" in the main loop; that will
stop
at the end of the captured data, rather than the end of the real data
-
it should continue to the end of the real data, so that it throws the
appropriate exception for short captures.
Well this dissector gets handed the data in a tvb by the previous
Dissector and the Content-lenght isn't known .. or am I missing
something?
You're missing something. A tvbuff has a data length, which represents
the actual amount of data in it, *and* a reported length, which is, in
effect, how much data would have been in it had the capture not been
done with a snapshot length that cut the captured packet short.
The only time one should check whether data is really in a tvbuff is if
you're doing something such as checking whether a packet begins with
some value such as "FOO:" in something such as a heuristic dissector.
When processing the data in a packet, or reporting the length of the
data in a packet, a dissector should use the reported length.
Currently, the data length is "what's left of the captured data" and
the reported length is "what's left of what was reported to be there
before the packet was cut off"; if packet data was cut off, they're
different. The SIP dissector *should* process the Content-Length
header and use it if present, in the same way that the HTTP dissector
does (and should also probably do the same reassembly stuff that the
HTTP and RTSP dissectors do).
As for the short names or not I was thinking that the likely hood of
'c='
as the first two chars on a line turning up in the header in a HTTP
message
is slim?
Possibly, but it might still be cleaner to do different checks for
non-SIP data.
The case sensitive checking is copied from the SIP dissector, off hand
I can't remember which parts are case sensitive and which are not
according
to the RFC. Can we check it in as it is for now and I'll check the
spec's
later, and send in a fix if needed ?
I'm not sure what Olivier's talking about there - the checking is
copied from the SIP dissector, but the SIP dissector and the
multipart/mixed dissector are both using "tvb_strncaseeql()", which
does a case-INsensitive comparison (the "case" means
"case-insensitive", not "case-sensitive", along the lines of "strcmp()"
vs. "strcasecmp()" on some UNIXes).
