On Nov  3 12:15, Christian Franke wrote:
> Mark Geisert wrote:
> > On 10/22/2024 7:45 AM, Corinna Vinschen wrote:
> > > - create a new function like pthread_sigqueue_with_correct_prototype
> > > (heh)
> > > 
> > > - Add this function to cygwin.din as exported symbol
> > > 
> > > - Add a matching entry to NEW_FUNCTIONS in Makefile.am, e.g.,
> > > 
> > >      pthread_sigqueue=pthread_sigqueue_with_correct_prototype,
> > > 
> > > - Implement either pthread_sigqueue_with_correct_prototype calling
> > >    pthread_sigqueue or vice versa, whatever makese more sense.
> > 
> > I appreciate your redirecting me towards an acceptable solution. I've
> > re-implemented the fix as you've indicated but there's one thing I
> > cannot figure out. (BTW I implemented a new pthread_sigqueue_portable()
> > calling existing pthread_sigqueue().)
> > 
> > In cygwin/include/pthread.h, should both function names appear or just
> > pthread_sigqueue? If the latter, which version of prototype? It seems
> > problematic: We want the include file to have the new, portable,
> > prototype for pthread_sigqueue() don't we? Doesn't that require that the
> > original pthread_sigqueue() be renamed to something else and have it
> > call the new pthread_sigqueue()? Maybe that changes one or more of the
> > steps you wrote above?
> 
> If backward compatibility with existing binaries using pthread_sigqueue() is
> desired, I would suggest:
> - Keep functionality and export symbol of the existing pthread_sigqueue().
> - Use a different export symbol for the new function.
> - By default, map the pthread_sigqueue() call to the new symbol.

That's pretty much what I said above, I just tried to explain how
to do that in Cygwin.

> - Invent a #define that allows to use the old function.

We don't need this.  We only want backward compat to keep existing
executables running.  So we need The old and wrong pthread_sigqueue only
as exported symbol.  On recompiling the affected project, the bug
hopefully shows up and can be easily fixed.


Corinna

Reply via email to