as errors:
/home/jmayer/work/wireshark/svn/trunk/epan/dissectors/packet-dcerpc-mapi.c: In function ‘mapi_dissect_struct_Release_req’:
/home/jmayer/work/wireshark/svn/trunk/epan/dissectors/packet-dcerpc-mapi.c:8592:14: error: variable ‘tree’ set but not used [-Werror=unused-but-set-variable]
/home/jmayer/work/wireshark/svn/trunk/epan/dissectors/packet-dcerpc-mapi.c: In function ‘mapi_dissect_struct_Release_repl’:
/home/jmayer/work/wireshark/svn/trunk/epan/dissectors/packet-dcerpc-mapi.c:8617:14: error: variable ‘tree’ set but not used [-Werror=unused-but-set-variable]
/home/jmayer/work/wireshark/svn/trunk/epan/dissectors/packet-dcerpc-mapi.c: In function ‘mapi_dissect_struct_RecipSMTP’:
/home/jmayer/work/wireshark/svn/trunk/epan/dissectors/packet-dcerpc-mapi.c:8848:14: error: variable ‘tree’ set but not used [-Werror=unused-but-set-variable]
svn path=/trunk/; revision=39965
to return a pointer to the merge_in_file_t that got the error. Set *err
to 0 on success and an error code on an err, treat a null return as an
EOF indication, and if we don't get a null return check for a non-zero
error code and treat that as an I/O error.
svn path=/trunk/; revision=39964
loop, otherwise you get stuck in an infinite loop.
(Where in RFC 3261 does it mention the use of commas in URI parameters?)
Should fix bug 6598.
svn path=/trunk/; revision=39952
type" when writing out a capture file (i.e., writing a
per-packet-encapsulation capture to a file type that supports it but
doesn't support one of the packet's encapsulations), report the packet
number and, when doing this in a merge operation, report the file from
which it came.
When reporting "sorry, that file can't be written to a file of that
type, period", show the file type rather than the input file link-layer
type that causes the problem. (We could show both. We could be
*really* ambitious and iterate through all possible file types and show
the ones that will or at least might work....)
file_write_error_message() is documented as handling only UNIX-style
errnos, and libwireshark should be usable without libwiretap, so leave
it up to its callers to handle Wiretap errors such as
WTAP_ERR_SHORT_WRITE.
Clean up indentation.
svn path=/trunk/; revision=39949
:~/wireshark/tools$ ../idl2wrs ../idl/cosnaming.idl > ../plugins/giop/packet-cosnaming.c
:~/wireshark/tools$ ../idl2wrs ../idl/coseventcomm.idl > ../plugins/giop/packet-coseventcomm.c
:~/wireshark/tools$ ../idl2wrs ../idl/parlay/Parlay.idl > ../plugins/giop/packet-parlay.c
:~/wireshark/tools$ ../idl2wrs ../idl/tango.idl > ../plugins/giop/packet-tango.c
For packet-cosnaming.c, only some white return change
For packet-parley.c, lot of change but only the functions is not in the same order...?! (Order change in 17911)
svn path=/trunk/; revision=39932
Does wireshark-gtk2\plugins\1.7.1-SVN-39918 specify a file name
or directory name on the target
(F = file, D = directory)?
svn path=/trunk/; revision=39922
With Subversion 1.7, the working copy metada storage as changed (see
http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng for details).
As a consequence, the file .svn/entries is no more updated and under Windows
the svnversion.h is no more regenerated (unless explicitely removed).
The attached patch fixes this issue so as to also check the .svn/wc.db file
date in the makefile rule.
Note that wc.db file must be checked before entries file as an upgrade of an
existing repository from subversion 1.6 to 1.7 leave an old entries file around
(that is no more updated).
In Makefile.am file, the svnversion.h file generation seems to be
systematically forced. So I guess Linux/Mac boxes are not impacted.
svn path=/trunk/; revision=39910