Re: [Wireshark-dev] [Wireshark-commits] rev 51169: / /trunk/epan/: app_mem_usage.c

On Aug 6, 2013, at 3:57 PM, Dirk Jagdmann wrote: >> If not, would an lseek() followed by a read() do just as well? > > No. lseek() and read() modify the file position/offset. pread() however does > *not* modify it. So to emulate pread() you would need something like: If you do an absolute lse

Re: [Wireshark-dev] [Wireshark-commits] rev 51169: / /trunk/epan/: app_mem_usage.c

If not, would an lseek() followed by a read() do just as well? No. lseek() and read() modify the file position/offset. pread() however does *not* modify it. So to emulate pread() you would need something like: ssize_t my_pread(int fd, void *buf, size_t count, off_t offset) { const off_t old

Re: [Wireshark-dev] Fwd: [Wireshark-commits] rev 51173: /trunk/epan/ /trunk/epan/: proto.c -> Use __builtin_ctz for GCC/clang

On Tue, Aug 06, 2013 at 11:39:11PM +0200, Anders Broman wrote: > Should we use *_BitScanForward* on Windows? > http://msdn.microsoft.com/en-us/library/wfd9z0bb%28VS.80%29.aspx Sure, if you know how to do it, why not. ___ Sent

Re: [Wireshark-dev] [Wireshark-commits] rev 51137: /trunk/ /trunk/: manuf

Possibly. make-services.pl says http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt doesn't have enough data The registry is available as a CSV file: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.csv We might want to

[Wireshark-dev] Fwd: [Wireshark-commits] rev 51173: /trunk/epan/ /trunk/epan/: proto.c -> Use __builtin_ctz for GCC/clang

Hi, Should we use *_BitScanForward* on Windows? http://msdn.microsoft.com/en-us/library/wfd9z0bb%28VS.80%29.aspx Regards Anders Ursprungligt meddelande Ämne: [Wireshark-commits] rev 51173: /trunk/epan/ /trunk/epan/: proto.c Datum: Tue, 06 Aug 2013 19:53:55 GMT Från: darkja

Re: [Wireshark-dev] [Wireshark-commits] rev 51169: / /trunk/epan/: app_mem_usage.c

On Tue, Aug 06, 2013 at 02:18:38PM -0400, Evan Huus wrote: > Or not quite. The question is why the feature test macro is for glibc > 2.12 and 2008, when the function existed long before that... I've used _XOPEN_SOURCE to avoid problems :) But most likely because it's guarder with _POSIX_C_SOURCE

Re: [Wireshark-dev] [Wireshark-commits] rev 51169: / /trunk/epan/: app_mem_usage.c

On Tue, Aug 6, 2013 at 2:17 PM, Evan Huus wrote: > On Tue, Aug 6, 2013 at 2:14 PM, Jakub Zawadzki > wrote: >> On Tue, Aug 06, 2013 at 10:59:42AM -0700, Guy Harris wrote: >>> >>> On Aug 6, 2013, at 9:38 AM, darkja...@wireshark.org wrote: >>> >>> > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?vie

Re: [Wireshark-dev] [Wireshark-commits] rev 51169: / /trunk/epan/: app_mem_usage.c

On Tue, Aug 6, 2013 at 2:14 PM, Jakub Zawadzki wrote: > On Tue, Aug 06, 2013 at 10:59:42AM -0700, Guy Harris wrote: >> >> On Aug 6, 2013, at 9:38 AM, darkja...@wireshark.org wrote: >> >> > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=51169 >> > >> > User: darkjames >> > Date: 2

Re: [Wireshark-dev] [Wireshark-commits] rev 51169: / /trunk/epan/: app_mem_usage.c

On Tue, Aug 6, 2013 at 1:59 PM, Guy Harris wrote: > > On Aug 6, 2013, at 9:38 AM, darkja...@wireshark.org wrote: > >> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=51169 >> >> User: darkjames >> Date: 2013/08/06 09:38 AM >> >> Log: >> app_mem_usage fixes: >> >> - Add missing fea

Re: [Wireshark-dev] [Wireshark-commits] rev 51169: / /trunk/epan/: app_mem_usage.c

On Tue, Aug 06, 2013 at 10:59:42AM -0700, Guy Harris wrote: > > On Aug 6, 2013, at 9:38 AM, darkja...@wireshark.org wrote: > > > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=51169 > > > > User: darkjames > > Date: 2013/08/06 09:38 AM > > > > Log: > > app_mem_usage fixes: > >

Re: [Wireshark-dev] Gently migrating to Git + Gerrit

On 8/6/13 4:18 AM, Bálint Réczey wrote: > Currently all the library archives are stored in SVN and if we simply convert > it > to Git anyone cloning the repository would have to download all the libs ever > checked in (unless using git clone --depth which imposes other limitations). > Handling bi

Re: [Wireshark-dev] [Wireshark-commits] rev 51169: / /trunk/epan/: app_mem_usage.c

On Aug 6, 2013, at 9:38 AM, darkja...@wireshark.org wrote: > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=51169 > > User: darkjames > Date: 2013/08/06 09:38 AM > > Log: > app_mem_usage fixes: > > - Add missing feature test macro for pread() Do all versions of the Linux ker

Re: [Wireshark-dev] Remove hf_ variables

Hi, On Tue, Aug 06, 2013 at 02:51:22PM +0200, Bálint Réczey wrote: > If we plan making such big changes which require touching practically > every dissector, it would be nice to migrate dissection related global > variables I'm not sure if it's in scope of this project, I hope above change invol

Re: [Wireshark-dev] Remove hf_ variables

On Jul 29, 2013, at 1:12 PM, Jakub Zawadzki wrote: > Is anyone attached to hf_ variables? ;) Having just fixed a bug in some stuff I'm working on wherein I passed to a function, in the wrong order, a non-hf_integer value and an hf_ value, which would have been caught by the compiler had we pa

Re: [Wireshark-dev] On SLES 11 app_mem_usage.c:105: error: implicit declaration of function 'pread'

Hi, On Tue, Aug 06, 2013 at 11:29:49AM +, Anders Broman wrote: > I get: > app_mem_usage.c: In function 'inux_get_memory': > app_mem_usage.c:105: error: implicit declaration of function 'pread' > Building on SLES11 any ideas? Should be fixed in r51169, sorry. __

Re: [Wireshark-dev] Loading of MIB:s broken? related to Hf fields created.

Hmm a clean build fixed it From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Anders Broman Sent: den 6 augusti 2013 13:36 To: wireshark-dev@wireshark.org Subject: [Wireshark-dev] Loading of MIB:s broken? related to Hf fields created. Hi, Starting

Re: [Wireshark-dev] addr_resolv.c, transport name resolution appalingly slow.

Hi, This patch fixes it... -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Anders Broman Sent: den 6 augusti 2013 16:05 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] addr_resolv.c, transport na

Re: [Wireshark-dev] addr_resolv.c, transport name resolution appalingly slow.

-Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Evan Huus Sent: den 6 augusti 2013 16:01 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] addr_resolv.c, transport name resolution appalingly slow.

Re: [Wireshark-dev] addr_resolv.c, transport name resolution appalingly slow.

On Tue, Aug 6, 2013 at 9:41 AM, Anders Broman wrote: > Hi, > > I will revert the change to use a hash table for transport name resolution > as soon as I can, the performance is horrible. It shouldn't be, glib hash tables are pretty efficient. If you profile, where is the time being spent? ___

[Wireshark-dev] Bluetooth: review request for "SCMS-T for AVDTP" and "SBC playing for RTP player"

Hi, This thread ( https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7893 [* Bug 7893* - Bluetooth: Add support for AVDTP/A2DP/VDP and SBC codec within playing stream]) live for some time, so I want to ask for review. Anybody can look at

[Wireshark-dev] addr_resolv.c, transport name resolution appalingly slow.

Hi, I will revert the change to use a hash table for transport name resolution as soon as I can, the performance is horrible. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-d

Re: [Wireshark-dev] On SLES 11 app_mem_usage.c:105: error: implicit declaration of function 'pread'

You can replace pread with an lseek and a read, I think. On Tue, Aug 6, 2013 at 8:33 AM, Anders Broman wrote: > Hi, > > It’s a managed box so I can’t alter its content glibc-2.9-13.3.1 > > > > From: wireshark-dev-boun...@wireshark.org > [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Ev

Re: [Wireshark-dev] Remove hf_ variables

2013/7/30 Joerg Mayer : > On Mon, Jul 29, 2013 at 10:42:02PM +0200, Jakub Zawadzki wrote: >> On Mon, Jul 29, 2013 at 01:25:41PM -0700, Guy Harris wrote: >> > >> > On Jul 29, 2013, at 1:12 PM, Jakub Zawadzki >> > wrote: >> > >> > > Is anyone attached to hf_ variables? ;) >> > > >> > > There's no r

Re: [Wireshark-dev] On SLES 11 app_mem_usage.c:105: error: implicit declaration of function 'pread'

Hi, It’s a managed box so I can’t alter its content glibc-2.9-13.3.1 From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Evan Huus Sent: den 6 augusti 2013 14:04 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] On SLES 11 app_me

[Wireshark-dev] Adding an optional expert field to colouring rules?

Hi, I sometimes add colouring rules for some condition I am only interested in for a short time (i.e. its not worth adding expert info for to the relevant dissector). Then, I want to quickly find the frames that match that condition. I realise that I can use filtering rules such as: frame.color

Re: [Wireshark-dev] On SLES 11 app_mem_usage.c:105: error: implicit declaration of function 'pread'

http://linux.die.net/man/2/pread Make sure you have the necessary includes and a new enough libc? On 2013-08-06, at 7:29 AM, Anders Broman wrote: > Hi, > I get: > app_mem_usage.c: In function ‘inux_get_memory’: > app_mem_usage.c:105: error: implicit declaration of function ‘pread’ > Building on

[Wireshark-dev] Loading of MIB:s broken? related to Hf fields created.

Hi, Starting WS with loading of MIB:s I get: 13:32:24 Err Field (abbrev='IP-MIB.ipForwDatagrams') does not have a n ame ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshar

[Wireshark-dev] On SLES 11 app_mem_usage.c:105: error: implicit declaration of function 'pread'

Hi, I get: app_mem_usage.c: In function 'inux_get_memory': app_mem_usage.c:105: error: implicit declaration of function 'pread' Building on SLES11 any ideas? Regards Anders ___ Sent via:Wireshark-dev mailing list Archives

Re: [Wireshark-dev] Gently migrating to Git + Gerrit

Hi Gerald, 2013/8/6 Gerald Combs : > I finally have some time set aside to do more work on the Git migration. > I'm hoping to do the following in the near future: Great! > > Switch code.wireshark.org from gitweb to cgit. > > This isn't strictly necessary but IMHO cgit has a slightly nicer > inter

Re: [Wireshark-dev] [Wireshark-commits] rev 51137: /trunk/ /trunk/: manuf

The services file hasn't been updating the last few weeks. Has the format changed again? On 2013-08-04, at 2:03 PM, ger...@wireshark.org wrote: > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=51137 > > User: gerald > Date: 2013/08/04 07:03 AM > > Log: > [Automatic manuf, ser