gtk-gnutella-devel Digest, Vol 29, Issue 1

Send gtk-gnutella-devel mailing list submissions to
        gtk-gnutella-devel@...

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
or, via email, send a message with subject or body 'help' to
        gtk-gnutella-devel-request@...

You can reach the person managing the list at
        gtk-gnutella-devel-owner@...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of gtk-gnutella-devel digest..."


Today's Topics:

   1.  STATIC_ASSERT related to maximum alignment (Lars Nordlund)
   2. Re:  STATIC_ASSERT related to maximum alignment (Christian Biere)
   3. Re:  STATIC_ASSERT related to maximum alignment (Lars Nordlund)
   4. Re:  STATIC_ASSERT related to maximum alignment (Christian Biere)
   5.  Static assert about atoms. (Matthew Lye)
   6. Re:  Static assert about atoms. (Christian Biere)
   7.  warning:  "size_t not int" in dht/routing.c (Matthew Lye)
   8. Re:  warning: "size_t not int" in dht/routing.c (Raphael Manfredi)
   9. Re:  FATAL: Assertion failure in atoms.c:928: "size > 0" in
      0.96.6 (Raphael Manfredi)


----------------------------------------------------------------------

Message: 1
Date: Sun, 3 May 2009 00:58:48 +0200
From: Lars Nordlund <lars.nordlund@...>
Subject: [gtk-gnutella-devel] STATIC_ASSERT related to maximum
        alignment
To: gtk-gnutella-devel@...
Message-ID: <20090503005848.0fae300c@laphroaig>
Content-Type: text/plain; charset=US-ASCII

Hello list

When building gtk-gnutella-current on NetBSD-5.0rc4/amd64 I get this
compile error:

cc -c -I../.. -I.. -I/usr/pkg/include/glib/glib-2.0 -I/usr/pkg/lib/glib-2.0/include    -DCURDIR=src/lib -O2 -g -pipe -momit-leaf-frame-pointer -W -Wall -Wformat=2 -Wshadow  atoms.c
atoms.c: In function 'atom_get':
atoms.c:837: error: duplicate case value
atoms.c:837: error: previously used here
gmake[3]: *** [atoms.o] Error 1

I think it relates this this entry in config.h

%grep MEM_ALI work/gtk-gnutella/config.h
/* MEM_ALIGNBYTES:
#define MEM_ALIGNBYTES 16 /**/

Building the latest gtk-gnutella release, 0.96.5, gives this in the
generated config.h:

%grep 'define MEM_ALI' work/gtk-gnutella-0.96.5/config.h
#define MEM_ALIGNBYTES 8 /**/

Changing the config.h file entry 16 to 8 gets me through the build on
gtk-gnutella-current, but I have not tried starting the binary.

Investigating the alignbytes detection program embedded in the
configure script reveals that it is the long double type which bumps up
the alignment constraint to 16. In the 0.96.5 release, only char and
double types are checked.

Any comments? I am not really sure how to proceed here.. I assume this
works fine on other 64bit OSes?


Best regards,
        Lars Nordlund



------------------------------

Message: 2
Date: Sun, 3 May 2009 02:18:49 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] STATIC_ASSERT related to maximum
        alignment
To: gtk-gnutella-devel@...
Message-ID: <20090503001848.GC16818@...>
Content-Type: text/plain; charset=utf-8

Lars Nordlund wrote:
The latest release is actually 0.96.6 although I'd recommend using
0.96.7u from SVN instead because the "stable" release leaks quite
badly.

> %grep 'define MEM_ALI' work/gtk-gnutella-0.96.5/config.h
> #define MEM_ALIGNBYTES 8 /**/
 
> Changing the config.h file entry 16 to 8 gets me through the build on
> gtk-gnutella-current, but I have not tried starting the binary.

> Investigating the alignbytes detection program embedded in the
> configure script reveals that it is the long double type which bumps up
> the alignment constraint to 16. In the 0.96.5 release, only char and
> double types are checked.

The old detection unit wasn't cross-compilable and suffered from blahism.
It defined MEM_ALIGNBYTES but actually talked about double. I considered
detecting the common maximum alignment constraint for all native types
is more useful and matching the seemingly obvious semantic of "align bytes".
Histerically, the widest type with the strictest alignment constraints
was 'double' but this was in the dark ages before the advent of C99,
maybe even before C89.

gtk-gnutella doesn't use "long double" but some library might, in theory.
 
> Any comments? I am not really sure how to proceed here.. I assume this
> works fine on other 64bit OSes?

Well, bugs don't exist unless reported. Apparently it does but nobody really
knows. In general, if gtk-gnutella doesn't compile or the compiler reports any
warnings, people should report these as soon as possible.

--
Christian



------------------------------

Message: 3
Date: Mon, 4 May 2009 23:45:59 +0200
From: Lars Nordlund <lars.nordlund@...>
Subject: Re: [gtk-gnutella-devel] STATIC_ASSERT related to maximum
        alignment
To: gtk-gnutella-devel@...
Cc: christianbiere@...
Message-ID: <20090504234559.6f79dd01@laphroaig>
Content-Type: text/plain; charset=US-ASCII

On Sun, 3 May 2009 02:18:49 +0200
Christian Biere <christianbiere@...> wrote:

> The latest release is actually 0.96.6 although I'd recommend using
> 0.96.7u from SVN instead because the "stable" release leaks quite
> badly.

Yes, you are correct. I blindly thought that pkgsrc/net/gtk-gnutella
was up-to-date. :-)

> The old detection unit wasn't cross-compilable and suffered from blahism.
> It defined MEM_ALIGNBYTES but actually talked about double. I considered
> detecting the common maximum alignment constraint for all native types
> is more useful and matching the seemingly obvious semantic of "align bytes".
> Histerically, the widest type with the strictest alignment constraints
> was 'double' but this was in the dark ages before the advent of C99,
> maybe even before C89.
>
> gtk-gnutella doesn't use "long double" but some library might, in theory.

I see.

> > Any comments? I am not really sure how to proceed here.. I assume this
> > works fine on other 64bit OSes?
>
> Well, bugs don't exist unless reported. Apparently it does but nobody really
> knows. In general, if gtk-gnutella doesn't compile or the compiler reports any
> warnings, people should report these as soon as possible.

I commented out the long double type from the Configure script test,
and have built a trunk version of gtk-gnutella. It has been running
stable for a couple of hours. Not much of a formal verification, but at
least an "it works here"-report..


Best regards,
        Lars Nordlund



------------------------------

Message: 4
Date: Tue, 5 May 2009 00:15:30 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] STATIC_ASSERT related to maximum
        alignment
To: gtk-gnutella-devel@...
Message-ID: <20090504221530.GA16259@...>
Content-Type: text/plain; charset=utf-8

Lars Nordlund wrote:
> On Sun, 3 May 2009 02:18:49 +0200
> Christian Biere <christianbiere@...> wrote:
 
> I commented out the long double type from the Configure script test,
> and have built a trunk version of gtk-gnutella. It has been running
> stable for a couple of hours. Not much of a formal verification, but at
> least an "it works here"-report..

Well, I think I had just fixed it before responding to your mail. So it
shouldn't be necessary to comment it out any longer. Don't you see any
warnings from the compiler at all?

Unfortunately, x86 platforms are no good for testing alignment correctness
because they're too forgiving.

By the way, practically there's no point for this test at all, as it's
MEM_ALIGNBYTES is a compile-time evaluable constant and a similar macro
could be used to evaluate alignment constraint for specific types instead
of using the maximum always - which might be overkill and wasting memory.

--
Christian



------------------------------

Message: 5
Date: Mon, 4 May 2009 21:34:33 -0400
From: Matthew Lye <mlye@...>
Subject: [gtk-gnutella-devel] Static assert about atoms.
To: gtk-gnutella-devel@...
Message-ID: <F7F2531A-D0EE-48FF-B838-1BDFFA750B4B@...>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

Hey there,

I was just trying to get Darwin's llvm-gcc (low level virtual machine  
based gcc) going on my machine, and I'm getting a static assert at  
line 832 of "atoms.c";  the arena offset isn't aligning to modulo 16  
bytes.  (A recent change to alignment in llvm-gcc 4.2).

http://devworld.apple.com/releasenotes/DeveloperTools/RN-llvm-gcc/index.html 
  for latest changes.






------------------------------

Message: 6
Date: Tue, 5 May 2009 10:48:33 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] Static assert about atoms.
To: gtk-gnutella-devel@...
Message-ID: <20090505084833.GA29680@...>
Content-Type: text/plain; charset=utf-8

Matthew Lye wrote:
> I was just trying to get Darwin's llvm-gcc (low level virtual machine  
> based gcc) going on my machine, and I'm getting a static assert at  
> line 832 of "atoms.c";  the arena offset isn't aligning to modulo 16  
> bytes.  (A recent change to alignment in llvm-gcc 4.2).

My previous attempt to fix the bug reported by Lars Nordlund was nonsense.
I think it makes more sense this time.

--
Christian



------------------------------

Message: 7
Date: Sat, 9 May 2009 22:48:10 -0400
From: Matthew Lye <mlye@...>
Subject: [gtk-gnutella-devel] warning:  "size_t not int" in
        dht/routing.c
To: gtk-gnutella-devel@...
Message-ID: <733A0D02-92A7-42DE-A2DF-CB392C332FAE@...>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed;
        delsp=yes

Cosmetic in this instance I guess, but hopefully no-one's depending on  
size_t always equalling int.

routing.c: In function ?dht_compute_size_estimate?:
routing.c:2425: warning: format ?%d? expects type ?int?, but argument  
4 has type ?long unsigned int?

from /Users/mlye/prj/gtk-fast/src/dht/routing.cc:
line 2333:
> size_t i;

...
line 2425:
> g_message("DHT sparseness over %d nodes is %s = %f (%f)",
> i - 1, kuid_to_hex_string(&sparseness),
> kuid_to_double(&sparseness), ds / s);




------------------------------

Message: 8
Date: Sun, 10 May 2009 07:12:12 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] warning: "size_t not int" in
        dht/routing.c
To: gtk-gnutella-devel@...
Message-ID: <gu5uoc$2ne$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Matthew Lye <mlye@...> from ml.softs.gtk-gnutella.devel:
:Cosmetic in this instance I guess, but hopefully no-one's depending on  
:size_t always equalling int.
:
:routing.c: In function ?dht_compute_size_estimate?:
:routing.c:2425: warning: format ?%d? expects type ?int?, but argument  
:4 has type ?long unsigned int?

Thanks, fixed in r16705.

Raphael



------------------------------

Message: 9
Date: Sun, 10 May 2009 07:13:53 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] FATAL: Assertion failure in
        atoms.c:928: "size > 0" in 0.96.6
To: gtk-gnutella-devel@...
Message-ID: <gu5urh$2ne$2@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Jochen Kemnade <jochenkemnade@...> from ml.softs.gtk-gnutella.devel:
:I encounter this error every time gtk-gnutella has run for some time
:(about half an hour, roughly). Unfortunately I cannot tell how to
:reproduce it, but it seems to happen without user interaction. Maybe,
:the following backtrace provides more details:
:
:FATAL: Assertion failure in atoms.c:928: "size > 0"

Are you still seeing this with the DHT code enabled?

You'd better test it thoroughly, because the next release is likely to
make DHT code enabled by default...

Raphael



------------------------------

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel


End of gtk-gnutella-devel Digest, Vol 29, Issue 1
*************************************************