Re: [Wireshark-dev] Bug 8416 - remove C++ incompatibilities from packet-pw-atm.c

2013-02-28 Thread Anders Broman 

Evan Huus skrev 2013-03-01 03:50:

On Thu, Feb 28, 2013 at 9:39 PM, Ed Beroset  wrote:

Jaap Keuter 


What I would like to see is the abolishment of the pwc_packet_properties_t type
altogether. This is _not_ an enum.

I agree, and have come across another such "enum abuse" instance that may be 
harder to address. Specifically, in the header file gmessages.h there is a similar 
typedef enum called GLogLevelFlags which is also intended to provide names for bitflags 
rather than actually enumerate.  This construct is used a number of places in the 
Wireshark code (such as line 3169 of plugins/asn1/packet-asn1.c).  Adding a cast quiets 
the compiler, but is there a better way that doesn't require rewriting glib-2.0?

 mylogh = g_log_set_handler (NULL, GLogLevelFlags(G_LOG_LEVEL_MASK | 
G_LOG_FLAG_FATAL
 | G_LOG_FLAG_RECURSION), 
my_log_handler, NULL);

Ed

Not off the top of my head. Fortunately, the vast majority of
G_LOG_LEVEL_* uses are in g_log calls that shouldn't cause problems -
there are only five or six cases I noticed where we were doing
bit-fieldy things with them.
On a side note, does any one know how to regenerate the PIDL dissectors? 
there is a

potential fix in the template waiting for regeneration.

___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe



___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Bug 8416 - remove C++ incompatibilities from packet-pw-atm.c

2013-02-28 Thread Evan Huus 
On Thu, Feb 28, 2013 at 9:39 PM, Ed Beroset  wrote:
> Jaap Keuter 
>
>>
>>What I would like to see is the abolishment of the pwc_packet_properties_t 
>>type
>>altogether. This is _not_ an enum.
>
> I agree, and have come across another such "enum abuse" instance that may be 
> harder to address. Specifically, in the header file gmessages.h there is a 
> similar typedef enum called GLogLevelFlags which is also intended to provide 
> names for bitflags rather than actually enumerate.  This construct is used a 
> number of places in the Wireshark code (such as line 3169 of 
> plugins/asn1/packet-asn1.c).  Adding a cast quiets the compiler, but is there 
> a better way that doesn't require rewriting glib-2.0?
>
> mylogh = g_log_set_handler (NULL, GLogLevelFlags(G_LOG_LEVEL_MASK | 
> G_LOG_FLAG_FATAL
> | G_LOG_FLAG_RECURSION), 
> my_log_handler, NULL);
>
> Ed

Not off the top of my head. Fortunately, the vast majority of
G_LOG_LEVEL_* uses are in g_log calls that shouldn't cause problems -
there are only five or six cases I noticed where we were doing
bit-fieldy things with them.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Bug 8416 - remove C++ incompatibilities from packet-pw-atm.c

2013-02-28 Thread Ed Beroset 
Jaap Keuter 

>
>What I would like to see is the abolishment of the pwc_packet_properties_t type
>altogether. This is _not_ an enum.

I agree, and have come across another such "enum abuse" instance that may be 
harder to address. Specifically, in the header file gmessages.h there is a 
similar typedef enum called GLogLevelFlags which is also intended to provide 
names for bitflags rather than actually enumerate.  This construct is used a 
number of places in the Wireshark code (such as line 3169 of 
plugins/asn1/packet-asn1.c).  Adding a cast quiets the compiler, but is there a 
better way that doesn't require rewriting glib-2.0?

mylogh = g_log_set_handler (NULL, GLogLevelFlags(G_LOG_LEVEL_MASK | 
G_LOG_FLAG_FATAL
| G_LOG_FLAG_RECURSION), 
my_log_handler, NULL);

Ed
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Bug 8416 - remove C++ incompatibilities from packet-pw-atm.c

2013-02-28 Thread Evan Huus 
Hi Ed,

I agree with Jaap regarding the replacing of the enum, but that's not
your fault, and I suspect the majority of the other enum-conversion
cases will not have this issue.

The rest of the patch looks fine to me, but I'm out of time for a
proper review+checkin right now.

Cheers,
Evan

On Thu, Feb 28, 2013 at 5:03 PM, Jaap Keuter  wrote:
> Hi,
>
> I already had my reservations against the construction of the PW dissectors, 
> and
> this only adds to it.
>
> What I would like to see is the abolishment of the pwc_packet_properties_t 
> type
> altogether. This is _not_ an enum.
>
> typedef enum {
> PWC_CW_BAD_BITS03   = 1 << 0
> ,PWC_CW_BAD_PAYLEN_LT_0 = 1 << 1
> ,PWC_CW_BAD_PAYLEN_GT_PACKET= 1 << 2
> ,PWC_CW_BAD_LEN_MUST_BE_0   = 1 << 3
> ,PWC_CW_BAD_FRAG= 1 << 4
> ,PWC_CW_BAD_RSV = 1 << 5
> ,PWC_CW_BAD_FLAGS   = 1 << 8
> ,PWC_CW_BAD_PAYLEN_LE_0 = 1 << 9
> ,PWC_CW_BAD_PADDING_NE_0= 1 << 10
> ,PWC_ANYOF_CW_BAD   = PWC_CW_BAD_BITS03
> + PWC_CW_BAD_PAYLEN_LT_0
> + PWC_CW_BAD_PAYLEN_GT_PACKET
> + PWC_CW_BAD_LEN_MUST_BE_0
> + PWC_CW_BAD_FRAG
> + PWC_CW_BAD_RSV
> + PWC_CW_BAD_FLAGS
> + PWC_CW_BAD_PAYLEN_LE_0
> + PWC_CW_BAD_PADDING_NE_0
> ,PWC_CW_SUSPECT_LM  = 1 << 6
> ,PWC_ANYOF_CW_SUSPECT   = PWC_CW_SUSPECT_LM
> ,PWC_PAY_SIZE_BAD   = 1 << 7
> }
> pwc_packet_properties_t;
>
> It's replacement is a list of #define's or const int's (to stay in C++ realm)
>
> #define PWC_CW_BAD_BITS03   (1 << 0)
> #define PWC_CW_BAD_PAYLEN_LT_0  (1 << 1)
> #define PWC_CW_BAD_PAYLEN_GT_PACKET (1 << 2)
> #define PWC_CW_BAD_LEN_MUST_BE_0(1 << 3)
> #define PWC_CW_BAD_FRAG (1 << 4)
> #define PWC_CW_BAD_RSV  (1 << 5)
> #define PWC_CW_SUSPECT_LM   (1 << 6)
> #define PWC_PAY_SIZE_BAD(1 << 7)
> #define PWC_CW_BAD_FLAGS(1 << 8)
> #define PWC_CW_BAD_PAYLEN_LE_0  (1 << 9)
> #define PWC_CW_BAD_PADDING_NE_0 (1 << 10)
> #define PWC_ANYOF_CW_BAD(PWC_CW_BAD_BITS03 |
>  PWC_CW_BAD_PAYLEN_LT_0 |
>  PWC_CW_BAD_PAYLEN_GT_PACKET |
>  PWC_CW_BAD_LEN_MUST_BE_0 |
>  PWC_CW_BAD_FRAG |
>  PWC_CW_BAD_RSV |
>  PWC_CW_BAD_FLAGS |
>  PWC_CW_BAD_PAYLEN_LE_0 |
>  PWC_CW_BAD_PADDING_NE_0)
> #define PWC_ANYOF_CW_SUSPECTPWC_CW_SUSPECT_LM
>
>
> This would impact packet-pw-cesopsn.c, packet-pw-satop.c in a similar way as 
> it
> did packet-pw-atm.c
>
> Thanks,
> Jaap
>
>
> On 02/28/2013 09:57 PM, Ed Beroset wrote:
>> As mentioned in the subject line, I've added Bug 8416 - "remove C++ 
>> incompatibilities from packet-pw-atm.c" with the associated patch.  Doing a 
>> little forensic work on the C++ incompatibilities still present in the code 
>> base, here are the types of issues of the 4919 "c++-incompat" lines in a 
>> compilation of the latest source using gcc on a Linux box (Fedora 17) 
>> (before this patch):
>>
>> type  count   percent
>> implicit_casts401381.58%
>> keyword_use   634 12.89%
>> enum_conversion   197 4.00%
>> uninit_const  7   0.14%
>> field_typedef 5   0.10%
>> special_operator  3   0.06%
>> incompat_ptr  2   0.04%
>> other 58  1.18%
>>
>> It's clear that the vast majority of these (over 98%) are of only three 
>> different kinds which are mostly trivial fixes.  I do want to point out, 
>> however, that the way I chose to resolve the enum_conversion complaint was 
>> to change the type of one member of a struct from an enum type to an int.  
>> The longer version of the rationale is in the bug report.  If we find this 
>> kind of patch acceptable, and desirable, I'll do more.
>>
>> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8416
>>
>> Ed
>>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wi

Re: [Wireshark-dev] Bug 8416 - remove C++ incompatibilities from packet-pw-atm.c

2013-02-28 Thread Jaap Keuter 
Hi,

I already had my reservations against the construction of the PW dissectors, and
this only adds to it.

What I would like to see is the abolishment of the pwc_packet_properties_t type
altogether. This is _not_ an enum.

typedef enum {
PWC_CW_BAD_BITS03   = 1 << 0
,PWC_CW_BAD_PAYLEN_LT_0 = 1 << 1
,PWC_CW_BAD_PAYLEN_GT_PACKET= 1 << 2
,PWC_CW_BAD_LEN_MUST_BE_0   = 1 << 3
,PWC_CW_BAD_FRAG= 1 << 4
,PWC_CW_BAD_RSV = 1 << 5
,PWC_CW_BAD_FLAGS   = 1 << 8
,PWC_CW_BAD_PAYLEN_LE_0 = 1 << 9
,PWC_CW_BAD_PADDING_NE_0= 1 << 10
,PWC_ANYOF_CW_BAD   = PWC_CW_BAD_BITS03
+ PWC_CW_BAD_PAYLEN_LT_0
+ PWC_CW_BAD_PAYLEN_GT_PACKET
+ PWC_CW_BAD_LEN_MUST_BE_0
+ PWC_CW_BAD_FRAG
+ PWC_CW_BAD_RSV
+ PWC_CW_BAD_FLAGS
+ PWC_CW_BAD_PAYLEN_LE_0
+ PWC_CW_BAD_PADDING_NE_0
,PWC_CW_SUSPECT_LM  = 1 << 6
,PWC_ANYOF_CW_SUSPECT   = PWC_CW_SUSPECT_LM
,PWC_PAY_SIZE_BAD   = 1 << 7
}
pwc_packet_properties_t;

It's replacement is a list of #define's or const int's (to stay in C++ realm)

#define PWC_CW_BAD_BITS03   (1 << 0)
#define PWC_CW_BAD_PAYLEN_LT_0  (1 << 1)
#define PWC_CW_BAD_PAYLEN_GT_PACKET (1 << 2)
#define PWC_CW_BAD_LEN_MUST_BE_0(1 << 3)
#define PWC_CW_BAD_FRAG (1 << 4)
#define PWC_CW_BAD_RSV  (1 << 5)
#define PWC_CW_SUSPECT_LM   (1 << 6)
#define PWC_PAY_SIZE_BAD(1 << 7)
#define PWC_CW_BAD_FLAGS(1 << 8)
#define PWC_CW_BAD_PAYLEN_LE_0  (1 << 9)
#define PWC_CW_BAD_PADDING_NE_0 (1 << 10)
#define PWC_ANYOF_CW_BAD(PWC_CW_BAD_BITS03 |
 PWC_CW_BAD_PAYLEN_LT_0 |
 PWC_CW_BAD_PAYLEN_GT_PACKET |
 PWC_CW_BAD_LEN_MUST_BE_0 |
 PWC_CW_BAD_FRAG |
 PWC_CW_BAD_RSV |
 PWC_CW_BAD_FLAGS |
 PWC_CW_BAD_PAYLEN_LE_0 |
 PWC_CW_BAD_PADDING_NE_0)
#define PWC_ANYOF_CW_SUSPECTPWC_CW_SUSPECT_LM


This would impact packet-pw-cesopsn.c, packet-pw-satop.c in a similar way as it
did packet-pw-atm.c

Thanks,
Jaap


On 02/28/2013 09:57 PM, Ed Beroset wrote:
> As mentioned in the subject line, I've added Bug 8416 - "remove C++ 
> incompatibilities from packet-pw-atm.c" with the associated patch.  Doing a 
> little forensic work on the C++ incompatibilities still present in the code 
> base, here are the types of issues of the 4919 "c++-incompat" lines in a 
> compilation of the latest source using gcc on a Linux box (Fedora 17) (before 
> this patch):
> 
> type  count   percent
> implicit_casts401381.58%
> keyword_use   634 12.89%
> enum_conversion   197 4.00%
> uninit_const  7   0.14%
> field_typedef 5   0.10%
> special_operator  3   0.06%
> incompat_ptr  2   0.04%
> other 58  1.18%
> 
> It's clear that the vast majority of these (over 98%) are of only three 
> different kinds which are mostly trivial fixes.  I do want to point out, 
> however, that the way I chose to resolve the enum_conversion complaint was to 
> change the type of one member of a struct from an enum type to an int.  The 
> longer version of the rationale is in the bug report.  If we find this kind 
> of patch acceptable, and desirable, I'll do more.  
> 
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8416
> 
> Ed
> 

___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Windows buildbot breakage

2013-02-28 Thread Bálint Réczey 
The commit converting libwiretap broke the Windows builds.
I'm fixing the symbol exporting related build problems right now, but
it seems my change
also triggered additional compile-time checks which revealed existing errors.

Cheers,
Balint


2013/2/28 Bálint Réczey :
> Hi Anders,
>
> I have fixed it now, I just wanted to run a full build to test fixing 
> distcheck.
>
> Cheers,
> Balint
>
> 2013/2/28 Anders Broman :
>> Hi,
>> Shouldn't ws_symbol_export.h be added to makefile.common ?
>> Regards
>> Anders
>>
>> -Original Message-
>> From: wireshark-commits-boun...@wireshark.org 
>> [mailto:wireshark-commits-boun...@wireshark.org] On Behalf Of 
>> rbal...@wireshark.org
>> Sent: den 28 februari 2013 15:10
>> To: wireshark-comm...@wireshark.org
>> Subject: [Wireshark-commits] rev 47938: /trunk/ /trunk/debian/: 
>> wireshark-dev.header-files /trunk/: CMakeLists.txt configure.ac 
>> ws_symbol_export.h /trunk/wsutil/: CMakeLists.txt Makefile.am Makefile.nmake 
>> crash_info.h crc10.h crc11.h ...
>>
>> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=47938
>>
>> User: rbalint
>> Date: 2013/02/28 06:09 AM
>>
>> Log:
>>  Export libwsutil symbols using WS_DLL_PUBLIC define
>>
>>  This change replaces *.def and *.sym file usage following the  guideline at 
>> http://gcc.gnu.org/wiki/Visibility
>>
>> Directory: /trunk/debian/
>>   ChangesPath  Action
>>   +1 -0  wireshark-dev.header-filesModified
>>
>> Directory: /trunk/
>>   ChangesPath  Action
>>   +8 -1  CMakeLists.txtModified
>>   +12 -0 configure.ac  Modified
>>   +54 -0 ws_symbol_export.hAdded
>>
>> Directory: /trunk/wsutil/
>>   ChangesPath   Action
>>   +5 -1  CMakeLists.txt Modified
>>   +6 -25 Makefile.amModified
>>   +3 -3  Makefile.nmake Modified
>>   +3 -0  crash_info.h   Modified
>>   +3 -0  crc10.hModified
>>   +3 -0  crc11.hModified
>>   +4 -0  crc16-plain.h  Modified
>>
>>
>> (17 files not shown)
>> ___
>> Sent via:Wireshark-commits mailing list 
>> Archives:http://www.wireshark.org/lists/wireshark-commits
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits
>>  
>> mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Bug 8416 - remove C++ incompatibilities from packet-pw-atm.c

2013-02-28 Thread Ed Beroset 
As mentioned in the subject line, I've added Bug 8416 - "remove C++ 
incompatibilities from packet-pw-atm.c" with the associated patch.  Doing a 
little forensic work on the C++ incompatibilities still present in the code 
base, here are the types of issues of the 4919 "c++-incompat" lines in a 
compilation of the latest source using gcc on a Linux box (Fedora 17) (before 
this patch):

typecount   percent
implicit_casts  401381.58%
keyword_use 634 12.89%
enum_conversion 197 4.00%
uninit_const7   0.14%
field_typedef   5   0.10%
special_operator3   0.06%
incompat_ptr2   0.04%
other   58  1.18%

It's clear that the vast majority of these (over 98%) are of only three 
different kinds which are mostly trivial fixes.  I do want to point out, 
however, that the way I chose to resolve the enum_conversion complaint was to 
change the type of one member of a struct from an enum type to an int.  The 
longer version of the rationale is in the bug report.  If we find this kind of 
patch acceptable, and desirable, I'll do more.  

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8416

Ed



___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 47943: /trunk-1.8/epan/dissectors/ /trunk-1.8/epan/dissectors/: packet-fcp.c

2013-02-28 Thread Evan Huus 
The issue I think would be that when the release-trunk buildbots get
upgraded to newer compilers (with more warnings), we would start
getting build-failures that didn't exist when 1.8 etc. were actually
trunk.

Not necessarily a huge issue, assuming the builbots aren't updated all
that frequently.

On Thu, Feb 28, 2013 at 12:37 PM, Jeff Morriss
 wrote:
> morr...@wireshark.org wrote:
>>
>> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=47943
>>
>> User: morriss
>> Date: 2013/02/28 08:57 AM
>>
>> Log:
>>  Copy over from trunk (in order to solve warnings introduced with r46464
>> and
>>  backported to trunk-1.8 with r46672):
>
>
> Is it possible/would it make sense to have the release-trunk buildbots do
> their configure's with "--enable-warnings-as-errors" so we can detect
> warnings being back-ported to those trunks (while not enabling
> warnings-as-errors by default--for users--of course)?
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] new dissector - dynamic value string table?

2013-02-28 Thread Jakub Zawadzki 
On Thu, Feb 28, 2013 at 12:29:05PM +0200, michal.labed...@tieto.com wrote:
> value = val_to_str_const(vendor_key, vendor_xxx_specific_vals, 
> unknown_key);
> if (value == unknown_key) {

  value = match_strval(vendor_key, vendor_xxx_specific_vals);
  if (value == NULL) {
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 47943: /trunk-1.8/epan/dissectors/ /trunk-1.8/epan/dissectors/: packet-fcp.c

2013-02-28 Thread Jeff Morriss 

morr...@wireshark.org wrote:

http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=47943

User: morriss
Date: 2013/02/28 08:57 AM

Log:
 Copy over from trunk (in order to solve warnings introduced with r46464 and
 backported to trunk-1.8 with r46672):


Is it possible/would it make sense to have the release-trunk buildbots 
do their configure's with "--enable-warnings-as-errors" so we can detect 
warnings being back-ported to those trunks (while not enabling 
warnings-as-errors by default--for users--of course)?


___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] new dissector - dynamic value string table?

2013-02-28 Thread Max Baker 
Michal,

Thank you very much for the comprehensive example.  I'll give this a try.

Cheers,
-m
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] FW: [Wireshark-commits] rev 47938: /trunk/ /trunk/debian/: wireshark-dev.header-files /trunk/: CMakeLists.txt configure.ac ws_symbol_export.h /trunk/wsutil/: CMakeLists.txt Makefil

2013-02-28 Thread Bálint Réczey 
Hi Anders,

I have fixed it now, I just wanted to run a full build to test fixing distcheck.

Cheers,
Balint

2013/2/28 Anders Broman :
> Hi,
> Shouldn't ws_symbol_export.h be added to makefile.common ?
> Regards
> Anders
>
> -Original Message-
> From: wireshark-commits-boun...@wireshark.org 
> [mailto:wireshark-commits-boun...@wireshark.org] On Behalf Of 
> rbal...@wireshark.org
> Sent: den 28 februari 2013 15:10
> To: wireshark-comm...@wireshark.org
> Subject: [Wireshark-commits] rev 47938: /trunk/ /trunk/debian/: 
> wireshark-dev.header-files /trunk/: CMakeLists.txt configure.ac 
> ws_symbol_export.h /trunk/wsutil/: CMakeLists.txt Makefile.am Makefile.nmake 
> crash_info.h crc10.h crc11.h ...
>
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=47938
>
> User: rbalint
> Date: 2013/02/28 06:09 AM
>
> Log:
>  Export libwsutil symbols using WS_DLL_PUBLIC define
>
>  This change replaces *.def and *.sym file usage following the  guideline at 
> http://gcc.gnu.org/wiki/Visibility
>
> Directory: /trunk/debian/
>   ChangesPath  Action
>   +1 -0  wireshark-dev.header-filesModified
>
> Directory: /trunk/
>   ChangesPath  Action
>   +8 -1  CMakeLists.txtModified
>   +12 -0 configure.ac  Modified
>   +54 -0 ws_symbol_export.hAdded
>
> Directory: /trunk/wsutil/
>   ChangesPath   Action
>   +5 -1  CMakeLists.txt Modified
>   +6 -25 Makefile.amModified
>   +3 -3  Makefile.nmake Modified
>   +3 -0  crash_info.h   Modified
>   +3 -0  crc10.hModified
>   +3 -0  crc11.hModified
>   +4 -0  crc16-plain.h  Modified
>
>
> (17 files not shown)
> ___
> Sent via:Wireshark-commits mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-commits
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits
>  
> mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Small typo in str_util.c

2013-02-28 Thread Jeff Morriss 

Anders Broman wrote:

Hi,

Str_util.c prints I64 instead of the value due to a couple of typos.


Hmm, those typos are actually r47934:


 str_util.c: Although the glib documentation doesn't explicitly say so,
 it looks like the thousands grouping (') modifier is supported so use it
 in format_size.


I was going to comment that I /suspect/ the reason it looks like it 
works is that Gerald's system happens to be running a GNU sprintf() on 
the backend.


I reverted it in r47940.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] FW: [Wireshark-commits] rev 47938: /trunk/ /trunk/debian/: wireshark-dev.header-files /trunk/: CMakeLists.txt configure.ac ws_symbol_export.h /trunk/wsutil/: CMakeLists.txt Makefile.am

2013-02-28 Thread Anders Broman 
Hi,
Shouldn't ws_symbol_export.h be added to makefile.common ?
Regards
Anders

-Original Message-
From: wireshark-commits-boun...@wireshark.org 
[mailto:wireshark-commits-boun...@wireshark.org] On Behalf Of 
rbal...@wireshark.org
Sent: den 28 februari 2013 15:10
To: wireshark-comm...@wireshark.org
Subject: [Wireshark-commits] rev 47938: /trunk/ /trunk/debian/: 
wireshark-dev.header-files /trunk/: CMakeLists.txt configure.ac 
ws_symbol_export.h /trunk/wsutil/: CMakeLists.txt Makefile.am Makefile.nmake 
crash_info.h crc10.h crc11.h ...

http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=47938

User: rbalint
Date: 2013/02/28 06:09 AM

Log:
 Export libwsutil symbols using WS_DLL_PUBLIC define
 
 This change replaces *.def and *.sym file usage following the  guideline at 
http://gcc.gnu.org/wiki/Visibility

Directory: /trunk/debian/
  ChangesPath  Action
  +1 -0  wireshark-dev.header-filesModified

Directory: /trunk/
  ChangesPath  Action
  +8 -1  CMakeLists.txtModified
  +12 -0 configure.ac  Modified
  +54 -0 ws_symbol_export.hAdded

Directory: /trunk/wsutil/
  ChangesPath   Action
  +5 -1  CMakeLists.txt Modified
  +6 -25 Makefile.amModified
  +3 -3  Makefile.nmake Modified
  +3 -0  crash_info.h   Modified
  +3 -0  crc10.hModified
  +3 -0  crc11.hModified
  +4 -0  crc16-plain.h  Modified


(17 files not shown)
___
Sent via:Wireshark-commits mailing list 
Archives:http://www.wireshark.org/lists/wireshark-commits
Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits
 mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Small typo in str_util.c

2013-02-28 Thread Anders Broman 
Hi,
Str_util.c prints I64 instead of the value due to a couple of typos.



str_util.c.patch
Description: str_util.c.patch
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] new dissector - dynamic value string table?

2013-02-28 Thread Michal.Labedzki 
Hi Max,

> On the first question of detecting the camera type, it looks like the
> information I need is captured by packet-usb.c (emem_tree_t
> *device_to_product_table) -- however it's not exported.   I will need to
> add a way of getting access to this tree from the new dissector.

I guess you do not want to export it. Instead, you can extent private_info in 
packet.usb.c for exporting vendor_id/product_id (etc.)  to higher protocol (see 
packet-hci_usb.c).

As I understand correctly you also need to do something like that:
static const value_string vendor_xxx_specific_vals[] = {
{0x0001, "A"},
{0x0401, "B"},
{0x0402, "C"},
{0, NULL}
};

static const value_string generic_vals[] = {
{0x0001, "A"},
{0x0401, "X"},
{0x0555, "O"},
{0, NULL}
};

/*...*/

gchar *unknown_key = "Unknown";
gchar *value;

for (i=0;i http://www.tieto.com / http://www.tieto.pl
---
ASCII: Michal Labedzki
e-mail: michal.labed...@tieto.com
location: Swobodna 1 Street, 50-088 Wrocław, Poland
desk: 5.021
---
Please note: The information contained in this message may be legally 
privileged and confidential and protected from disclosure. If the reader of 
this message is not the intended recipient, you are hereby notified that any 
unauthorised use, distribution or copying of this communication is strictly 
prohibited. If you have received this communication in error, please notify us 
immediately by replying to the message and deleting it from your computer. 
Thank You.
---
Please consider the environment before printing this e-mail.
---
Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Szczecinie, 
ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym Szczecin-Centrum w 
Szczecinie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 
124858. NIP: 8542085557. REGON: 812023656. Kapitał zakładowy: 4 271500 PLN
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] malformed packet

2013-02-28 Thread Lohith HS 

Hi Hadriel,

Thanks for your reply.I will apply your patch.

Thanks,
Lohith

On Thursday 28 February 2013 01:45 PM, Pascal Quantin wrote:
2013/2/28 Hadriel Kaplan >



Wireshark's SIP dissector is throwing an error on the RAck header
field method name.
It shouldn't, because the message's header is correctly formed,
but there's a bug in packet-sip.c:
for case POS_RACK, when it goes to add the method name, it's using
'(int)linelen-sub_value_offset' for the length argument to
proto_tree_add_item(),
but should be using '(int)value_len-sub_value_offset'.

patch:
Index: epan/dissectors/packet-sip.c
===
--- epan/dissectors/packet-sip.c(revision 47899)
+++ epan/dissectors/packet-sip.c(working copy)
@@ -2734,7 +2734,7 @@
{
   
proto_tree_add_item(rack_tree, hf_sip_rack_cseq_method, tvb,
 
  value_offset + sub_value_offset,
-
  (int)linelen-sub_value_offset, ENC_ASCII|ENC_NA);
+
  (int)value_len-sub_value_offset, ENC_ASCII|ENC_NA);

}

break;

Hi Hadriel,

Thanks for the patch! I committed it in revision 47936 and scheduled 
it for backport in 1.8.6 and 1.6.14.


Regards,
Pascal.


On Feb 28, 2013, at 1:21 AM, Lohith HS
mailto:lohith...@globaledgesoft.com>> wrote:

> Hi ,
>
>I am getting malformed packet in SIP message(PRACK) in
wireshark 1.6.7 version.
>But if i see the same capture in 0.9 version ,  there is no
malformed packet issue.
>Pls can anyone tell me what is the issue.i have attached the
capture file.
>
>
> Thanks,
> Lohith
> ___
> Sent via:Wireshark-dev mailing list
mailto:wireshark-dev@wireshark.org>>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org
?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list
mailto:wireshark-dev@wireshark.org>>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org
?subject=unsubscribe




___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] malformed packet

2013-02-28 Thread Pascal Quantin 
2013/2/28 Hadriel Kaplan 

>
> Wireshark's SIP dissector is throwing an error on the RAck header field
> method name.
> It shouldn't, because the message's header is correctly formed, but
> there's a bug in packet-sip.c:
> for case POS_RACK, when it goes to add the method name, it's using
> '(int)linelen-sub_value_offset' for the length argument to
> proto_tree_add_item(),
> but should be using '(int)value_len-sub_value_offset'.
>
> patch:
> Index: epan/dissectors/packet-sip.c
> ===
> --- epan/dissectors/packet-sip.c(revision 47899)
> +++ epan/dissectors/packet-sip.c(working copy)
> @@ -2734,7 +2734,7 @@
> {
>
> proto_tree_add_item(rack_tree, hf_sip_rack_cseq_method, tvb,
>
>   value_offset + sub_value_offset,
> -
>   (int)linelen-sub_value_offset, ENC_ASCII|ENC_NA);
> +
>   (int)value_len-sub_value_offset, ENC_ASCII|ENC_NA);
> }
>
> break;
>
> Hi Hadriel,

Thanks for the patch! I committed it in revision 47936 and scheduled it for
backport in 1.8.6 and 1.6.14.

Regards,
Pascal.


> On Feb 28, 2013, at 1:21 AM, Lohith HS 
> wrote:
>
> > Hi ,
> >
> >I am getting malformed packet in SIP message(PRACK) in wireshark
> 1.6.7 version.
> >But if i see the same capture in 0.9 version ,  there is no malformed
> packet issue.
> >Pls can anyone tell me what is the issue.i have attached the capture
> file.
> >
> >
> > Thanks,
> > Lohith
> >  >___
> > Sent via:Wireshark-dev mailing list 
> > Archives:http://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> > mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe