[geos-devel] Thread safe error handling

Pepijn Van Eeckhoudt pepijn at vaneeckhoudt.net
Mon Sep 9 04:41:24 PDT 2013


On ma, 2013-09-09 at 13:00 +0200, Sandro Santilli wrote:
> On Mon, Sep 09, 2013 at 12:37:02PM +0200, Pepijn Van Eeckhoudt wrote:
> > On ma, 2013-09-09 at 10:49 +0200, Sandro Santilli wrote:
> > > On Mon, Sep 09, 2013 at 09:43:51AM +0200, Pepijn Van Eeckhoudt wrote:
> > > Can't we turn NOTICE_MESSAGE and ERROR_MESSAGE into variadic methods
> > > of the GEOSContextHandlerInternal class ? We could print to a string
> > > and always pass a single string to the user-provided function, using
> > > an hardcoded "%s" format for it.
> >
> > Not sure if I understand this correctly. Do you mean you would do the
> > actual formatting on the geos side and pass the formatted string as
> > 'fmt' then? That would work if you're ok with the subtle behavioural
> > change. Seems unlikely that anyone would count on the exact contents of
> > 'fmt' and the parameter list, but you never know...
> 
> I'd pass "%s" as the 'fmt' arg, and a pointer to a geos-owned memory
> space as the only argument. No client should be expecting anything
> from those calls, except they'd be composed by a printf-like format
> and a variable list of arguments which work fine with that format.
I have to admit C++ is a very, very long time ago for me. Is it possible
to call one variadic function from another one in C++? If not, how would
you delegate from notice(handle,void*,fmt,...) (or the hypothetical
method on a C++ class) to the current notice(fmt,...)? I think this is
necessary to avoid breaking the ABI, no?

> > Memory allocation for the formatted string shifts to geos then as well;
> > do you think that's an issue?
> 
> I don't see any issue there, clients would still need to re-print
> the returned string. Only, we'll need a buffer for messages in each
> GEOSContextHandlerInternal instance.
Ok, one thing less to worry about.

Pepijn



More information about the geos-devel mailing list