Re: Profile.c bugs (was RE: Some thoughts on the learning curve)

In the short term, incremental and iterative can go well, but in the long term it only makes the bit rot worse. I have had bad experiences both ways, so neither course guarantees success. Thread synchronization is a particularly dangerous area for not having a known design, because it can lead

RE: Profile.c bugs (was RE: Some thoughts on the learning curve)

.c bugs (was RE: Some thoughts on the learning > curve) > > On 3/4/2016 9:39 AM, Dennis E. Hamilton wrote: > > Patricia, > > > > Based on Damjan's finding that profile files are read by the > > application and that some are created during setup, with ot

Re: Profile.c bugs (was RE: Some thoughts on the learning curve)

On 3/4/2016 9:39 AM, Dennis E. Hamilton wrote: Patricia, Based on Damjan's finding that profile files are read by the application and that some are created during setup, with others copied in from the setup, it is settled that the code is used in current distributions and is also available to

RE: Profile.c bugs (was RE: Some thoughts on the learning curve)

Damjan, A question below. > -Original Message- > From: Damjan Jovanovic [mailto:dam...@apache.org] > Sent: Friday, March 4, 2016 04:41 > To: Apache OO <dev@openoffice.apache.org> > Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning > curve) >

RE: Profile.c bugs (was RE: Some thoughts on the learning curve)

attention. - Dennis > -Original Message- > From: Patricia Shanahan [mailto:p...@acm.org] > Sent: Friday, March 4, 2016 05:23 > To: dev@openoffice.apache.org > Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning > curve) > > > > On

Re: Profile.c bugs (was RE: Some thoughts on the learning curve)

On 3/3/2016 5:00 PM, Dennis E. Hamilton wrote: -Original Message- From: Patricia Shanahan [mailto:p...@acm.org] ... I am curious about whether it started out with pthread_mutex uses and lost them along the way, or whether that difference between unx and w32 is primordial. [orcmid]

Re: Profile.c bugs (was RE: Some thoughts on the learning curve)

On 3/4/2016 4:40 AM, Damjan Jovanovic wrote: On Fri, Mar 4, 2016 at 11:59 AM, Patricia Shanahan wrote: On 3/4/2016 12:54 AM, Damjan Jovanovic wrote: ELF binaries (Linux, *BSD) fundamentally use one of the worst ideas of all time: symbols are process scoped (unlike on Windows

Re: Profile.c bugs (was RE: Some thoughts on the learning curve)

On 3/4/2016 12:54 AM, Damjan Jovanovic wrote: ELF binaries (Linux, *BSD) fundamentally use one of the worst ideas of all time: symbols are process scoped (unlike on Windows and MacOS where they're library scoped), meaning that symbols with the same name can clash even if in different libraries

Re: Profile.c bugs (was RE: Some thoughts on the learning curve)

On 3/3/2016 5:00 PM, Dennis E. Hamilton wrote: -Original Message- From: Patricia Shanahan [mailto:p...@acm.org] Sent: Thursday, March 3, 2016 14:38 To: dev@openoffice.apache.org Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning curve) I am seriously considering

Re: Profile.c bugs (was RE: Some thoughts on the learning curve)

>> To: dev@openoffice.apache.org >>> Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning >>> curve) >>> >>> I am seriously considering starting a project to eliminate profile.c >>> etc. and seeing what, if anything, breaks. >>>

RE: Profile.c bugs (was RE: Some thoughts on the learning curve)

ursday, March 3, 2016 17:43 > To: dev@openoffice.apache.org > Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning > curve) > > On 3/3/2016 5:00 PM, Dennis E. Hamilton wrote: > >> -Original Message- > >> From: Patricia Shanahan [mailto:

Re: Profile.c bugs (was RE: Some thoughts on the learning curve)

On 3/3/2016 5:00 PM, Dennis E. Hamilton wrote: -Original Message- From: Patricia Shanahan [mailto:p...@acm.org] Sent: Thursday, March 3, 2016 14:38 To: dev@openoffice.apache.org Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning curve) I am seriously considering starting

RE: Profile.c bugs (was RE: Some thoughts on the learning curve)

> -Original Message- > From: Patricia Shanahan [mailto:p...@acm.org] > Sent: Thursday, March 3, 2016 14:38 > To: dev@openoffice.apache.org > Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning > curve) > > I am seriously considering starting a projec

Re: Profile.c bugs (was RE: Some thoughts on the learning curve)

I am seriously considering starting a project to eliminate profile.c etc. and seeing what, if anything, breaks. Before I do that, I have a question about whether it could be accessed through any of OpenOffice's extension or plugin facilities? Even if it can, 14 years seems quite long enough

RE: Profile.c bugs (was RE: Some thoughts on the learning curve)

E. Hamilton [mailto:dennis.hamil...@acm.org] > Sent: Wednesday, March 2, 2016 11:42 > To: dev@openoffice.apache.org > Subject: RE: Profile.c bugs (was RE: Some thoughts on the learning > curve) > > > > > -Original Message- > > From: Patricia Shanahan [mail

Re: Profile.c bugs (was RE: Some thoughts on the learning curve)

Dennis, The build output from my Windows build contains the line: Compiling: sal/osl/w32/profile.cxx There appear to be three different implementations of the profile module, profile.c for "os2", profile.c for "unx", and profile.cxx for "w32". Only the "unx" version has pthread_mutex

Re: Profile.c bugs (was RE: Some thoughts on the learning curve)

On 3/1/2016 6:31 AM, Pedro Giffuni wrote: Hi Patricia; Good analysis, thank you! I think the operation is invalid. We can just comment out the code. FWIW, I looked at the SUN history to see if I could guess what the author pretended:

Re: Profile.c bugs (was RE: Some thoughts on the learning curve)

Hi Patricia; Good analysis, thank you! I think the operation is invalid. We can just comment out the code. FWIW, I looked at the SUN history to see if I could guess what the author pretended:

Re: Profile.c bugs (was RE: Some thoughts on the learning curve)

On 2/29/2016 7:41 PM, Pedro Giffuni wrote: Hello; FWIW, I have looked at i126669 and Coverity confirms there is a bug there. CID 440168 (#1 of 1): Dereference after null check (FORWARD_NULL)9. var_deref_model: Passing null pointer ">m_AccessLock" to function

Re: Profile.c bugs (was RE: Some thoughts on the learning curve)

Hello; FWIW, I have looked at i126669 and Coverity confirms there is a bug there. CID 440168 (#1 of 1): Dereference after null check (FORWARD_NULL)9. var_deref_model: Passing null pointer ">m_AccessLock" to function "pthread_mutex_unlock(pthread_mutex_t *)", which dereferences it. I suggest

Re: Profile.c bugs (was RE: Some thoughts on the learning curve)

I'll take a look at the results of my Windows build. It should be relatively easy to see if they are built at all. Built but not used is a bit harder, and may take some experiments. On 2/29/2016 11:02 AM, Dennis E. Hamilton wrote: Patricia, Take a look at main/sal/inc/osl/profile.h Methinks

Profile.c bugs (was RE: Some thoughts on the learning curve)

Patricia, Take a look at main/sal/inc/osl/profile.h Methinks that the code identified in might not be built for current releases on Windows or Linux. You'll see that there are filename suffixes such as .rc and .ini used. I doubt that has