On Fri, Mar 4, 2016 at 3:43 AM, Patricia Shanahan <p...@acm.org> wrote: > 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 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 for people to migrate off a >>> deprecated interface. >> >> [orcmid] >> >> I think the extensions and plugins depend on UNO objects. So long as that >> is the case, the profile code should be unreachable. > > > I have found a file main/sal/util/sal.map that begins with: > > UDK_3_0_0 { > global: > GetVersionInfo; > osl_acceptConnectionOnSocket; > osl_acceptPipe; > osl_acquireSocket; > osl_acquirePipe; > osl_acquireMutex; > osl_acquireSemaphore; > osl_addSignalHandler; > osl_addToSocketSet; > osl_assertFailedLine; > osl_bindAddrToSocket; > osl_breakDebug; > osl_checkCondition; > osl_clearSocketSet; > osl_closeDirectory; > osl_closePipe; > osl_closeProfile; > ... > > and goes on to mention several other profile.c /osl_.*Profile.*/ function > names in the same list.
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 loaded through arbitrary layers of indirection. For example, compiling AOO with GCC on recent FreeBSD easily crashes AOO because both GCC's and Clang's C++ runtime libraries are loaded, their symbols clash with each other, and their ABIs are not fully compatible -> memory corruption -> undebuggable crash. Symbol map files are supposed to work around the problem because the UDK_3_0_0 becomes part of the symbol name and makes it more globally unique. I don't know if UDK_3_0_0 is correct since we are on AOO version 4 now (or do we version UDK differently?). Also UNO is all good in theory, but in practice plugins can always use run-time dynamic linking to load any library and call any exported function (which the profile functions are) - even when running in a separate process, or written a different language (eg. JNA/BridJ for Java). Whether they actually do this in practice is the more important question. > Unfortunately, I am seeing some indications that "UDK" relates to UNO. > > At the worst, the deprecation just means that other modules are supposed to > access the profile only through UNO, not by including the header file and > calling the functions directly. > > Patricia > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
