Submitted: Nick Leverton ( leveret ) - 2010-04-19 07:44:10 PDT
Details: The recent codebase merge has removed a significant API call
which is used by several pupnp devices such as mediatomb and gmediaserver.
UpnpSetVirtualDirCallbacks() has been replaced by individual routines to
set each callback. Essentially this means that 1.6.7 will in fact be a majo
bump and 1.6.6 devices can no longer link against it. Could we have the call
reinstated please, perhaps as a wrapper around the individual calls ? As
it is, all distros will have to patch their 1.6.x apps, rebuild and re-link them.
The other removed API calls and external variables don't seem to be used
by any of the apps I have copies of, but UpnpSetVirtualDirCallbacks is
important for maintaining compatibility within 1.6.x.
Adding two new functions (UpnpSendAdvertisementLowPower and
UpnpUnRegisterRootDeviceLowPower) which can be used to specify values
for the three SSDP headers defined by UPnP Low Power. Those headers are
Powerstate, SleepPeriod and RegistrationState.
Add a new UpnpRegisterRootDevice4 which allow user to specify a
description URL to be returned for legacy CPs (for example, CPs
searching for a v1 when the device is v2). Most of those CPs does not
work if they found a v2 in the XML description, so this new function is
only used to solve interoperability issues.
Details:
Hello. I trying compile libupnp-1.6.10 on the Fedora 14 MinGW
Environment and get many errors. I create patch to fix it. With this
patch i can get static library. This patch is very raw.
Submitted: Ivan Romanov (ivanromanov) - 2010-12-16 23:29:19 UTC
This mode can be recognized by the macro __STRICT_ANSI__.
From man gcc:
-ansi
In C mode, this is equivalent to -std=c89. In C++ mode, it is equivalent to
-std=c++98.
This turns off certain features of GCC that are incompatible with ISO C90
(when compiling C code), or of standard (when compiling code), such as the
asm and typeof keywords, and predefined macros such as unix and vax that
identify the type of system you are using. It also enables the undesirable
and rarely used ISO trigraph feature. For the C compiler, it disables
recognition of style // comments as well as the inline keyword.
The alternate keywords _ _asm_ _, _ _extension_ _, _ _inline_ _ and
_ _typeof_ _ continue to work despite -ansi. You would not want to use them
in an ISO C program, of course, but it is useful to put them in header files
that might be included in compilations done with -ansi. Alternate predefined
macros such as _ _unix_ _ and _ _vax_ _ are also available, with or without
-ansi.
The -ansi option does not cause non-ISO programs to be rejected gratuitously.
For that, -pedantic is required in addition to -ansi.
The macro _ _STRICT_ANSI_ _ is predefined when the -ansi option is used.
Some header files may notice this macro and refrain from declaring certain
functions or defining certain macros that the ISO standard doesn't call for;
this is to avoid interfering with any programs that might use these names for
other things.
Functions that would normally be built in but do not have semantics defined
by ISO C (such as alloca and ffs) are not built-in functions when -ansi is
used.
On win32 socket() returns INVALID_SOCKET, which is unsigned,
on error, not -1.
Also, most network functions return SOCKET_ERROR.
This patch tries to make the usage consistent.
This is a follow up from issue 6 in tracker id 3056713: calling UpnpSetMaxContentLength() by passing '0' disables the content length checking. This is useful for developing some prototype applications that deal with a lot of XML/SOAP data, and for debugging.
The corresponding c file change is already in the pupnp tree. Copy/pasting the relevant block of code here for clarity:
In upnp/src/genlib/net/http/httpreadwrite.c:
if (g_maxContentLength > 0 && parser->content_length > (unsigned int)g_maxContentLength) {
*http_error_code = HTTP_REQ_ENTITY_TOO_LARGE;
line = __LINE__;
ret = UPNP_E_OUTOF_BOUNDS;
goto ExitFunction;
}
This block of code checks only does the bounds check if g_maxContentLength > 0, and it's only place g_maxContentLength is checked.
Attached is a patch against the latest sources.
(cherry picked from commit 7f1e164a5a)
* Macros to test whether an IPV6 address is global or ula.
* UpnpGetServerUlaGuaIp6Address(): added interface.
* IN6_IS_ADDR_GLOBAL, IN6_IS_ADDR_ULA: new macros.
* gIF_IPV6_ULA_GUA: new buffer.
* UpnpRegisterRootDevice3(): Change to the test of already registered
devices for IPV6.
* UpnpGetIfInfo(): gua/ula issues.
Patch submitted by Ronan Menard.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@564 119443c7-1b9e-41f8-b6fc-b9c35fce742c
2 - Backport of svn revision 527:
* Added API to ithread, created the following functions:
- int ithread_initialize_library(void);
- int ithread_cleanup_library(void);
- int ithread_initialize_thread(void);
- int ithread_cleanup_thread(void);
* SF Bug Tracker [ 2876374 ] Access Violation when compiling with Visual Studio 2008
Submitted: Stulle ( stulleamgym ) - 2009-10-10 19:05
Hi,
I am one of the devs of the MorphXT project and I use this lib in some
other of my projects, too. When I tried to upgrade the lib earlier for one
of my projects I had to realise that something did not work at first and
while most of the things were reasonably ease to be fixed. Now, the last
thing I encountered was not so easy to fix and I am uncertain if my fix is
any good so I'll just post it here and wait for some comments.
The problem was that I got an Access Violation when calling "UpnpInit". It
would call "ithread_rwlock_init(&GlobalHndRWLock, NULL)" which eventually
led to calling "pthread_cond_init" and I got the error notice at
"EnterCriticalSection (&ptw32_cond_list_lock);". It appeared that
"ptw32_cond_list_lock" was NULL. Now, I found two ways to fix this. Firstly
moving the whole block after at least one of the "ThreadPoolInit" calls
will fix the issue. Secondly, you could add:
#ifdef WIN32
#ifdef PTW32_STATIC_LIB
// to get the following working we need this... is it a good patch or
not... I do not know!
pthread_win32_process_attach_np();
#endif
#endif
right before "ithread_rwlock_init(&GlobalHndRWLock, NULL)".
Just so you know, I am using libupnp 1.6.6 and libpthreads 2.8.0 and both
are linked static into the binaries. I am currently using Visual Studio
2008 for development with Windows being the target OS. Any comment at your
end?
Regards, Stulle
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@529 119443c7-1b9e-41f8-b6fc-b9c35fce742c
(void) argument list.
* SF Patch Tracker [ 2857611 ] Declare a few functions to have proper
(void) argument list.
Submitted By: zephyrus ( zephyrus00jp )
In a publicly installed headers, a few functions are declared without any
arguments at all, a la "()".
When I used gcc's -Wimplict and -Wstrict-prototypes to check for the
mismatch of
function prototype declarations and their usage in my own program,
some headers from libupnp-1.6.6 produced warnings.
They are not strictly bugs, but pretty much annoying. This is 2009, and
almost all the important compilers
understand ISO-C.
So the offending functions are declared as "(void") to show that they have
no arguments at all.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@494 119443c7-1b9e-41f8-b6fc-b9c35fce742c
