- openldap-bugs - openldap.org

Re: (ITS#8754) ldpasearch IPv5 only
by ondra＠mistotebe.net 14 Jun '19

14 Jun '19

On Wed, Oct 11, 2017 at 12:24:56PM +0000, dpa-openldap(a)aegee.org wrote: > After `./configure --disable-ipv6` I expect, that `ldapsearch` will not contact > severs over IPv6, which is achieved with the fix below. Hi, thank you for your work, the patch has been pushed to master (5e8aa3f6d111160cbb3ce3a49af7323258e702b5) and will also be part (c4f55cea87880ca8c14b559bd77bcea19ad615cd) of the upcoming 2.4.48 release. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8427) Incorrect value of tls_reqcert in syncrepl
by ondra＠mistotebe.net 14 Jun '19

14 Jun '19

On Fri, Dec 01, 2017 at 07:15:08PM +0000, mkp37215(a)gmail.com wrote: > I, Maciej Puzio, hereby place the above modifications to OpenLDAP > Software (and only these modifications) into the public domain. Hence, > these modifications may be freely used and/or redistributed for any > purpose with or without attribution and/or other notice. Hi Maciej, thank you for your work, patches have been pushed to master and will also be part of the upcoming 2.4.48 release. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8674) Leak in ldap_create_assertion_control
by ondra＠mistotebe.net 14 Jun '19

14 Jun '19

On Thu, Sep 07, 2017 at 03:42:50PM +0000, come(a)opensides.be wrote: > Hello, > > I encountered this bug as well while adding controls support into > php-ldap (see https://github.com/php/php-src/pull/2640 - WIP) > I used the work-around but it would still be better to fix this in > openldap. Hi Côme, thank you for your work, your patch has been pushed to master (2cac3ceb03530e3afe741d4a7d4d7e21059a6a97) and will also be part (8e6d1b8b81e94f89027a120ea862bd5938e953c6) of the upcoming 2.4.48 release. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8167) The new non-blocking TLS connect does not work in a reference/referral
by ondra＠mistotebe.net 14 Jun '19

14 Jun '19

On Wed, Jun 10, 2015 at 12:39:19AM +0000, ipuleston(a)SonicWALL.com wrote: > I've now uploaded the patch to the ftp.openldap.org FTP server as "ian-pule= > ston-15069.patch". Hi Ian, thank you for your work, the patch has been pushed to master (46c93e41f43da7f16270179c6eff75e450617329) and will also be part (a8cf2fb10047794c83873f5ff5c125ecd0e53168) of the upcoming 2.4.48 release. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8450) race condition in ldap_int_utils_init
by ondra＠mistotebe.net 14 Jun '19

14 Jun '19

On Fri, Jun 24, 2016 at 08:04:27PM +0000, doug.leavitt(a)oracle.com wrote: > There is a race condition in ldap_int_utils_init that can be triggered when > multiple threads enter ldap_int_utils_init from ldap_init_initialize about the > same time. The done flag gets set immediately, before the various mutexes are > initialized. If thread A sets done, and thread B tests for done==1 before thread > A has completed the mutex inits, thread B can attempt to use an uninitialized > mutex and fail/core dump etc. > > Additionally if judt the done=1 is moved to the bottom of the function thwo > threads can both be initializing the same mutexes multiple times causes other > mayhem. > > The short term workaround for Solaris (THR APIs) is to move setting of done=1 to > after the mutex inits, and to protect the mutex inits using another statically > initialized mutex within ldap_int_utils_init. Hi Doug, a patch addressing this and ITS#7996 has been pushed to master (db40120a276c3b7968552e253aea24860fad5f60) and will also be part (cde56fad154fcd25e351c3cd84d8173d263b0a01) of the upcoming 2.4.48 release. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#7996) Global initialisation race in ldap_int_initialize
by ondra＠mistotebe.net 14 Jun '19

14 Jun '19

On Fri, Sep 08, 2017 at 02:07:19PM +0000, quanah(a)symas.com wrote: > --On Friday, September 08, 2017 1:02 PM +0000 a.cudbardb(a)freeradius.org > wrote: >>> Thanks for the report and sorry for the delay on getting to this >>> issue. I would note that for the fix to be included in the OpenLDAP >>> project, we need an IPR statement, as noted at >>> <https://www.openldap.org/devel/contributing.html>. If you can >>> provide that, and (if possible) submit the patch as git format-patch >>> via the project FTP server (include the URL in your email), then I >>> can pull it in. >> >> IPR statement is not a problem, but I don't have the original diff to = >> work from. If you can send me a copy of the FTP submission I can = >> reformat it and resubmit it. > > Hi Arran, > > The diff is in your github issues tracker. ;) > > <https://github.com/arr2036/ldapperf/issues/2#issuecomment-66242732> Hi Arran, thank you for your work, a patch addressing this has been pushed to master (db40120a276c3b7968552e253aea24860fad5f60) and will also be part (cde56fad154fcd25e351c3cd84d8173d263b0a01) of the upcoming 2.4.48 release. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#7042) [PATCH] allow unsetting of tls_* options for syncrepl
by ondra＠mistotebe.net 14 Jun '19

14 Jun '19

On Sat, Oct 21, 2017 at 03:50:48PM +0000, patrick(a)monnerat.net wrote: > Hi Quanah, > Thanks for your directives and future action. Hi Patrick, thank you for your patch, it has now been pushed to master (0f9afae02d9425e54f070ecd5ea8b954115e092b) and will also be part (e5f945bab40482e2045fede3fbe9a04210808a93) of the upcoming 2.4.48 release. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#9034) LDMB: 0.9.22/3: initial mdb_env_set_mapsize() is problematic
by hyc＠symas.com 14 Jun '19

14 Jun '19

steffen(a)sdaoden.eu wrote: > Full_Name: Steffen Nurpmeso > Version: 0.9.23 > OS: Linux > URL: https://ftp.sdaoden.eu/lmdb-bogo.tar.xz > Submission from: (NULL) (109.40.130.211) > > > A follow-up to private communication with Quanah Gibson-Mount. > You can find more in the tarball linked below. The code works as designed. No changes to mapsize handling were made between 0.9.22 and 0.9.23. Closing this ITS. -- -- 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#9036) LDMB: 0.9.23: mdb_env_info() does not report latest mapsize() after transaction abort
by hyc＠symas.com 14 Jun '19

14 Jun '19

steffen(a)sdaoden.eu wrote: > Full_Name: Steffen Nurpmeso > Version: 0.9.23 > OS: Linux > URL: https://ftp.sdaoden.eu/lmdb-bogo.tar.xz > Submission from: (NULL) (109.40.130.211) > > > A follow-up to private communication with Quanah Gibson-Mount. > You can find more in the tarball linked below > > Your README states that the behavior in LMDB 0.9.23 is different than in 0.9.22 but that is incorrect. No changes to set_mapsize() behavior were made between 0.9.22 and 0.9.23. Closing this ITS. -- -- 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#9035) LDMB: 0.9.23: mdb_env_set_maxreaders() not honoured?
by hyc＠symas.com 14 Jun '19

14 Jun '19

steffen(a)sdaoden.eu wrote: > Full_Name: Steffen Nurpmeso > Version: 0.9.23 > OS: Linux > URL: https://ftp.sdaoden.eu/lmdb-bogo.tar.xz > Submission from: (NULL) (109.40.130.211) > > > A follow-up to private communication with Quanah Gibson-Mount. > You can find more in the tarball linked below The maxreaders setting doesn't persist after all processes have closed the environment. Therefore it returns to its default value when the next process opens the environment. The code works as designed. There is no bug here. Closing this ITS. -- -- 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

(ITS#9036) LDMB: 0.9.23: mdb_env_info() does not report latest mapsize() after transaction abort
by steffen＠sdaoden.eu 14 Jun '19

14 Jun '19

Full_Name: Steffen Nurpmeso Version: 0.9.23 OS: Linux URL: https://ftp.sdaoden.eu/lmdb-bogo.tar.xz Submission from: (NULL) (109.40.130.211) A follow-up to private communication with Quanah Gibson-Mount. You can find more in the tarball linked below

1 0

(ITS#9035) LDMB: 0.9.23: mdb_env_set_maxreaders() not honoured?
by steffen＠sdaoden.eu 14 Jun '19

14 Jun '19

Full_Name: Steffen Nurpmeso Version: 0.9.23 OS: Linux URL: https://ftp.sdaoden.eu/lmdb-bogo.tar.xz Submission from: (NULL) (109.40.130.211) A follow-up to private communication with Quanah Gibson-Mount. You can find more in the tarball linked below

1 0

(ITS#9034) LDMB: 0.9.22/3: initial mdb_env_set_mapsize() is problematic
by steffen＠sdaoden.eu 14 Jun '19

14 Jun '19

Full_Name: Steffen Nurpmeso Version: 0.9.23 OS: Linux URL: https://ftp.sdaoden.eu/lmdb-bogo.tar.xz Submission from: (NULL) (109.40.130.211) A follow-up to private communication with Quanah Gibson-Mount. You can find more in the tarball linked below.

1 0

Re: (ITS#9033) Computer Object
by quanah＠symas.com 13 Jun '19

13 Jun '19

--On Thursday, June 13, 2019 12:43 PM +0000 jgbuenaventura(a)gmail.com wrote: > Hi, > > I am trying to add a computer/network device (windows, linux, routers) in > Openldap, but i cannot find a specific, schema/objectclass/attribute for > that. Any advice? Hello, The ITS system is for reporting bugs, not asking usage questions. Please use the openldap-technical(a)openldap.org mailing lists for questions such as those above (<https://www.openldap.org/lists/mm/listinfo/openldap-technical>). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9033) Computer Object
by jgbuenaventura＠gmail.com 13 Jun '19

13 Jun '19

Full_Name: JP Buenaventura Version: 2.4.45 OS: Rhel 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (222.127.115.105) Hi, I am trying to add a computer/network device (windows, linux, routers) in Openldap, but i cannot find a specific, schema/objectclass/attribute for that. Any advice? Thanks! JP

1 0

Re: (ITS#9032) need to create custom attributes in openldap schema
by ryan＠nardis.ca 09 Jun '19

09 Jun '19

Hello Suresh, The ITS is for reporting bugs, not for usage questions. For support, please write to the openldap-technical(a)openldap.org mailing list. See https://www.openldap.org/support/ for more details. This ITS will be closed. Thank you, Ryan.

1 0

(ITS#9032) need to create custom attributes in openldap schema
by sureshd＠nihontechnology.com 08 Jun '19

08 Jun '19

Full_Name: Suresh Dhayalan Version: 1.2.2 OS: ubuntu 18.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (164.164.10.1) Dear sir, I need to create custom schema attributes, in my AWS cloud I am using ubuntu 18.6. I will create additional attributes to my project related apart from in build attributes, so kindly send me the steps to create my custom attributes. Regards, D Suresh

1 0

Re: (ITS#8988) Undefined Behavior in slapadd
by hyc＠symas.com 08 Jun '19

08 Jun '19

Jeffrey Walton wrote: > On Sat, Jun 8, 2019 at 3:47 AM Howard Chu <hyc(a)symas.com> wrote: >> >> Jeffrey Walton wrote: >>> On Fri, Jun 7, 2019 at 2:37 PM Howard Chu <hyc(a)symas.com> wrote: >>>> >>>> Jeffrey Walton wrote: >>>>> On Fri, Jun 7, 2019 at 10:08 AM Howard Chu <hyc(a)symas.com> wrote: >>>>>> >>>>>> Jeffrey Walton wrote: >>>>>>> On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote: >>>>>>>> >>>>>>>> noloader(a)gmail.com wrote: >>>>>>>>> On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: >>>>>>>>>> >>>>>>>>>> noloader(a)gmail.com wrote: >>>>>>>>>> ... >>>>>>>>>>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an >>>>>>>>>>> important project, and the undefined behavior is causing too many >>>>>>>>>>> tangential problems. >>>>>>>>>> >>>>>>>>>> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary >>>>>>>>>> part of the language for its intended use as a system programming language, writing >>>>>>>>>> machine-specific programs. Anyone who says it is prohibited by the spec is wrong. >>>>>>>>> >>>>>>>>> I don't believe this is correct. >>>>>>>>> >>>>>>>>> Maybe you are thinking of implementation defined behavior? >>>>>>>> >>>>>>>> That would apply to how a particular compiler implementation treats some piece of code. >>>>>>>> Whether a CPU supports unaligned access is machine-defined. Since our code is already >>>>>>>> properly ifdef'd for the machines which do or don't support it, the fact that this is >>>>>>>> "non-portable" is not an issue. >>>>>>> >>>>>>> The undefined behavior is causing OpenLDAP to fail testing. >>>>>>> >>>>>>> Worse, it is causing test failures in programs and libraries which use >>>>>>> OpenLDAP. The OpenLDAP bugs have cross-pollinated into other programs >>>>>>> and libraries. It is not simply contained or limited to OpenLDAP. >>>>>>> >>>>>>> That's a big problem for testing a QA folks. >>>>>> >>>>>> Then the tests are broken, because these are not bugs. >>>>> >>>>> They are absolutely OpenLDAP bugs. The unaligned accesses are >>>>> Undefined Behavior. >>>> >>>> Simply because the C standard doesn't specify what the behavior is doesn't make it a bug. >>> >>> The C standard does specify the behavior. It falls clearly in >>> Undefined Behavior. >> >> The fact a behavior is undefined does not make it illegal. > > A program with undefined behavior is, by definition, and illegal program. This is pure nonsense. You realize, don't you, that the C spec has no definition of threads? All multithreaded programs are using undefined behavior. And yet here we are, using threads for over 2 decades. The gcc/clang folks have their heads up their asses. They've deliberately misinterpreted the spec claiming undefined behaviors are forbidden, supposedly to enable essential optimizations. Most of which only apply to obscure corner cases in compiler benchmark suites, that nobody in the real world ever benefits from. -- -- 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#8988) Undefined Behavior in slapadd
by noloader＠gmail.com 08 Jun '19

08 Jun '19

On Sat, Jun 8, 2019 at 3:47 AM Howard Chu <hyc(a)symas.com> wrote: > > Jeffrey Walton wrote: > > On Fri, Jun 7, 2019 at 2:37 PM Howard Chu <hyc(a)symas.com> wrote: > >> > >> Jeffrey Walton wrote: > >>> On Fri, Jun 7, 2019 at 10:08 AM Howard Chu <hyc(a)symas.com> wrote: > >>>> > >>>> Jeffrey Walton wrote: > >>>>> On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote: > >>>>>> > >>>>>> noloader(a)gmail.com wrote: > >>>>>>> On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: > >>>>>>>> > >>>>>>>> noloader(a)gmail.com wrote: > >>>>>>>> ... > >>>>>>>>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an > >>>>>>>>> important project, and the undefined behavior is causing too many > >>>>>>>>> tangential problems. > >>>>>>>> > >>>>>>>> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary > >>>>>>>> part of the language for its intended use as a system programming language, writing > >>>>>>>> machine-specific programs. Anyone who says it is prohibited by the spec is wrong. > >>>>>>> > >>>>>>> I don't believe this is correct. > >>>>>>> > >>>>>>> Maybe you are thinking of implementation defined behavior? > >>>>>> > >>>>>> That would apply to how a particular compiler implementation treats some piece of code. > >>>>>> Whether a CPU supports unaligned access is machine-defined. Since our code is already > >>>>>> properly ifdef'd for the machines which do or don't support it, the fact that this is > >>>>>> "non-portable" is not an issue. > >>>>> > >>>>> The undefined behavior is causing OpenLDAP to fail testing. > >>>>> > >>>>> Worse, it is causing test failures in programs and libraries which use > >>>>> OpenLDAP. The OpenLDAP bugs have cross-pollinated into other programs > >>>>> and libraries. It is not simply contained or limited to OpenLDAP. > >>>>> > >>>>> That's a big problem for testing a QA folks. > >>>> > >>>> Then the tests are broken, because these are not bugs. > >>> > >>> They are absolutely OpenLDAP bugs. The unaligned accesses are > >>> Undefined Behavior. > >> > >> Simply because the C standard doesn't specify what the behavior is doesn't make it a bug. > > > > The C standard does specify the behavior. It falls clearly in > > Undefined Behavior. > > The fact a behavior is undefined does not make it illegal. A program with undefined behavior is, by definition, and illegal program. > > And Appendix J.2, Undefined Behavior, says: > > > > Conversion between two pointer types produces a result > > that is incorrectly aligned (6.3.2.3). > > > > You are violating the C standard in macros like COPY_PGNO. Effectively > > you are casting a uint8_t array to an uint16_t*. You cannot do that > > because uint16_t* increases the alignment requirements. > > All internal fields of LMDB are (at least) 2-byte aligned, so these copies always > meet alignment requirements. No, they are not. Some of them are 1-byte aligned. UBsan tells you that. Others require 4-byte alignment. UBsan tells you that, too. Jeff

1 0

Re: (ITS#8988) Undefined Behavior in slapadd
by hyc＠symas.com 08 Jun '19

08 Jun '19

Jeffrey Walton wrote: > On Fri, Jun 7, 2019 at 2:37 PM Howard Chu <hyc(a)symas.com> wrote: >> >> Jeffrey Walton wrote: >>> On Fri, Jun 7, 2019 at 10:08 AM Howard Chu <hyc(a)symas.com> wrote: >>>> >>>> Jeffrey Walton wrote: >>>>> On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote: >>>>>> >>>>>> noloader(a)gmail.com wrote: >>>>>>> On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: >>>>>>>> >>>>>>>> noloader(a)gmail.com wrote: >>>>>>>> ... >>>>>>>>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an >>>>>>>>> important project, and the undefined behavior is causing too many >>>>>>>>> tangential problems. >>>>>>>> >>>>>>>> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary >>>>>>>> part of the language for its intended use as a system programming language, writing >>>>>>>> machine-specific programs. Anyone who says it is prohibited by the spec is wrong. >>>>>>> >>>>>>> I don't believe this is correct. >>>>>>> >>>>>>> Maybe you are thinking of implementation defined behavior? >>>>>> >>>>>> That would apply to how a particular compiler implementation treats some piece of code. >>>>>> Whether a CPU supports unaligned access is machine-defined. Since our code is already >>>>>> properly ifdef'd for the machines which do or don't support it, the fact that this is >>>>>> "non-portable" is not an issue. >>>>> >>>>> The undefined behavior is causing OpenLDAP to fail testing. >>>>> >>>>> Worse, it is causing test failures in programs and libraries which use >>>>> OpenLDAP. The OpenLDAP bugs have cross-pollinated into other programs >>>>> and libraries. It is not simply contained or limited to OpenLDAP. >>>>> >>>>> That's a big problem for testing a QA folks. >>>> >>>> Then the tests are broken, because these are not bugs. >>> >>> They are absolutely OpenLDAP bugs. The unaligned accesses are >>> Undefined Behavior. >> >> Simply because the C standard doesn't specify what the behavior is doesn't make it a bug. > > The C standard does specify the behavior. It falls clearly in > Undefined Behavior. The fact a behavior is undefined does not make it illegal. > And Appendix J.2, Undefined Behavior, says: > > Conversion between two pointer types produces a result > that is incorrectly aligned (6.3.2.3). > > You are violating the C standard in macros like COPY_PGNO. Effectively > you are casting a uint8_t array to an uint16_t*. You cannot do that > because uint16_t* increases the alignment requirements. All internal fields of LMDB are (at least) 2-byte aligned, so these copies always meet alignment requirements. -- -- 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#8988) Undefined Behavior in slapadd
by noloader＠gmail.com 08 Jun '19

08 Jun '19

On Fri, Jun 7, 2019 at 2:37 PM Howard Chu <hyc(a)symas.com> wrote: > > Jeffrey Walton wrote: > > On Fri, Jun 7, 2019 at 10:08 AM Howard Chu <hyc(a)symas.com> wrote: > >> > >> Jeffrey Walton wrote: > >>> On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote: > >>>> > >>>> noloader(a)gmail.com wrote: > >>>>> On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: > >>>>>> > >>>>>> noloader(a)gmail.com wrote: > >>>>>> ... > >>>>>>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an > >>>>>>> important project, and the undefined behavior is causing too many > >>>>>>> tangential problems. > >>>>>> > >>>>>> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary > >>>>>> part of the language for its intended use as a system programming language, writing > >>>>>> machine-specific programs. Anyone who says it is prohibited by the spec is wrong. > >>>>> > >>>>> I don't believe this is correct. > >>>>> > >>>>> Maybe you are thinking of implementation defined behavior? > >>>> > >>>> That would apply to how a particular compiler implementation treats some piece of code. > >>>> Whether a CPU supports unaligned access is machine-defined. Since our code is already > >>>> properly ifdef'd for the machines which do or don't support it, the fact that this is > >>>> "non-portable" is not an issue. > >>> > >>> The undefined behavior is causing OpenLDAP to fail testing. > >>> > >>> Worse, it is causing test failures in programs and libraries which use > >>> OpenLDAP. The OpenLDAP bugs have cross-pollinated into other programs > >>> and libraries. It is not simply contained or limited to OpenLDAP. > >>> > >>> That's a big problem for testing a QA folks. > >> > >> Then the tests are broken, because these are not bugs. > > > > They are absolutely OpenLDAP bugs. The unaligned accesses are > > Undefined Behavior. > > Simply because the C standard doesn't specify what the behavior is doesn't make it a bug. The C standard does specify the behavior. It falls clearly in Undefined Behavior. > It would be unreasonable to expect the standards body to exhaustively list all of the > possible behaviors on all of the possible hardware architectures that the language is > implemented for. Leaving it undefined in the spec only means they chose not to specify > a behavior. That means the actual behavior depends on the underlying machine. On the > x86 family the behavior is well defined. You seem to have a misunderstanding of the standard and unaligned accesses. You also seem to be conflating two different concepts. First, unaligned accesses, are undefined behavior. They are forbidden by the standard in 6.3.2.3 Pointers: 7. A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined. And Appendix J.2, Undefined Behavior, says: Conversion between two pointer types produces a result that is incorrectly aligned (6.3.2.3). You are violating the C standard in macros like COPY_PGNO. Effectively you are casting a uint8_t array to an uint16_t*. You cannot do that because uint16_t* increases the alignment requirements. Tools like UBsan are telling you when you violate the rules. They specifically flagged COPY_PGNO as incurring undefined behavior. (Tools like UBsan will miss some UB, but that's a different error and not applicable to this discussion). You insistence on claiming the code is correct is befuddling. You are effectively saying the world is wrong, including the C standard, the compiler writers, other projects, the QA personnel testing the software and users like me. There's nothing special about me being wrong. I've had to acknowledged that often. However, I would take pause in claiming the C standard is wrong or the compiler writers, like GCC and LLVM devs, are wrong. That's pretty bold. Second, conflating concepts, is the difference between the C standard and processor capabilities. The C code has undefined behavior, and it does not matter what the processor is capable of. And it does not matter if the compiler decides to generate code that performs unaligned accesses. The compiler is free to do what it wants, even when it frustrates the user or makes the user envious. However, you cannot wrote code that uses unaligned objects even though the compiler may generate equivalent code. Jeff

1 0

Re: (ITS#8988) Undefined Behavior in slapadd
by hyc＠symas.com 07 Jun '19

07 Jun '19

Howard Chu wrote: > hyc(a)symas.com wrote: >> Jeffrey Walton wrote: >>> On Fri, Jun 7, 2019 at 10:08 AM Howard Chu <hyc(a)symas.com> wrote: >>>> >>>> Jeffrey Walton wrote: >>>>> On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote: >>>>>> >>>>>> noloader(a)gmail.com wrote: >>>>>>> On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: >>>>>>>> >>>>>>>> noloader(a)gmail.com wrote: >>>>>>>> ... >>>>>>>>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an >>>>>>>>> important project, and the undefined behavior is causing too many >>>>>>>>> tangential problems. >>>>>>>> >>>>>>>> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary >>>>>>>> part of the language for its intended use as a system programming language, writing >>>>>>>> machine-specific programs. Anyone who says it is prohibited by the spec is wrong. >>>>>>> >>>>>>> I don't believe this is correct. >>>>>>> >>>>>>> Maybe you are thinking of implementation defined behavior? >>>>>> >>>>>> That would apply to how a particular compiler implementation treats some piece of code. >>>>>> Whether a CPU supports unaligned access is machine-defined. Since our code is already >>>>>> properly ifdef'd for the machines which do or don't support it, the fact that this is >>>>>> "non-portable" is not an issue. >>>>> >>>>> The undefined behavior is causing OpenLDAP to fail testing. >>>>> >>>>> Worse, it is causing test failures in programs and libraries which use >>>>> OpenLDAP. The OpenLDAP bugs have cross-pollinated into other programs >>>>> and libraries. It is not simply contained or limited to OpenLDAP. >>>>> >>>>> That's a big problem for testing a QA folks. >>>> >>>> Then the tests are broken, because these are not bugs. >>> >>> They are absolutely OpenLDAP bugs. The unaligned accesses are >>> Undefined Behavior. >> >> Simply because the C standard doesn't specify what the behavior is doesn't make it a bug. >> It would be unreasonable to expect the standards body to exhaustively list all of the >> possible behaviors on all of the possible hardware architectures that the language is >> implemented for. Leaving it undefined in the spec only means they chose not to specify >> a behavior. That means the actual behavior depends on the underlying machine. On the >> x86 family the behavior is well defined. > > Also note: Behaviors are left undefined when they are non-portable. But being non-portable > isn't illegal in C. The entire purpose of conditional compilation is to support non-portable > code. > Worth reading https://www.yodaiken.com/2018/12/31/undefined-behavior-and-the-purpose-of-c/ -- -- 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#8988) Undefined Behavior in slapadd
by hyc＠symas.com 07 Jun '19

07 Jun '19

hyc(a)symas.com wrote: > Jeffrey Walton wrote: >> On Fri, Jun 7, 2019 at 10:08 AM Howard Chu <hyc(a)symas.com> wrote: >>> >>> Jeffrey Walton wrote: >>>> On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote: >>>>> >>>>> noloader(a)gmail.com wrote: >>>>>> On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: >>>>>>> >>>>>>> noloader(a)gmail.com wrote: >>>>>>> ... >>>>>>>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an >>>>>>>> important project, and the undefined behavior is causing too many >>>>>>>> tangential problems. >>>>>>> >>>>>>> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary >>>>>>> part of the language for its intended use as a system programming language, writing >>>>>>> machine-specific programs. Anyone who says it is prohibited by the spec is wrong. >>>>>> >>>>>> I don't believe this is correct. >>>>>> >>>>>> Maybe you are thinking of implementation defined behavior? >>>>> >>>>> That would apply to how a particular compiler implementation treats some piece of code. >>>>> Whether a CPU supports unaligned access is machine-defined. Since our code is already >>>>> properly ifdef'd for the machines which do or don't support it, the fact that this is >>>>> "non-portable" is not an issue. >>>> >>>> The undefined behavior is causing OpenLDAP to fail testing. >>>> >>>> Worse, it is causing test failures in programs and libraries which use >>>> OpenLDAP. The OpenLDAP bugs have cross-pollinated into other programs >>>> and libraries. It is not simply contained or limited to OpenLDAP. >>>> >>>> That's a big problem for testing a QA folks. >>> >>> Then the tests are broken, because these are not bugs. >> >> They are absolutely OpenLDAP bugs. The unaligned accesses are >> Undefined Behavior. > > Simply because the C standard doesn't specify what the behavior is doesn't make it a bug. > It would be unreasonable to expect the standards body to exhaustively list all of the > possible behaviors on all of the possible hardware architectures that the language is > implemented for. Leaving it undefined in the spec only means they chose not to specify > a behavior. That means the actual behavior depends on the underlying machine. On the > x86 family the behavior is well defined. Also note: Behaviors are left undefined when they are non-portable. But being non-portable isn't illegal in C. The entire purpose of conditional compilation is to support non-portable code. -- -- 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#8988) Undefined Behavior in slapadd
by hyc＠symas.com 07 Jun '19

07 Jun '19

Jeffrey Walton wrote: > On Fri, Jun 7, 2019 at 10:08 AM Howard Chu <hyc(a)symas.com> wrote: >> >> Jeffrey Walton wrote: >>> On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote: >>>> >>>> noloader(a)gmail.com wrote: >>>>> On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: >>>>>> >>>>>> noloader(a)gmail.com wrote: >>>>>> ... >>>>>>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an >>>>>>> important project, and the undefined behavior is causing too many >>>>>>> tangential problems. >>>>>> >>>>>> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary >>>>>> part of the language for its intended use as a system programming language, writing >>>>>> machine-specific programs. Anyone who says it is prohibited by the spec is wrong. >>>>> >>>>> I don't believe this is correct. >>>>> >>>>> Maybe you are thinking of implementation defined behavior? >>>> >>>> That would apply to how a particular compiler implementation treats some piece of code. >>>> Whether a CPU supports unaligned access is machine-defined. Since our code is already >>>> properly ifdef'd for the machines which do or don't support it, the fact that this is >>>> "non-portable" is not an issue. >>> >>> The undefined behavior is causing OpenLDAP to fail testing. >>> >>> Worse, it is causing test failures in programs and libraries which use >>> OpenLDAP. The OpenLDAP bugs have cross-pollinated into other programs >>> and libraries. It is not simply contained or limited to OpenLDAP. >>> >>> That's a big problem for testing a QA folks. >> >> Then the tests are broken, because these are not bugs. > > They are absolutely OpenLDAP bugs. The unaligned accesses are > Undefined Behavior. Simply because the C standard doesn't specify what the behavior is doesn't make it a bug. It would be unreasonable to expect the standards body to exhaustively list all of the possible behaviors on all of the possible hardware architectures that the language is implemented for. Leaving it undefined in the spec only means they chose not to specify a behavior. That means the actual behavior depends on the underlying machine. On the x86 family the behavior is well defined. -- -- 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#8988) Undefined Behavior in slapadd
by noloader＠gmail.com 07 Jun '19

07 Jun '19

On Fri, Jun 7, 2019 at 10:08 AM Howard Chu <hyc(a)symas.com> wrote: > > Jeffrey Walton wrote: > > On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote: > >> > >> noloader(a)gmail.com wrote: > >>> On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: > >>>> > >>>> noloader(a)gmail.com wrote: > >>>> ... > >>>>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an > >>>>> important project, and the undefined behavior is causing too many > >>>>> tangential problems. > >>>> > >>>> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary > >>>> part of the language for its intended use as a system programming language, writing > >>>> machine-specific programs. Anyone who says it is prohibited by the spec is wrong. > >>> > >>> I don't believe this is correct. > >>> > >>> Maybe you are thinking of implementation defined behavior? > >> > >> That would apply to how a particular compiler implementation treats some piece of code. > >> Whether a CPU supports unaligned access is machine-defined. Since our code is already > >> properly ifdef'd for the machines which do or don't support it, the fact that this is > >> "non-portable" is not an issue. > > > > The undefined behavior is causing OpenLDAP to fail testing. > > > > Worse, it is causing test failures in programs and libraries which use > > OpenLDAP. The OpenLDAP bugs have cross-pollinated into other programs > > and libraries. It is not simply contained or limited to OpenLDAP. > > > > That's a big problem for testing a QA folks. > > Then the tests are broken, because these are not bugs. They are absolutely OpenLDAP bugs. The unaligned accesses are Undefined Behavior. * https://stackoverflow.com/a/46790815/608639 * https://stackoverflow.com/a/46790813/608639 * https://stackoverflow.com/a/28895321/608639 * https://stackoverflow.com/a/51126453/608639 * https://stackoverflow.com/q/39908946/608639 ... I get that you think your project is fine. Many folks take that myopic view of the world. I call it the greedy model. Greedy models show up all over the place. For example, every website that requires a different account and different 16 character password. That's the greedy password model where a site think it is the only one someone visits. What baffles me is your insistence on polluting other program and library results. That's not your place to screw up testing for other programs and libraries. Jeff

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs