Re: [Wireshark-dev] Oldest version of VS supported?

[Graham Bloice]

On 24 July 2014 20:02, Graham Bloice  wrote:

> On 24 July 2014 19:06, Graham Bloice  wrote:
>
>> On 24 July 2014 19:03, Pascal Quantin  wrote:
>>
>>>
>>> Le 24 juil. 2014 20:00, "Graham Bloice"  a
>>> écrit :
>>>
>>> >
>>> > On 24 July 2014 18:51, Pascal Quantin 
>>> wrote:
>>> >>
>>> >> Le 24/07/2014 19:39, Joerg Mayer a écrit :
>>> >> > On Thu, Jul 24, 2014 at 06:20:48PM +0100, Graham Bloice wrote:
>>> >> >> On 24 July 2014 18:08, Joerg Mayer  wrote:
>>> >> >>
>>> >> >>> IIRC there was some discussion which versions of VS should still
>>> be
>>> >> >>> supported,
>>> >> >>> but I failed to find it in the archives. So, was there some
>>> consensus
>>> >> >>> which is
>>> >> >>> the oldest version we are going to support with master?
>>> >> >>>
>>> >> >>>
>>> >> >> I brought up the issue of moving to VS2013 for master, and
>>> separately
>>> >> >> dropping info from the (master) docs for earlier than VS2010.
>>> >> >>
>>> >> >> I didn't see any requests for support to build with earlier than
>>> 2010,
>>> >> >> although Guy did wonder about the doc changes, but no real
>>> conclusion was
>>> >> >> reached.
>>> >> >>
>>> >> >> Personally I would make 2013 the minimum supported for master.
>>> >> > Hmm, OK. So we need an updated developer's guide setup section. I
>>> will try
>>> >> > to update my Windows vom 2010 to 2013 and see how it goes - just
>>> have to
>>> >> > find out how to snapshot the VM first ;->
>>> >> > Could you update Makefile.nmake and config.nmake to rip out all the
>>> >> > stuff that deals with older versions? That would make my life with
>>> the
>>> >> > CMake work on Windows somewhat easier  ;-)
>>> >> >
>>> >> > Thanks
>>> >> >Jörg
>>> >> Could not we keep at least VS2010 but change the default to VS2013 (if
>>> >> everybody agree)? I find it a quite drastic change to drop all older
>>> >> compilers suddenly... This is not something we have done in the past.
>>> >>
>>> >
>>> > That was what I was meaning, we would leave support for VS2010, and
>>> fix up whatever is needed for 2012 & 2013.  2013 builds well for me.  The
>>> toolchain in 2013 is a big improvement over 2010.
>>> >
>>> > I think we can make nmake autodetect the version and possibly CMake
>>> too, although that likes to make it's own mind up so needs a command line
>>> switch if you have multiple versions.
>>>
>>> Which make me think that I must upload the MSVC2013 Lua package :)
>>>
>>>
>> The current one builds and runs fine with VS2013, but I don't think I've
>> tried any Lua scripts with it.
>>
>>
> I have two batch files, one for VS2010 and the other for VS2013.  Both are
> set by default for x86 builds, but it shouldn't be too hard to make them
> bit-width agnostic.
>
> For VS2010:
>
> REM Environment setup for Wireshark and VS2010
>
> set CYGWIN=nodosfilewarning
> set WIRESHARK_BASE_DIR=E:\Wireshark
> set WIRESHARK_TARGET_PLATFORM=win32
> set QT5_BASE_DIR=C:\qt\Qt-5.1.1-MSVC2010-win32-ws
>
> set VisualStudioVersion=10.0
>
> set WIRESHARK_VERSION_EXTRA=-GMB
>
>
> and for VS2013:
>
> REM Environment setup for Wireshark and VS2013
>
> set CYGWIN=nodosfilewarning
> set WIRESHARK_BASE_DIR=E:\Wireshark
> set WIRESHARK_TARGET_PLATFORM=win32
> set QT5_BASE_DIR=C:\Qt\Qt5.3.0\5.3\msvc2013
>
> set WIRESHARK_VERSION_EXTRA=-GMB
>
>
> I run these from a "Visual Studio Command Prompt", look in the Start Menu
> for the appropriate "Visual Studio Tools" entry, and in there should be
> some shortcuts.  Using the batch files, no changes are required to the
> sources for a plain vanilla build.
>
>
I forgot to add, for VS2013 you need a newer version of QT, I used 5.3.0.

-- 
Graham Bloice
___
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] Buildbot updates

[Gerald Combs]

I upgraded the fuzz testing buildslave to Ubuntu 14.04. The new version
of scan-build (clang+LLVM 3.4) crashes on packet-parlay.c. We also
jumped from 39 to 47 scan-build issues.

I also installed VS 2013 Professional on each of the Windows buildslaves
(production and Petri Dish). Builds are still using VS 2010. I'll take a
look at updating each environment for 2013 next.


On 7/15/14 5:11 PM, Gerald Combs wrote:
> The fuzz testing buildslave runs Ubuntu, but on a different machine.
> It's still running 12.04 but upgrading it to 14.04 is on my to-do list.
> 
> On 7/13/14 4:01 PM, Evan Huus wrote:
>> Is the Ubuntu buildslave the one on which the fuzz-bot runs? If so, does
>> that mean its zlib version is >= 1.2.3.7 and I can remove that valgrind
>> suppression in `tools/vg-suppressions`?
>>
>> Thanks,
>> Evan
>>
>>
>> On Wed, Jun 25, 2014 at 6:47 PM, Gerald Combs > > wrote:
>>
>> I added a new buildslave running Windows 8.1 32-bit. It will replace our
>> XP buildslave. I also upgraded the Ubuntu buildslave from 12.04 to
>> 14.04.
>>
>> Next up: Buildbot ↔ Gerrit integration.
>> 
>> ___
>> 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

Re: [Wireshark-dev] const'ness of value_string_ext

[Kevin Cox]

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
functions as a start.  Then we can move out from there.



signature.asc
Description: OpenPGP digital signature
___
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] const'ness of value_string_ext

[Evan Huus]

On Thu, Jul 24, 2014 at 4:35 PM, Kevin Cox  wrote:

> 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
> system but it made me curious why this error was possible without
> compiler errors or warnings.
>
> After looking into epan/value_string.{h,c} I noticed that all of the evs
> methods took 'const value_string_ext*' even though many of them may end
> up writing to the evs.  This all boils down to the "virtual" method
> '_vs_match2' which may contain '_try_val_to_str_ext_init' which casts
> away the const'ness and writes to the evs.
>
> There is a comment inside this function explaining why the const is
> casted away however I believe that this isn't the proper solution.  The
> comment discusses casting inside the function versus casting the
> function pointer when assigning it to '_vs_match2'.  I would argue that
> the correct solution is actually to change the prototype of '_vs_match2'
> from:
>
> const value_string *(*)(const guint32, const value_string_ext*)
> to
> const value_string *(*)(const guint32, value_string_ext*)
>
> then change all of the evs functions to take a non-const evs.  This
> would convey the actual signature of the functions and prevent this type
> of error in the future.
>
> However, the problem with this approach is that when declaring hf's and
> probably other places around the source 'const void*'s are used to
> handle evs.  So changing these functions would cause large changes to
> the code.  There a a number of solutions of varying completeness.
>
> 0: Leave as is.
> Pros:
> - Easy.
> Cons:
> - The API lies and can invoke undefined behaviour unless you know.
> - No compiler checking.
>
> 1: Change all of the evs functions and add the const-cast further up the
> stack.
> Pros:
> - The evs functions don't lie and people will get errors if they use an
> evs directly.
> - The evs API is now correct.
> - Can slowly start to move the rest of the code to be const-correct.
> Cons:
> - There is still an issue in a different part of the code.
> - Not full type safety.
>
> 2: Change everything.
> Pros:
> - Full compiler error checking and type safety.
> Cons:
> - Hard
> - May change dissector API.
>
> I was wondering what everyone else thought and what should be done to
> improve the safety of this code.
>
> Cheers,
> Kevin
>

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 :)
___
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] const'ness of value_string_ext

[Kevin Cox]

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
system but it made me curious why this error was possible without
compiler errors or warnings.

After looking into epan/value_string.{h,c} I noticed that all of the evs
methods took 'const value_string_ext*' even though many of them may end
up writing to the evs.  This all boils down to the "virtual" method
'_vs_match2' which may contain '_try_val_to_str_ext_init' which casts
away the const'ness and writes to the evs.

There is a comment inside this function explaining why the const is
casted away however I believe that this isn't the proper solution.  The
comment discusses casting inside the function versus casting the
function pointer when assigning it to '_vs_match2'.  I would argue that
the correct solution is actually to change the prototype of '_vs_match2'
from:

const value_string *(*)(const guint32, const value_string_ext*)
to
const value_string *(*)(const guint32, value_string_ext*)

then change all of the evs functions to take a non-const evs.  This
would convey the actual signature of the functions and prevent this type
of error in the future.

However, the problem with this approach is that when declaring hf's and
probably other places around the source 'const void*'s are used to
handle evs.  So changing these functions would cause large changes to
the code.  There a a number of solutions of varying completeness.

0: Leave as is.
Pros:
- Easy.
Cons:
- The API lies and can invoke undefined behaviour unless you know.
- No compiler checking.

1: Change all of the evs functions and add the const-cast further up the
stack.
Pros:
- The evs functions don't lie and people will get errors if they use an
evs directly.
- The evs API is now correct.
- Can slowly start to move the rest of the code to be const-correct.
Cons:
- There is still an issue in a different part of the code.
- Not full type safety.

2: Change everything.
Pros:
- Full compiler error checking and type safety.
Cons:
- Hard
- May change dissector API.

I was wondering what everyone else thought and what should be done to
improve the safety of this code.

Cheers,
Kevin



signature.asc
Description: OpenPGP digital signature
___
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] Difference between Autofoo and CMake build ?

[Bill Meier]

On 7/24/2014 2:09 PM, Kevin Cox wrote:


I usually get these too.  Maybe it was a compiler bug or something.  I
will try checking out the old version and doing a clean build to see if
the warning/error shows up now.



I just did a complete rebuild and I am now getting this error under
CMake as well.  I must have messed up my CMake "configure" somehow.




Kevin:

Ok; thanks for taking the time to do this.

(I always like to follow thru on things to make sure
 there isn't some issue we need to address).

Bill


___
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] tvb allocator (was: Re: [Wireshark-commits] master b6d20a2: Optimize reseting epan_dissect_t when filtering.)

[Bálint Réczey]

2014-07-24 20:48 GMT+02:00 Evan Huus :
>
> On Thu, Jul 24, 2014 at 2:42 PM, Bálint Réczey 
> wrote:
>>
>> Hi Jakub,
>>
>> 2014-07-22 0:52 GMT+02:00  :
>> > Hi,
>> >
>> > On Sat, Jul 12, 2014 at 02:27:06AM +0200, B??lint R??czey wrote:
>> >> I plan using ASAN for all programs which would catch (among others)
>> >> use-after-free and reading below or over the malloc()-ed
>> >> memory area. Those can't be caught if the program uses another layer
>> >> of bulk memory allocations.
>> >> g_malloc() and g_slice_* has the same problem, but they can be
>> >> overrideb by passing G_SLICE=always-malloc .
>> >
>> > We have these environment variables also, ver{3, 4} introduce
>> > WIRESHARK_DEBUG_WMEM_OBJECT_POOL_SKIP,
>> > where you can set, and object pool will not maintain free list of
>> > objects.
>> >
>> > I see no problem with enabling it by default when building with ASAN.
>> >
>> > Also it should be quite easy to use ASAN manual poisoning[1] with object
>> > pool API.
>> >
>> > wmem_object_pool_alloc(wmem_allocator_t *allocator, wmem_object_pool_t
>> > *pool):
>> > if (pool->current_count > 0) {
>> > ...
>> > ASAN_UNPOISON_MEMORY_REGION(pool->free_list, pool->object_size);
>> > pool->free_list = pool->free_list->next;
>> >
>> > wmem_object_pool_free(wmem_allocator_t *allocator, wmem_object_pool_t
>> > *pool, void *ptr)
>> > ...
>> > ASAN_POISON_MEMORY_REGION(ptr, pool->object_size);
>> >
>> > (not tested).
>> Thank you, I was not aware of those macros. I think we should add
>> those to the custom allocator code.
>
>
> Just setting WIRESHARK_DEBUG_WMEM_OVERRIDE=simple is easier, is it not?
I think it would worth testing the performance of both options, but
yes, using the simple allocator seems to be easier.
___
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] Oldest version of VS supported?

[Graham Bloice]

On 24 July 2014 19:06, Graham Bloice  wrote:

> On 24 July 2014 19:03, Pascal Quantin  wrote:
>
>>
>> Le 24 juil. 2014 20:00, "Graham Bloice"  a
>> écrit :
>>
>> >
>> > On 24 July 2014 18:51, Pascal Quantin  wrote:
>> >>
>> >> Le 24/07/2014 19:39, Joerg Mayer a écrit :
>> >> > On Thu, Jul 24, 2014 at 06:20:48PM +0100, Graham Bloice wrote:
>> >> >> On 24 July 2014 18:08, Joerg Mayer  wrote:
>> >> >>
>> >> >>> IIRC there was some discussion which versions of VS should still be
>> >> >>> supported,
>> >> >>> but I failed to find it in the archives. So, was there some
>> consensus
>> >> >>> which is
>> >> >>> the oldest version we are going to support with master?
>> >> >>>
>> >> >>>
>> >> >> I brought up the issue of moving to VS2013 for master, and
>> separately
>> >> >> dropping info from the (master) docs for earlier than VS2010.
>> >> >>
>> >> >> I didn't see any requests for support to build with earlier than
>> 2010,
>> >> >> although Guy did wonder about the doc changes, but no real
>> conclusion was
>> >> >> reached.
>> >> >>
>> >> >> Personally I would make 2013 the minimum supported for master.
>> >> > Hmm, OK. So we need an updated developer's guide setup section. I
>> will try
>> >> > to update my Windows vom 2010 to 2013 and see how it goes - just
>> have to
>> >> > find out how to snapshot the VM first ;->
>> >> > Could you update Makefile.nmake and config.nmake to rip out all the
>> >> > stuff that deals with older versions? That would make my life with
>> the
>> >> > CMake work on Windows somewhat easier  ;-)
>> >> >
>> >> > Thanks
>> >> >Jörg
>> >> Could not we keep at least VS2010 but change the default to VS2013 (if
>> >> everybody agree)? I find it a quite drastic change to drop all older
>> >> compilers suddenly... This is not something we have done in the past.
>> >>
>> >
>> > That was what I was meaning, we would leave support for VS2010, and fix
>> up whatever is needed for 2012 & 2013.  2013 builds well for me.  The
>> toolchain in 2013 is a big improvement over 2010.
>> >
>> > I think we can make nmake autodetect the version and possibly CMake
>> too, although that likes to make it's own mind up so needs a command line
>> switch if you have multiple versions.
>>
>> Which make me think that I must upload the MSVC2013 Lua package :)
>>
>>
> The current one builds and runs fine with VS2013, but I don't think I've
> tried any Lua scripts with it.
>
>
I have two batch files, one for VS2010 and the other for VS2013.  Both are
set by default for x86 builds, but it shouldn't be too hard to make them
bit-width agnostic.

For VS2010:

REM Environment setup for Wireshark and VS2010

set CYGWIN=nodosfilewarning
set WIRESHARK_BASE_DIR=E:\Wireshark
set WIRESHARK_TARGET_PLATFORM=win32
set QT5_BASE_DIR=C:\qt\Qt-5.1.1-MSVC2010-win32-ws

set VisualStudioVersion=10.0

set WIRESHARK_VERSION_EXTRA=-GMB


and for VS2013:

REM Environment setup for Wireshark and VS2013

set CYGWIN=nodosfilewarning
set WIRESHARK_BASE_DIR=E:\Wireshark
set WIRESHARK_TARGET_PLATFORM=win32
set QT5_BASE_DIR=C:\Qt\Qt5.3.0\5.3\msvc2013

set WIRESHARK_VERSION_EXTRA=-GMB


I run these from a "Visual Studio Command Prompt", look in the Start Menu
for the appropriate "Visual Studio Tools" entry, and in there should be
some shortcuts.  Using the batch files, no changes are required to the
sources for a plain vanilla build.

-- 
Graham Bloice
___
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] tvb allocator (was: Re: [Wireshark-commits] master b6d20a2: Optimize reseting epan_dissect_t when filtering.)

[Evan Huus]

On Thu, Jul 24, 2014 at 2:42 PM, Bálint Réczey 
wrote:

> Hi Jakub,
>
> 2014-07-22 0:52 GMT+02:00  :
> > Hi,
> >
> > On Sat, Jul 12, 2014 at 02:27:06AM +0200, B??lint R??czey wrote:
> >> I plan using ASAN for all programs which would catch (among others)
> >> use-after-free and reading below or over the malloc()-ed
> >> memory area. Those can't be caught if the program uses another layer
> >> of bulk memory allocations.
> >> g_malloc() and g_slice_* has the same problem, but they can be
> >> overrideb by passing G_SLICE=always-malloc .
> >
> > We have these environment variables also, ver{3, 4} introduce
> WIRESHARK_DEBUG_WMEM_OBJECT_POOL_SKIP,
> > where you can set, and object pool will not maintain free list of
> objects.
> >
> > I see no problem with enabling it by default when building with ASAN.
> >
> > Also it should be quite easy to use ASAN manual poisoning[1] with object
> pool API.
> >
> > wmem_object_pool_alloc(wmem_allocator_t *allocator, wmem_object_pool_t
> *pool):
> > if (pool->current_count > 0) {
> > ...
> > ASAN_UNPOISON_MEMORY_REGION(pool->free_list, pool->object_size);
> > pool->free_list = pool->free_list->next;
> >
> > wmem_object_pool_free(wmem_allocator_t *allocator, wmem_object_pool_t
> *pool, void *ptr)
> > ...
> > ASAN_POISON_MEMORY_REGION(ptr, pool->object_size);
> >
> > (not tested).
> Thank you, I was not aware of those macros. I think we should add
> those to the custom allocator code.
>

Just setting WIRESHARK_DEBUG_WMEM_OVERRIDE=simple is easier, is it not?


> Cheers,
> Balint
> ___
> 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] tvb allocator (was: Re: [Wireshark-commits] master b6d20a2: Optimize reseting epan_dissect_t when filtering.)

[Bálint Réczey]

Hi Jakub,

2014-07-22 0:52 GMT+02:00  :
> Hi,
>
> On Sat, Jul 12, 2014 at 02:27:06AM +0200, B??lint R??czey wrote:
>> I plan using ASAN for all programs which would catch (among others)
>> use-after-free and reading below or over the malloc()-ed
>> memory area. Those can't be caught if the program uses another layer
>> of bulk memory allocations.
>> g_malloc() and g_slice_* has the same problem, but they can be
>> overrideb by passing G_SLICE=always-malloc .
>
> We have these environment variables also, ver{3, 4} introduce 
> WIRESHARK_DEBUG_WMEM_OBJECT_POOL_SKIP,
> where you can set, and object pool will not maintain free list of objects.
>
> I see no problem with enabling it by default when building with ASAN.
>
> Also it should be quite easy to use ASAN manual poisoning[1] with object pool 
> API.
>
> wmem_object_pool_alloc(wmem_allocator_t *allocator, wmem_object_pool_t *pool):
> if (pool->current_count > 0) {
> ...
> ASAN_UNPOISON_MEMORY_REGION(pool->free_list, pool->object_size);
> pool->free_list = pool->free_list->next;
>
> wmem_object_pool_free(wmem_allocator_t *allocator, wmem_object_pool_t *pool, 
> void *ptr)
> ...
> ASAN_POISON_MEMORY_REGION(ptr, pool->object_size);
>
> (not tested).
Thank you, I was not aware of those macros. I think we should add
those to the custom allocator code.

Cheers,
Balint
___
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] Difference between Autofoo and CMake build ?

[Kevin Cox]

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 different
>>> results then a build by Kevin Cox (the submitter of the new
>>> dissector) using CMake on Linux.
>>>
>>> He used GCC 4.9.1 and CMake while I used GCC 4.9.0 and Autofoo.
>>>
>>> 1. The Autofoo compile indicated an
>>>   "unused but set" variable
>>>The CMake apparently did not.
>>
>> Should not be: I do (or at least did) get these messages regularly with
>> CMake.
> 
> I usually get these too.  Maybe it was a compiler bug or something.  I
> will try checking out the old version and doing a clean build to see if
> the warning/error shows up now.
> 

I just did a complete rebuild and I am now getting this error under
CMake as well.  I must have messed up my CMake "configure" somehow.




signature.asc
Description: OpenPGP digital signature
___
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] Oldest version of VS supported?

[Graham Bloice]

On 24 July 2014 19:03, Pascal Quantin  wrote:

>
> Le 24 juil. 2014 20:00, "Graham Bloice"  a
> écrit :
>
> >
> > On 24 July 2014 18:51, Pascal Quantin  wrote:
> >>
> >> Le 24/07/2014 19:39, Joerg Mayer a écrit :
> >> > On Thu, Jul 24, 2014 at 06:20:48PM +0100, Graham Bloice wrote:
> >> >> On 24 July 2014 18:08, Joerg Mayer  wrote:
> >> >>
> >> >>> IIRC there was some discussion which versions of VS should still be
> >> >>> supported,
> >> >>> but I failed to find it in the archives. So, was there some
> consensus
> >> >>> which is
> >> >>> the oldest version we are going to support with master?
> >> >>>
> >> >>>
> >> >> I brought up the issue of moving to VS2013 for master, and separately
> >> >> dropping info from the (master) docs for earlier than VS2010.
> >> >>
> >> >> I didn't see any requests for support to build with earlier than
> 2010,
> >> >> although Guy did wonder about the doc changes, but no real
> conclusion was
> >> >> reached.
> >> >>
> >> >> Personally I would make 2013 the minimum supported for master.
> >> > Hmm, OK. So we need an updated developer's guide setup section. I
> will try
> >> > to update my Windows vom 2010 to 2013 and see how it goes - just have
> to
> >> > find out how to snapshot the VM first ;->
> >> > Could you update Makefile.nmake and config.nmake to rip out all the
> >> > stuff that deals with older versions? That would make my life with the
> >> > CMake work on Windows somewhat easier  ;-)
> >> >
> >> > Thanks
> >> >Jörg
> >> Could not we keep at least VS2010 but change the default to VS2013 (if
> >> everybody agree)? I find it a quite drastic change to drop all older
> >> compilers suddenly... This is not something we have done in the past.
> >>
> >
> > That was what I was meaning, we would leave support for VS2010, and fix
> up whatever is needed for 2012 & 2013.  2013 builds well for me.  The
> toolchain in 2013 is a big improvement over 2010.
> >
> > I think we can make nmake autodetect the version and possibly CMake too,
> although that likes to make it's own mind up so needs a command line switch
> if you have multiple versions.
>
> Which make me think that I must upload the MSVC2013 Lua package :)
>
>
The current one builds and runs fine with VS2013, but I don't think I've
tried any Lua scripts with it.

-- 
Graham Bloice
___
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] Oldest version of VS supported?

[Pascal Quantin]

Le 24 juil. 2014 20:00, "Graham Bloice"  a
écrit :
>
> On 24 July 2014 18:51, Pascal Quantin  wrote:
>>
>> Le 24/07/2014 19:39, Joerg Mayer a écrit :
>> > On Thu, Jul 24, 2014 at 06:20:48PM +0100, Graham Bloice wrote:
>> >> On 24 July 2014 18:08, Joerg Mayer  wrote:
>> >>
>> >>> IIRC there was some discussion which versions of VS should still be
>> >>> supported,
>> >>> but I failed to find it in the archives. So, was there some consensus
>> >>> which is
>> >>> the oldest version we are going to support with master?
>> >>>
>> >>>
>> >> I brought up the issue of moving to VS2013 for master, and separately
>> >> dropping info from the (master) docs for earlier than VS2010.
>> >>
>> >> I didn't see any requests for support to build with earlier than 2010,
>> >> although Guy did wonder about the doc changes, but no real conclusion
was
>> >> reached.
>> >>
>> >> Personally I would make 2013 the minimum supported for master.
>> > Hmm, OK. So we need an updated developer's guide setup section. I will
try
>> > to update my Windows vom 2010 to 2013 and see how it goes - just have
to
>> > find out how to snapshot the VM first ;->
>> > Could you update Makefile.nmake and config.nmake to rip out all the
>> > stuff that deals with older versions? That would make my life with the
>> > CMake work on Windows somewhat easier  ;-)
>> >
>> > Thanks
>> >Jörg
>> Could not we keep at least VS2010 but change the default to VS2013 (if
>> everybody agree)? I find it a quite drastic change to drop all older
>> compilers suddenly... This is not something we have done in the past.
>>
>
> That was what I was meaning, we would leave support for VS2010, and fix
up whatever is needed for 2012 & 2013.  2013 builds well for me.  The
toolchain in 2013 is a big improvement over 2010.
>
> I think we can make nmake autodetect the version and possibly CMake too,
although that likes to make it's own mind up so needs a command line switch
if you have multiple versions.

Which make me think that I must upload the MSVC2013 Lua package :)
___
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] Oldest version of VS supported?

[Graham Bloice]

On 24 July 2014 18:59, Joerg Mayer  wrote:

> On Thu, Jul 24, 2014 at 07:51:37PM +0200, Pascal Quantin wrote:
> > Le 24/07/2014 19:39, Joerg Mayer a écrit :
> [...]
> > > Hmm, OK. So we need an updated developer's guide setup section. I will
> try
> > > to update my Windows vom 2010 to 2013 and see how it goes - just have
> to
> > > find out how to snapshot the VM first ;->
> > > Could you update Makefile.nmake and config.nmake to rip out all the
> > > stuff that deals with older versions? That would make my life with the
> > > CMake work on Windows somewhat easier  ;-)
>
> > Could not we keep at least VS2010 but change the default to VS2013 (if
> > everybody agree)? I find it a quite drastic change to drop all older
> > compilers suddenly... This is not something we have done in the past.
>
> I wouldn't mind that either - in that case I would not need to update my
> Windows build box right now :-)
>
> Btw, I've already found out that without updated setup instructions for the
> wsdg it would probably take me way too much time to do the upgrade from
> 2010
> to 2013.
>
>
Yep I misread Pascal's email.  VS2010 will still be supported.

I'll try to post some new instructions here tonight.  Pretty trivial really.

-- 
Graham Bloice
___
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] Oldest version of VS supported?

[Graham Bloice]

On 24 July 2014 18:51, Pascal Quantin  wrote:

> Le 24/07/2014 19:39, Joerg Mayer a écrit :
> > On Thu, Jul 24, 2014 at 06:20:48PM +0100, Graham Bloice wrote:
> >> On 24 July 2014 18:08, Joerg Mayer  wrote:
> >>
> >>> IIRC there was some discussion which versions of VS should still be
> >>> supported,
> >>> but I failed to find it in the archives. So, was there some consensus
> >>> which is
> >>> the oldest version we are going to support with master?
> >>>
> >>>
> >> I brought up the issue of moving to VS2013 for master, and separately
> >> dropping info from the (master) docs for earlier than VS2010.
> >>
> >> I didn't see any requests for support to build with earlier than 2010,
> >> although Guy did wonder about the doc changes, but no real conclusion
> was
> >> reached.
> >>
> >> Personally I would make 2013 the minimum supported for master.
> > Hmm, OK. So we need an updated developer's guide setup section. I will
> try
> > to update my Windows vom 2010 to 2013 and see how it goes - just have to
> > find out how to snapshot the VM first ;->
> > Could you update Makefile.nmake and config.nmake to rip out all the
> > stuff that deals with older versions? That would make my life with the
> > CMake work on Windows somewhat easier  ;-)
> >
> > Thanks
> >Jörg
> Could not we keep at least VS2010 but change the default to VS2013 (if
> everybody agree)? I find it a quite drastic change to drop all older
> compilers suddenly... This is not something we have done in the past.
>
>
That was what I was meaning, we would leave support for VS2010, and fix up
whatever is needed for 2012 & 2013.  2013 builds well for me.  The
toolchain in 2013 is a big improvement over 2010.

I think we can make nmake autodetect the version and possibly CMake too,
although that likes to make it's own mind up so needs a command line switch
if you have multiple versions.

-- 
Graham Bloice
___
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] Oldest version of VS supported?

[Joerg Mayer]

On Thu, Jul 24, 2014 at 07:51:37PM +0200, Pascal Quantin wrote:
> Le 24/07/2014 19:39, Joerg Mayer a écrit :
[...]
> > Hmm, OK. So we need an updated developer's guide setup section. I will try
> > to update my Windows vom 2010 to 2013 and see how it goes - just have to
> > find out how to snapshot the VM first ;->
> > Could you update Makefile.nmake and config.nmake to rip out all the
> > stuff that deals with older versions? That would make my life with the
> > CMake work on Windows somewhat easier  ;-)

> Could not we keep at least VS2010 but change the default to VS2013 (if
> everybody agree)? I find it a quite drastic change to drop all older
> compilers suddenly... This is not something we have done in the past.

I wouldn't mind that either - in that case I would not need to update my
Windows build box right now :-)

Btw, I've already found out that without updated setup instructions for the
wsdg it would probably take me way too much time to do the upgrade from 2010
to 2013.

Ciao
Jörg
-- 
Joerg Mayer   
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
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] Oldest version of VS supported?

[Pascal Quantin]

Le 24/07/2014 19:39, Joerg Mayer a écrit :
> On Thu, Jul 24, 2014 at 06:20:48PM +0100, Graham Bloice wrote:
>> On 24 July 2014 18:08, Joerg Mayer  wrote:
>>
>>> IIRC there was some discussion which versions of VS should still be
>>> supported,
>>> but I failed to find it in the archives. So, was there some consensus
>>> which is
>>> the oldest version we are going to support with master?
>>>
>>>
>> I brought up the issue of moving to VS2013 for master, and separately
>> dropping info from the (master) docs for earlier than VS2010.
>>
>> I didn't see any requests for support to build with earlier than 2010,
>> although Guy did wonder about the doc changes, but no real conclusion was
>> reached.
>>
>> Personally I would make 2013 the minimum supported for master.
> Hmm, OK. So we need an updated developer's guide setup section. I will try
> to update my Windows vom 2010 to 2013 and see how it goes - just have to
> find out how to snapshot the VM first ;->
> Could you update Makefile.nmake and config.nmake to rip out all the
> stuff that deals with older versions? That would make my life with the
> CMake work on Windows somewhat easier  ;-)
>
> Thanks
>Jörg
Could not we keep at least VS2010 but change the default to VS2013 (if
everybody agree)? I find it a quite drastic change to drop all older
compilers suddenly... This is not something we have done in the past.

Pascal.
___
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] Oldest version of VS supported?

[Joerg Mayer]

On Thu, Jul 24, 2014 at 06:20:48PM +0100, Graham Bloice wrote:
> On 24 July 2014 18:08, Joerg Mayer  wrote:
> 
> > IIRC there was some discussion which versions of VS should still be
> > supported,
> > but I failed to find it in the archives. So, was there some consensus
> > which is
> > the oldest version we are going to support with master?
> >
> >
> I brought up the issue of moving to VS2013 for master, and separately
> dropping info from the (master) docs for earlier than VS2010.
> 
> I didn't see any requests for support to build with earlier than 2010,
> although Guy did wonder about the doc changes, but no real conclusion was
> reached.
> 
> Personally I would make 2013 the minimum supported for master.

Hmm, OK. So we need an updated developer's guide setup section. I will try
to update my Windows vom 2010 to 2013 and see how it goes - just have to
find out how to snapshot the VM first ;->
Could you update Makefile.nmake and config.nmake to rip out all the
stuff that deals with older versions? That would make my life with the
CMake work on Windows somewhat easier  ;-)

Thanks
   Jörg
-- 
Joerg Mayer   
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
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] Oldest version of VS supported?

[Graham Bloice]

On 24 July 2014 18:08, Joerg Mayer  wrote:

> IIRC there was some discussion which versions of VS should still be
> supported,
> but I failed to find it in the archives. So, was there some consensus
> which is
> the oldest version we are going to support with master?
>
>
I brought up the issue of moving to VS2013 for master, and separately
dropping info from the (master) docs for earlier than VS2010.

I didn't see any requests for support to build with earlier than 2010,
although Guy did wonder about the doc changes, but no real conclusion was
reached.

Personally I would make 2013 the minimum supported for master.

-- 
Graham Bloice
___
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] Oldest version of VS supported?

[Joerg Mayer]

IIRC there was some discussion which versions of VS should still be supported,
but I failed to find it in the archives. So, was there some consensus which is
the oldest version we are going to support with master?

Thanks
   Jörg
-- 
Joerg Mayer   
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
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] Difference between Autofoo and CMake build ?

[Kevin Cox]

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 (the submitter of the new
>> dissector) using CMake on Linux.
>>
>> He used GCC 4.9.1 and CMake while I used GCC 4.9.0 and Autofoo.
>>
>> 1. The Autofoo compile indicated an
>>   "unused but set" variable
>>The CMake apparently did not.
> 
> Should not be: I do (or at least did) get these messages regularly with
> CMake.

I usually get these too.  Maybe it was a compiler bug or something.  I
will try checking out the old version and doing a clean build to see if
the warning/error shows up now.

>> 2. The ceph dissector had several value_string_ext structs
>>defined as 'static const ...'.
>>
>>The Wireshark built with CMake worked AOK when
>>the ceph dissector used the extended value
>>strings for the first time (i.e., no exceptions).
>>
>>The Wireshark built with Autofoo trapped
>>when the extended value string structs were used
>>for the first time (when there was an attempt to
>>write to the struct).
>>
>>IOW: In one case, the structs were apparently not in a r/o section
>> while in the other they apparently were.
>>
>>I've no idea if this difference has anything to
>>do with CMake vs Autofoo.
>>
>>
>> Thoughts ?
> 
> Not on first sight. Maybe you can do a comparison on your system where
> all the other tools are identical?
> 

I just ran a test build and ./autogen && ./configure && make performed
the same way.  It seems that GCC 4.9.1 doesn't want to put those
structures in .rodata on my system for whatever reason.

Also of note, the header_field_info.strings member is defined as 'const
void*' but when passed an extended value string it appears that the
const is casted away.  This should probably be changed in order to be
type safe, as an error would have been raised if it was declared
properly as 'void*'.

Of course the downside to this is that regular value strings will not be
allowed to be const, but that can be worked around by modifying the
VALS() macro to cast away that const-ness as value_string's will always
be treated const.  Ideally there would be a more type safe way to do this.




signature.asc
Description: OpenPGP digital signature
___
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] Difference between Autofoo and CMake build ?

[Joerg Mayer]

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 (the submitter of the new
> dissector) using CMake on Linux.
> 
> He used GCC 4.9.1 and CMake while I used GCC 4.9.0 and Autofoo.
> 
> 1. The Autofoo compile indicated an
>   "unused but set" variable
>The CMake apparently did not.

Should not be: I do (or at least did) get these messages regularly with
CMake.

>Different CFlags ?

As the order of flags in both files is rather random I did a bit of grepping,
sorting and some manual editing. It looks like the flags should be the same.

> 2. The ceph dissector had several value_string_ext structs
>defined as 'static const ...'.
> 
>The Wireshark built with CMake worked AOK when
>the ceph dissector used the extended value
>strings for the first time (i.e., no exceptions).
> 
>The Wireshark built with Autofoo trapped
>when the extended value string structs were used
>for the first time (when there was an attempt to
>write to the struct).
> 
>IOW: In one case, the structs were apparently not in a r/o section
> while in the other they apparently were.
> 
>I've no idea if this difference has anything to
>do with CMake vs Autofoo.
> 
> 
> Thoughts ?

Not on first sight. Maybe you can do a comparison on your system where
all the other tools are identical?

Ciao
 Jörg

-- 
Joerg Mayer   
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
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] Difference between Autofoo and CMake build ?

[Bill Meier]

(For Jörg Mayer)

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 (the submitter of the new dissector) using CMake on 
Linux.


He used GCC 4.9.1 and CMake while I used GCC 4.9.0 and Autofoo.

1. The Autofoo compile indicated an
  "unused but set" variable
   The CMake apparently did not.

   Different CFlags ?

2. The ceph dissector had several value_string_ext structs
   defined as 'static const ...'.

   The Wireshark built with CMake worked AOK when
   the ceph dissector used the extended value
   strings for the first time (i.e., no exceptions).

   The Wireshark built with Autofoo trapped
   when the extended value string structs were used
   for the first time (when there was an attempt to
   write to the struct).

   IOW: In one case, the structs were apparently not in a r/o section
while in the other they apparently were.

   I've no idea if this difference has anything to
   do with CMake vs Autofoo.


Thoughts ?

[1] https://code.wireshark.org/review/#/c/1889/

___
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