openldap-bugs August 2009

openldap-bugs@openldap.org

35 participants
225 discussions

Re: (ITS#6266) uninitialized var in overlays/dynlist.c:dl_cfgen()
by h.b.furuseth＠usit.uio.no 19 Aug '09

19 Aug '09

hyc(a)symas.com writes: >> Not even sure about what that piece of code is supposed to do... > > Indeed. It has no visible effect; an optimizer would just elide the > entire block. Sorry, I meant that was the use of _that variable_. There is other code in between. -- Hallvard

1 0

Re: (ITS#6266) uninitialized var in overlays/dynlist.c:dl_cfgen()
by hyc＠symas.com 19 Aug '09

19 Aug '09

hyc(a)symas.com wrote: > masarati(a)aero.polimi.it wrote: >>> gcc complains >>> dynlist.c:1537: warning: 'dlml' may be used uninitialized in this >>> function >>> Looks like its declaration at least should be moved outside the loop below >>> and it should be initialized to something. This is the complete use of >>> dlml: >>> >>> for ( ... ) { >>> dynlist_map_t *dlml; >>> if ( dlm == NULL ) { >>> dlml = NULL; >>> } >>> if ( dlml != NULL ) >>> dlml->dlm_next = dlmp; >>> dlml = dlmp; >>> } >> >> Not even sure about what that piece of code is supposed to do... > > Indeed. It has no visible effect; an optimizer would just elide the entire block. Never mind, the above code snippet was quite abbreviated. In the actual code, dlm is initialized to NULL. Therefore, dlml will get initialized to NULL. The effect is to make sure that new dlmp's are appended to the existing singly-linked list. It's pretty obvious when looking at the actual file. And also obvious that the uninit warning is false. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6266) uninitialized var in overlays/dynlist.c:dl_cfgen()
by hyc＠symas.com 19 Aug '09

19 Aug '09

masarati(a)aero.polimi.it wrote: >> gcc complains >> dynlist.c:1537: warning: 'dlml' may be used uninitialized in this >> function >> Looks like its declaration at least should be moved outside the loop below >> and it should be initialized to something. This is the complete use of >> dlml: >> >> for ( ... ) { >> dynlist_map_t *dlml; >> if ( dlm == NULL ) { >> dlml = NULL; >> } >> if ( dlml != NULL ) >> dlml->dlm_next = dlmp; >> dlml = dlmp; >> } > > Not even sure about what that piece of code is supposed to do... Indeed. It has no visible effect; an optimizer would just elide the entire block. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6161) test058-syncrepl-asymmetric failed (exit 6)
by pchamo2001＠yahoo.com 19 Aug '09

19 Aug '09

Hi all, I'm having similar problems with test058-syncrepl-asymmetric too. I compiled openldap-2.4.17 in several machines under FC3, FC4, and CentOS 5.3 using db-4.6.21.tar.gz, like this: export LD_RUN_PATH=/usr/local/BerkeleyDB.4.6/lib LDFLAGS="-L/usr/local/BerkeleyDB.4.6/lib" CPPFLAGS="-I/usr/local//BerkeleyDB.4.6/include" ./configure --enable-ipv6=no --enable-syslog --enable-slapd --enable-crypt --enable-modules --enable-bdb --enable-hdb --enable-monitor --enable-ldap --enable-accesslog=mod --enable-auditlog=mod --enable-constraint=mod --enable-dyngroup=mod --enable-dynlist=mod --enable-ppolicy=mod --enable-refint=mod --enable-syncprov=mod --enable-unique=mod --enable-valsort=mod --enable-expandurl=mod --enable-static --enable-shared --with-cyrus-sasl --with-tls=openssl; make depend; make; nohup make test -d 16384 & I copied the error messages here: http://correo.ingeominas.gov.co/tmp/ldap/ I wonder if that's right, or else, please just tell me how to run the tests again to get all the debug info possible. Thank you, Pablo Chamorro

1 0

Re: (ITS#6266) uninitialized var in overlays/dynlist.c:dl_cfgen()
by masarati＠aero.polimi.it 19 Aug '09

19 Aug '09

> gcc complains > dynlist.c:1537: warning: 'dlml' may be used uninitialized in this > function > Looks like its declaration at least should be moved outside the loop below > and it should be initialized to something. This is the complete use of > dlml: > > for ( ... ) { > dynlist_map_t *dlml; > if ( dlm == NULL ) { > dlml = NULL; > } > if ( dlml != NULL ) > dlml->dlm_next = dlmp; > dlml = dlmp; > } Not even sure about what that piece of code is supposed to do... p.

1 0

(ITS#6266) uninitialized var in overlays/dynlist.c:dl_cfgen()
by h.b.furuseth＠usit.uio.no 19 Aug '09

19 Aug '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard gcc complains dynlist.c:1537: warning: 'dlml' may be used uninitialized in this function Looks like its declaration at least should be moved outside the loop below and it should be initialized to something. This is the complete use of dlml: for ( ... ) { dynlist_map_t *dlml; if ( dlm == NULL ) { dlml = NULL; } if ( dlml != NULL ) dlml->dlm_next = dlmp; dlml = dlmp; }

1 0

Re: (ITS#6257) libldap: getopt flag to return the SASL username
by michael＠stroeder.com 19 Aug '09

19 Aug '09

masarati(a)aero.polimi.it wrote: >>> It returns whatever returned by sasl_getprop(); it should be a pointer >>> to >>> a zero-terminated string within the SASL context (you don't have to free >>> it, but it may be invalidated when the context is destroyed). >> It seems "you don't have to free it" was the clue! >> Well, it rather means you must not free it. > > I'm documenting options, and noticed that all other values are duplicated > rather than returned as they are. Would you mind reverting the behavior > of this option? I mean: return a LDAP_MALLOC'ed string instead of a > pointer to a string within the SASL handle? I'd appreciate it very much if it would be exactly behave in the same way like all other string-valued options. Ciao, Michael.

1 0

Re: (ITS#6247)
by daniel＠pluta.biz 19 Aug '09

19 Aug '09

Michael Ströder schrieb: > daniel(a)pluta.biz wrote: >> Even with the above described limited scope there seem to be plenty of >> open questions before thinking about "office-hours" and so on. Just two >> examples regarding the current implementation of now: >> - The server's timezone vs. the client's timezone (that's more or less >> obvious - in my opinion it's sufficient to store UTC times). >> - Replication of "now" attributes' values between slapds that are >> located in different timezones and client's that communicate with these >> server's... > > IMHO the client has to convert all user input to GMT and convert all server > results to local timezone for presentation to the user. The server internally > processes everything as GMT. Maybe I got you wrong though. Other server > implementations do it this way when checking logon hours. The server internally compares the (once set) attributes' values against its current time (whether locale or utc, does not really matter here essentially it's always used the same - utc or local time) but the server does not know (IMHO it cannot reliably determine) from which timezone a client currently is connecting. Imagine a business trip to Japan (GMT+10) login would not work during the original specified (European) office hours, even when asking a local replica server in Japan...

1 0

Re: (ITS#6257) libldap: getopt flag to return the SASL username
by masarati＠aero.polimi.it 19 Aug '09

19 Aug '09

>> It returns whatever returned by sasl_getprop(); it should be a pointer >> to >> a zero-terminated string within the SASL context (you don't have to free >> it, but it may be invalidated when the context is destroyed). > > It seems "you don't have to free it" was the clue! > Well, it rather means you must not free it. I'm documenting options, and noticed that all other values are duplicated rather than returned as they are. Would you mind reverting the behavior of this option? I mean: return a LDAP_MALLOC'ed string instead of a pointer to a string within the SASL handle? p.

1 0

Re: (ITS#6264) (docs) Admin guide: bad link in password policy overlay section
by hyc＠symas.com 19 Aug '09

19 Aug '09

jonathan(a)phillipoux.net wrote: > Full_Name: Jonathan Clarke > Version: irrelevant > OS: irrelevant > URL: > Submission from: (NULL) (82.67.204.30) > > > In http://www.openldap.org/doc/admin24/overlays.html#Password%20Policies : > > 8<--------- > Please see slapo-ppolicy(5) for complete explanations of features and discussion > of "Password Management Issues" at > http://www.connexitor.com/forums/viewtopic.php?f=6&t=25 > 8<--------- > > This link leads to a "The requested topic does not exist." error. > Looks like that should now be http://www.symas.com/blog/?page_id=66 I'll fix this. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
23
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2009