When you try to push to gerrit it should generate a change id that you can
edit into your commit message.
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: http
On Wed, 2016-02-10 at 10:46 -0500, Michael McConville wrote:
> Signed overflow is undefined, so the overflow check below is
> technically
> meaningless. Because we're only checking whether an increment will
> overflow, we can compare j to G_MAXINT instead.
>
This is an important fix. The compiler
On 09/08/14 12:51, Toralf Förster wrote:
> My question is rather, whether it is mandatory to register at one of
> the big IT players or if an email address would be sufficient.
You don't need to register at "one of the big IT players", I think that
Wireshark gerrit is set up to accept any OpenID p
On 04/08/14 11:25, Toralf Förster wrote:
> I developer pointed me to http://code.wireshark.org/review - but I do not
> have an OpenID nor I have an account listed here :
> http://openid.net/get-an-openid/ And I do not own a home page.
>
> Any chance to participate in WS under this circumstances ?
On 25/07/14 03:01, darkjames...@darkjames.pl wrote:
> Hi,
>
> On Thu, Jul 24, 2014 at 04:35:07PM -0400, Kevin Cox wrote:
>> 2: Change everything.
>> Pros:
>> - Full compiler error checking and type safety.
>> Cons:
>> - Hard
>> - May change dissector
On 24/07/14 16:38, Evan Huus wrote:
>
> We are usually not afraid of breaking API changes (whether that's a good
> thing or not is debatable, but it's true) so probably solution 2 if
> somebody wants to tackle it :)
>
I others agree I will start by just changing the extended value string
functio
Hello All,
While working on the new Ceph dissector I made a mistake using
value_string_ext (herein evs) where I declared them 'const' which was
causing an error when they were put in a read-only segment of the
executable.
Thankfully Bill Meier was able to figure out why it was crashing on his
sys
On 24/07/14 12:54, Kevin Cox wrote:
> On 24/07/14 12:36, Joerg Mayer wrote:
>> On Thu, Jul 24, 2014 at 11:58:51AM -0400, Bill Meier wrote:
>>> While reviewing the new ceph dissector [1], two issues cropped up
>>> where my build on Linux (using Autofoo) apparently gave d
On 24/07/14 12:36, Joerg Mayer wrote:
> On Thu, Jul 24, 2014 at 11:58:51AM -0400, Bill Meier wrote:
>> While reviewing the new ceph dissector [1], two issues cropped up
>> where my build on Linux (using Autofoo) apparently gave different
>> results then a build by Kevin Cox
On 16/06/14 16:17, wsgd wrote:
> Le 15/06/2014 16:51, Richard Sharpe a écrit :
>>
> Because :
> - I do not anything about git
> - I do not not know what is the whole thing
> - I do not not know want the whole thing :)
> - I only want source code corresponding to the official release 1.12 and
> be a
On 04/06/14 12:18, Evan Huus wrote:
> If you're going to have a data subfield that is filterable, why do you
> need the parent item to be filterable as well? Wouldn't they have the
> exact same thing? Most Wireshark dissectors do not make the intermediate
> tree items filterable, only the "bottom"-
On 04/06/14 10:24, Anders Broman wrote:
> One option is to read the bytes from the tvb to a buffer manipulate the bytes
> and make a new tvb with the manipulated bytes in the buffer and then dissect
> that new tvb.
> Like uncompressing something and then dissect the content of the
> uncompresse
Hello,
Please forgive me if I am missing something obvious. I am trying to add
some computed bytes to the proto_tree and wish them to be filterable.
However, the proto_tree_add_bytes and similar functions only have one
length argument that is used for both the tvb and the value pointer.
The probl
Hello,
I have just posted a WIP patch[0] for the Ceph[1] dissector I am working
on. There is still a lot of work to be done but I was hoping that I can
get an initial review to ensure I am on the right track.
[0] https://code.wireshark.org/review/1889
[1] http://ceph.com/
I have implemented a c
On May 22, 2014 4:57 AM, "Vishnu Bhatt" wrote:
>
>
> One more thing, does it matter that the .so file of mine should be placed
in the same machine (32 or 64bit) in which it was compiled?
>
The architecture of the plugin must match that of wireshark.
It is possible to run a 32 bit wireshark on a
On 13/05/14 15:06, Alexis La Goutte wrote:
> The better will be add 64bits bitfields... ;-)
>
Unless I am missing something a 64 bit bitfield can't be used because
the bitmask field of header_field_info is only 32 bits wide.
Cheers,
Kevin
signature.asc
Description: OpenPGP digital signature
_
Hello,
I was attempting to dissect a 64 bit bitfield and was wondering what the
best/preferred method was. I saw a question on ask.wireshark.org[0]
which had a single answer the said to use a text field.
[0]
http://ask.wireshark.org/questions/20599/dissecting-bitfields-larger-than-32-bits
I was
Hello,
Forgive me if this has been asked before but I can't find any resources
about the advantages/disadvantages of plugin dissectors and the ideal
cases for each.
So far I have gathered that plugin dissectors are "easiest to write
initially"[0] while builtin dissectors load slightly faster.
[0
On 22/03/14 12:34, Toralf Förster wrote:
> On 03/22/2014 05:15 PM, Hadriel Kaplan wrote:
>
> b/c for gerrit I'd need an OpenId which I do not have (and just
> getting an account as easy as for bugzilla is not an option there, or ?)
>
There are many free OpenID providers[1] you may already have o
19 matches
Mail list logo
