Re: svn commit: r1086790 - /apr/apr/trunk/xml/apr_xml_internal.h
On Mon, 11 Apr 2011 15:14:00 -0400 Jeff Trawick wrote: > >> niq, is that to be exported eventually? No (since I still seem to owe you an answer - sorry). > how about changing the _ex to _internal? +1. I thought so more-or-less as soon as I'd committed. Didn't make the trivial change in case it got overtaken by events - like the whole thing blowing up on someone's platform and becoming a showstopper. -- Nick Kew Available for work, contract or permanent. http://www.webthing.com/~nick/cv.html
Re: svn commit: r1086790 - /apr/apr/trunk/xml/apr_xml_internal.h
Am 11.04.2011 21:14, schrieb Jeff Trawick: how about changing the _ex to _internal? sure, sounds better ... Gün.
Re: svn commit: r1086790 - /apr/apr/trunk/xml/apr_xml_internal.h
On Mon, Apr 11, 2011 at 3:11 PM, Guenter Knauf wrote:
> Jeff, Niq,
> Am 30.03.2011 01:26, schrieb Jeff Trawick:
>>
>> On Tue, Mar 29, 2011 at 7:09 PM, Guenter Knauf wrote:
>>>
>>> Am 30.03.2011 00:52, schrieb Guenter Knauf:
are you really sure this is the right thing? /me doubt ...
1. its in an internal header - if we want to expoert that function then
it should be moved to a public header
2. if you look into apr_xml.c you can find:
APR_DECLARE(apr_xml_parser *) apr_xml_parser_create(apr_pool_t *pool)
{
return apr_xml_parser_create_ex(pool,&start_handler,&end_handler,
&cdata_handler);
}
so why should something directly link against apr_xml_parser_create_ex()
?
>>>
>>> I dont find any other reference to apr_xml_parser_create_ex() beside the
>>> one
>>> in apr_xml.c; so I guess the linkage error happens because
>>> apr_xml_parser_create_ex() is wrongly marked for export in the C file,
>>> or?
>>
>> right, apr_xml_expat/libxml had API-style linkage
>>
>> xml/apr_xml_expat.c:APR_DECLARE(apr_xml_parser *)
>> apr_xml_parser_create_ex(apr_pool_t *pool,
>> xml/apr_xml_libxml2.c:APR_DECLARE(apr_xml_parser *)
>> apr_xml_parser_create_ex(apr_pool_t *pool,
>>
>> meanwhile, apr_xml_parser_create_ex() certainly *sounds* like an API
>>
>> niq, is that to be exported eventually? otherwise, the APR_DECLARE()
>> can be ripped off and the two implementations be given a less
>> API-sounding name
>
> I still dont believe we should export this function, and have just created
> the patch to remove he APR_DECLARE() - if there's shortly some proposal for
> a better name then I'll take that into account, otherwise I will commit the
> removal only within a hour -- unless someone screams :-)
how about changing the _ex to _internal?
Re: svn commit: r1086790 - /apr/apr/trunk/xml/apr_xml_internal.h
Jeff, Niq,
Am 30.03.2011 01:26, schrieb Jeff Trawick:
On Tue, Mar 29, 2011 at 7:09 PM, Guenter Knauf wrote:
Am 30.03.2011 00:52, schrieb Guenter Knauf:
are you really sure this is the right thing? /me doubt ...
1. its in an internal header - if we want to expoert that function then
it should be moved to a public header
2. if you look into apr_xml.c you can find:
APR_DECLARE(apr_xml_parser *) apr_xml_parser_create(apr_pool_t *pool)
{
return apr_xml_parser_create_ex(pool,&start_handler,&end_handler,
&cdata_handler);
}
so why should something directly link against apr_xml_parser_create_ex() ?
I dont find any other reference to apr_xml_parser_create_ex() beside the one
in apr_xml.c; so I guess the linkage error happens because
apr_xml_parser_create_ex() is wrongly marked for export in the C file, or?
right, apr_xml_expat/libxml had API-style linkage
xml/apr_xml_expat.c:APR_DECLARE(apr_xml_parser *)
apr_xml_parser_create_ex(apr_pool_t *pool,
xml/apr_xml_libxml2.c:APR_DECLARE(apr_xml_parser *)
apr_xml_parser_create_ex(apr_pool_t *pool,
meanwhile, apr_xml_parser_create_ex() certainly *sounds* like an API
niq, is that to be exported eventually? otherwise, the APR_DECLARE()
can be ripped off and the two implementations be given a less
API-sounding name
I still dont believe we should export this function, and have just
created the patch to remove he APR_DECLARE() - if there's shortly some
proposal for a better name then I'll take that into account, otherwise I
will commit the removal only within a hour -- unless someone screams :-)
Gün.
Re: svn commit: r1086790 - /apr/apr/trunk/xml/apr_xml_internal.h
On Tue, Mar 29, 2011 at 7:09 PM, Guenter Knauf wrote:
> Am 30.03.2011 00:52, schrieb Guenter Knauf:
>>
>> are you really sure this is the right thing? /me doubt ...
>> 1. its in an internal header - if we want to expoert that function then
>> it should be moved to a public header
>> 2. if you look into apr_xml.c you can find:
>> APR_DECLARE(apr_xml_parser *) apr_xml_parser_create(apr_pool_t *pool)
>> {
>> return apr_xml_parser_create_ex(pool, &start_handler, &end_handler,
>> &cdata_handler);
>> }
>>
>> so why should something directly link against apr_xml_parser_create_ex() ?
>
> I dont find any other reference to apr_xml_parser_create_ex() beside the one
> in apr_xml.c; so I guess the linkage error happens because
> apr_xml_parser_create_ex() is wrongly marked for export in the C file, or?
right, apr_xml_expat/libxml had API-style linkage
xml/apr_xml_expat.c:APR_DECLARE(apr_xml_parser *)
apr_xml_parser_create_ex(apr_pool_t *pool,
xml/apr_xml_libxml2.c:APR_DECLARE(apr_xml_parser *)
apr_xml_parser_create_ex(apr_pool_t *pool,
meanwhile, apr_xml_parser_create_ex() certainly *sounds* like an API
niq, is that to be exported eventually? otherwise, the APR_DECLARE()
can be ripped off and the two implementations be given a less
API-sounding name
Re: svn commit: r1086790 - /apr/apr/trunk/xml/apr_xml_internal.h
Am 30.03.2011 00:52, schrieb Guenter Knauf:
are you really sure this is the right thing? /me doubt ...
1. its in an internal header - if we want to expoert that function then
it should be moved to a public header
2. if you look into apr_xml.c you can find:
APR_DECLARE(apr_xml_parser *) apr_xml_parser_create(apr_pool_t *pool)
{
return apr_xml_parser_create_ex(pool, &start_handler, &end_handler,
&cdata_handler);
}
so why should something directly link against apr_xml_parser_create_ex() ?
I dont find any other reference to apr_xml_parser_create_ex() beside the
one in apr_xml.c; so I guess the linkage error happens because
apr_xml_parser_create_ex() is wrongly marked for export in the C file, or?
Gün.
Re: svn commit: r1086790 - /apr/apr/trunk/xml/apr_xml_internal.h
Hi Jeff,
Am 30.03.2011 00:29, schrieb traw...@apache.org:
Author: trawick
Date: Tue Mar 29 22:29:05 2011
New Revision: 1086790
URL: http://svn.apache.org/viewvc?rev=1086790&view=rev
Log:
fix linkage of apr_parser_create_ex() on Windows
Submitted by: Carlo Bramini
PR: tiny part of 46175
Modified:
apr/apr/trunk/xml/apr_xml_internal.h
Modified: apr/apr/trunk/xml/apr_xml_internal.h
URL:
http://svn.apache.org/viewvc/apr/apr/trunk/xml/apr_xml_internal.h?rev=1086790&r1=1086789&r2=1086790&view=diff
==
--- apr/apr/trunk/xml/apr_xml_internal.h (original)
+++ apr/apr/trunk/xml/apr_xml_internal.h Tue Mar 29 22:29:05 2011
@@ -43,8 +43,6 @@ struct apr_xml_parser {
XMLParserImpl *impl;
};
-
-
-apr_xml_parser *apr_xml_parser_create_ex(apr_pool_t*, void*, void*, void*);
+APR_DECLARE(apr_xml_parser *) apr_xml_parser_create_ex(apr_pool_t*, void*,
void*, void*);
#endif
are you really sure this is the right thing? /me doubt ...
1. its in an internal header - if we want to expoert that function then
it should be moved to a public header
2. if you look into apr_xml.c you can find:
APR_DECLARE(apr_xml_parser *) apr_xml_parser_create(apr_pool_t *pool)
{
return apr_xml_parser_create_ex(pool, &start_handler, &end_handler,
&cdata_handler);
}
so why should something directly link against apr_xml_parser_create_ex() ?
Gün.
