Menu
▾
▴
opensync-devel
|
From: Chris F. <cd...@fo...> - 2009-10-09 19:37:04
|
Hi, While reading the opensync API from the application perspective, group members are referred to by their ID, and this ID is a long long int. In output from commands such as osynctool --showgroup GroupName, these ID numbers start from 1. Why is the member ID so large? Is there really a risk of 9223372036854775807 different members? The reason I ask is that 'long long' is not as portable as just long, and there is no reason for such a large number, as far as I can see. Thanks, - Chris -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
|
From: Daniel G. <go...@b1...> - 2009-10-10 10:40:26
|
On Friday 09 October 2009 09:35:59 pm Chris Frey wrote: > Why is the member ID so large? Is there really a risk of > 9223372036854775807 different members? > > The reason I ask is that 'long long' is not as portable as just long, and > there is no reason for such a large number, as far as I can see. > No idea, this was introduced long before i joined the OpenSync development. We should have a look into the subversion logs if Armin mentioned any reason to use long long ... How many public member/group interfaces are using long long? Best Regards, Daniel -- Daniel Gollub Geschaeftsfuehrer: Ralph Dehner FOSS Developer Unternehmenssitz: Vohburg B1 Systems GmbH Amtsgericht: Ingolstadt Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... http://www.b1-systems.de Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D |
|
From: Chris F. <cd...@fo...> - 2009-10-21 21:02:00
|
On Sat, Oct 10, 2009 at 12:40:08PM +0200, Daniel Gollub wrote: > On Friday 09 October 2009 09:35:59 pm Chris Frey wrote: > > Why is the member ID so large? Is there really a risk of > > 9223372036854775807 different members? > > > > The reason I ask is that 'long long' is not as portable as just long, and > > there is no reason for such a large number, as far as I can see. > > > > No idea, this was introduced long before i joined the OpenSync development. > We should have a look into the subversion logs if Armin mentioned any reason > to use long long ... > > How many public member/group interfaces are using long long? Sorry for the delay on this. This command shows about 22 functions: find . -type f -name "*.h" -print0 | \ xargs -0 grep "long *long" | \ grep EXPORT | \ wc -l There are also things like misc/schemas/capabilities.xsd that have longlong and ulonglong for things such as AdvancedType. - Chris |
|
From: Henrik /K. <kaa...@us...> - 2009-10-10 11:39:30
|
Daniel Gollub wrote: > On Friday 09 October 2009 09:35:59 pm Chris Frey wrote: > >> Why is the member ID so large? Is there really a risk of >> 9223372036854775807 different members? >> >> The reason I ask is that 'long long' is not as portable as just long, and >> there is no reason for such a large number, as far as I can see. >> > > No idea, this was introduced long before i joined the OpenSync development. > We should have a look into the subversion logs if Armin mentioned any reason > to use long long ... > > How many public member/group interfaces are using long long? > > If we really want to stick to the frozen interface, we could use gint64 http://library.gnome.org/devel/glib/stable/glib-Basic-Types.html#gint64 (This would be "binary compatible" with current API for most platforms I guess, yet be more portable). However, I guess that long int should be more than enough... /Henrik |
|
From: Chris F. <cd...@fo...> - 2009-10-21 21:09:03
|
On Sat, Oct 10, 2009 at 01:39:08PM +0200, Henrik /KaarPoSoft wrote: > If we really want to stick to the frozen interface, we could use gint64 > http://library.gnome.org/devel/glib/stable/glib-Basic-Types.html#gint64 That would be worse in my opinion. long long is standard C99, it's just C++ that has trouble with it for now. The reason I brought it up was because it seemed silly to stretch C and C++ standards for values that rarely go above 2. - Chris |
|
From: Henrik /K. <he...@ka...> - 2009-10-22 08:50:18
|
Chris Frey wrote: > On Sat, Oct 10, 2009 at 01:39:08PM +0200, Henrik /KaarPoSoft wrote: > >> If we really want to stick to the frozen interface, we could use gint64 >> http://library.gnome.org/devel/glib/stable/glib-Basic-Types.html#gint64 >> > > That would be worse in my opinion. > > long long is standard C99, it's just C++ that has trouble with it for now. > The reason I brought it up was because it seemed silly to stretch > C and C++ standards for values that rarely go above 2. > > - Chris > I agree - it was just a "quick and dirty" if we really want to stick to frozen API. In my opinion the best solution would to break API and change long long to long. /Henrik |
|
From: Daniel G. <go...@b1...> - 2009-10-22 20:47:39
|
On Thursday 22 October 2009 10:49:54 am Henrik /KaarPoSoft wrote: > In my opinion the best solution would to break API and change long long > to long. > Are there any vetos? Could someone prepare a patch? -- Daniel Gollub Geschaeftsfuehrer: Ralph Dehner FOSS Developer Unternehmenssitz: Vohburg B1 Systems GmbH Amtsgericht: Ingolstadt Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... http://www.b1-systems.de Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D |
|
From: Chris F. <cd...@fo...> - 2009-10-23 18:47:45
|
On Thu, Oct 22, 2009 at 10:47:25PM +0200, Daniel Gollub wrote: > On Thursday 22 October 2009 10:49:54 am Henrik /KaarPoSoft wrote: > > In my opinion the best solution would to break API and change long long > > to long. > > > > Are there any vetos? > Could someone prepare a patch? Since I brought this up, I can prepare a patch. Busy weekend here though, so please pardon any slight delay. Thanks, - Chris |
Thanks for helping keep SourceForge clean.
X