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.
Currently, in notify_send_and_recv function, pupnp waits for
HTTP_DEFAULT_TIMEOUT seconds when trying to send a GENA notification.
When there is a lot of notifications with CPs which was disconnected
without unsusbcribing, all the pupnp threads are blocked on this
timeout. To correct, this issue, this patch adds a new variable,
GENA_NOTIFICATION_SENDING_TIMEOUT, which can be used to lower the
timeout so GENA threads return quickly when writing is impossible. By
the same mean, pupnp waits the CP's answer to the NOTIFY for
HTTP_DEFAULT_TIMEOUT seconds, so this patch adds a new variable,
GENA_NOTIFICATION_ANSWERING_TIMEOUT, to customize this value.
Currently, pupnp is using a blocking connect to sends GENA
notifications. As a result, when there is a lot of notifications with
CPs which were disconnected without unsusbcribing, all the pupnp
threads are blocked for 20s (timeout). To correct this issue, this
patch replace the call to connect with a call to private_connect and add
a compilation flag to disable blocking TCP connections, so if we are not
able to connect to the CP, the notification is lost.
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.
Fix for bug introduced in samples code in svn revision 502, commit
git:25c908c558c8e60eb386c155a6b93add447ffec0
Sample device and combo were aborting with the message:
"***** SampleUtil_Initialize was called multiple times!"
Put the loop to send multiple copies of each SSDP advertisements in
ssdp_server.c instead of ssdp_device.c so we have only one call to
imillisleep ( SSDP_PAUSE ) to speed up advertisements.
Previously, NUM_COPY was used in ssdp_device.c to send multiple copies
of each advertisements but also multiple replies to each M-SEARCH
request. As sending multiple replies is not compliant with HTTPU/MU
spec, NUM_COPY has been set to 1 in an older patch. However, as this
variable is not needed and has been replaced with SSDP_COPY, it has
been removed.
Currently, SSDP_COPY is used only to send multiple M-SEARCH requests (in
ssdp_ctrlpt.c). With this patch, SSDP_COPY is also used to send multiple
copies of each advertisements packets (in ssdp_device.c).
By "Carl Benson" <carl.benson@windriver.com>:
I had to do some modifications myself though, because the Android
build system insists on having a file named "util.h" taking precedence
in its include path, libupnp gets confused because of the same filename
in upnp/src/inc/util.h
Fix a bug in miniserver.c, in which maxMiniSock was wrongly declared as
unsigned int and as a result it was beeng set to ((unsigned int)(-1)).
As a result, after beeing incremented, it became zero, and this value
was beeing used in the select() call.
Thanks to Fabrice Fontaine for helping and testing with this issue.
the sleep() call, it was just a workaround.
SF Bug Tracker [ 3086852 ] 99% CPU loop in miniserver.c on a non ipv6
system.
Submitted by: Jin ( jin_eld ) - 2010-10-13 19:29:13 UTC
I cross compiled libupnp 1.6.7 for ARM9 using the --disable-ipv6
option, my system is an ipv4 only setup.
I do not know why this problem only appears when running the app in the
background (for instance using nohup &), but then it starts using 99%
CPU.
I traced the problem down to the select() call in miniserver.c in the
RunMiniServer() function. Select returns code 1, but errno is set to
"Socket operation on non-socket", I also see this when running my app
under strace.
I set all ...Sock6 variables to INVALID_SOCKET to make sure that they
do not get added to the FD_SET and the problem is gone.
Adding a configure flag to disable GENA notification reordering as even
with an imillisleep(1), this mechanism consumes too much CPU on embedded
devices when there is a burst of notifications.
When a device with embedded devices (like IGD) when created and one of
the embedded devices did not have any service, there was a Segmentation
Fault (see SF Tracker [ 2688125 ]).
When a lot of notifications were generated by a device in a short
period of time then 100% of the CPU was used to reorder those
notifications by pushing back the thread in the job queue. This
mechanism has been modified so now thread sleep 1 ms before being
pushed back into the job queue.
Removing DEFAULT_SCHED_PARAM parameter and use
sched_get_priority_min(DEFAULT_POLICY) instead.
Devices must respond to M-SEARCH requests for any supported version and the
response should specify the same version as was contained in the search target.
Previously, the device did not answer if the M-SEARCH request did not
contain the same version number than the version number of the device.
This patch adds the WEB_SERVER_CONTENT_LANGUAGE parameter so the user can specify
the language used by the device during Description and Presentation steps of UPnP
through the HTTP CONTENT-LANGUAGE header.
By default, the WEB_SERVER_CONTENT_LANGUAGE is an empty string so no
CONTENT-LANGUAGE is added.
This patch allows a user to customize the stack size of the threads used by
pupnp through the new THREAD_STACK_SIZE variable. This is especially useful
on embedded systems with limited memory where the user can set THREAD_STACK_SIZE
to ITHREAD_STACK_MIN.
However, as this modification can have side effects, I set 0 as the default
value, so threads will continue to use the default stack size of the system
(which varies greatly as stated in
https://computing.llnl.gov/tutorials/pthreads/).
Hi,
I've made some modification to the libupnp v1.6.5
I've add a timeout for each TCP connect.
It is very useful when an UPnP device stop working and do not accept
connection for an UPnP action.
Modifications are only located in
upnp/src/genlib/net/http/httpreadwrite.c
For every TCP connection, I set the socket to non-blocking, perform
connect,
check result and wait during a timeout if necessary, then reset the
socket to blocking.
Please see this patch in attached file.
I hope it helps.
Regards,
David Hoeung
Consultant Extia
Orange Labs R&D
----
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)
src/ssdp/ssdp_ctrlpt.c: In function ‘SearchByTarget’:
src/ssdp/ssdp_ctrlpt.c:634: warning: format ‘%s’ expects type ‘char *’, but argument 6 has type ‘int’
Sending messages over UDP is broken in some Apple OSes
such as OS X and iOS. This might be broken in other OSes to but didn't
verify.
The fix is to modify the socket lenght argument of sendto to use the correct
sockaddr lenght dependng on whether the socket is IPV4 or IPV6.
Also added some error checks and debugging related to the issue
crash. This happens when the file being downloaded exceeds the device
memory - entirely possible when transferring video files.
The programmatic cause is that the logic implemented in the function
http_ReadHttpGet (which UpnpReadHttpGet calls) reads the entire file
into memory. The fix modifies the existing logic to discard data after
it's been read; there's no reason to keep it around since the caller
of UpnpReadHttpGet already has a copy of it.
This issue exists in 1.6.6 as well as the latest sources.
Patch submitted by Chandra (inactiveneurons).
use connect() are broken. More specifically, connect() in these methods
is returning with an EINVAL. The programatic cause is that the address_len
argument passed to connect() is different in IPV4 vs IPV6 (as described in:
http://www.opengroup.org/onlinepubs/009695399/functions/connect.html).
The current code always uses the IPV6 size. The fix modifies each use of
connect() to use the correct size based on the address family being used.
Patch submitted by Chandra (inactiveneurons).
* 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
SF Bug Tracker [ 3022490 ] String declaration fix for patch applied in 3007407
Hello,
When my patch for tracker ID 3007407 was accepted, the definition of the
serviceList string was changed from
#define SERVICELIST_STR "serviceList"
to
static const char *SERVICELIST_STR = "serviceList";
During internal code review of the final patch, it was pointed out that
sizeof(SERVICELIST_STR) == 4 since SERVICELIST_STR is now declared as
a pointer instead of an array.
If you wish to use a variable instead of a define, I suggest the
following instead:
static const char SERVICELIST_STR[] = "serviceList";
Thanks,
Chuck Thomason
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@557 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Backport of svn revision 552:
SF Bug Tracker [ 3007407 ] Service traversal issue in AdvertiseAndReply()
Submitted: Chuck Thomason ( cyt4 ) - 2010-05-26 15:07:39 UTC
When the UPnP server is started, one alive message is broadcast for each
service in each device. It appears that libupnp's implementation of the
alive message generation does not correctly navigate the XML description
document when locating the services. This can result in the wrong UDN
being used in the alive message sent for a service.
In my specific case (see attached XML), the root EchoSTB device contains
no services, but its embedded MediaServer device contains 2 services.
When the existing libupnp code traverses the EchoSTB device in the XML,
it searches the global list of serviceLists within the document instead
of searching for a serviceList that is its direct child node. The
ContentDirectory and ConnectionManager services are then announced with
the UDN of EchoSTB1 (the root device) instead of with the UDN of
MediaServer, which is actually their parent device.
I discovered this behavior using libupnp-1.6.6. I have generated a patch
against branch-1.6.x that corrects the XML navigation such that all
services are traversed from their parent device, which results in the
correct UDN being sent in the alive message for each service. I built
from branch-1.6.x without this patch, tested, and confirmed that the
issue still exists as I observed it in libupnp-1.6.6. I then built
from branch-1.6.x with this patch, tested, and confirmed that the
issue was resolved.
Thanks,
Chuck Thomason
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@553 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted: viallard anthony ( homer242 )
When trying to use reuseaddr option in miniserver/miniserver.c, there
isn't a affectation of the port chosen (serverAddr.sin_port isn't
receive listen_port variable value).
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@548 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
Submitted: Ulrik ( ulsv_enea ) - 2008-12-05 08:24
Valgrind reports a memory leak due to that the function ithread_detach is
not called for finished worker threads in ThreadPool.c.
==21137== 2,176 bytes in 8 blocks are possibly lost in loss record 5 of 5
==21137== at 0x4C20F3F: calloc (vg_replace_malloc.c:279)
==21137== by 0x4010F58: _dl_allocate_tls (in /lib/ld-2.6.1.so)
==21137== by 0x544BA92: pthread_create@@GLIBC_2.2.5 (in
/lib/libpthread-2.6.1.so)
==21137== by 0x5F94592: CreateWorker (ThreadPool.c:639)
==21137== by 0x5F95079: ThreadPoolInit (ThreadPool.c:784)
I'm using libupnp 1.6.6
For more info on pthread_detach, see:
http://gelorakan.wordpress.com/2007/11/26/pthead_create-valgrind-memory-lea
k-solved/
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@520 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted: Ulrik ( ulsv_enea ) - 2008-12-05 08:24
Valgrind reports a memory leak function in AdvertiseAndReply
(ssdp/ssdp_server.c) in libupnp 1.6.6
There are continue statements in many places in AdvertiseAndReply. In some
of those error handling cases the variable nodelist is not free'ed before
continuing to the next iteration. The next iteration will take care of
free'ing the nodelist from the previous iteration in most cases, but not
when breaking out of the for loop after the last element.
I belive this memory leak can be solved by makeing sure that the rows
ixmlNodeList_free( nodeList );
nodeList = NULL;
are always executed, also in the beginning of the last iteration when we
found out that there are not more elements.
==29110== at 0x4C21C16: malloc (vg_replace_malloc.c:149)
==29110== by 0x5D8DE0E: ixmlNodeList_addToNodeList (nodeList.c:106)
==29110== by 0x5D8B7E2: ixmlNode_getElementsByTagNameRecursive
(node.c:1438)
==29110== by 0x5D8E587: ixmlElement_getElementsByTagName
(element.c:491)
==29110== by 0x5B6C0F1: AdvertiseAndReply (ssdp_server.c:201)
==29110== by 0x5B7AB74: UpnpSendAdvertisement (upnpapi.c:1495)
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@518 119443c7-1b9e-41f8-b6fc-b9c35fce742c
SF Patch Tracker [ 2964973 ] install: will not overwrite just-created
...blah... with...
Submitted: Nick Leverton ( leveret ) - 2010-03-07 05:18
Full error:
/usr/bin/install: will not overwrite just-created
`/tmp/buildd/libupnp-1.6.6/debian/tmp/usr/share/doc/libupnp3-dev/examples/s
ample_util.c' with `common/sample_util.c'
This seems to be from Automake 1.11 which doesn't like having duplicate
files in a Makefile.am. Patch attached, kindly provided by Stefan Potyra
for Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543068)
This fix will be needed for both 1.6.x and 1.8.x branches.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@511 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: zephyrus ( zephyrus00jp )
Obs by Marcelo: The issue with linking with -lsocket -lnsl -lrt is not
covered in this changeset beacuse I don't have solaris to test. I will
need some help from zephyrus in this regard. The issue will be addressed
in a future changeset.
Compilation for solaris
I have used gcc3.x and gcc4.x under solaris 10 for x86 / 64 bits.
A couple of Source file fixes were necessary for successful compilation
and runtime behavior.
threadutil/src/ThreadPool.c
POSIX
sched_setschduler() returns non-negative value for success.
Without the fix, UpnpInit() fails immediately.
upnpp/src/api/upnpai.c
There is a typo of a macro name "__sun" in one of the
CPP conditional.
Without the fix, the compilation aborts due to unknown constant
in socket ioctl call.
A few structs and an array is not properly initialized.
Well, I think it may be safe as is, but when I checked it
using purify evaluation version, it was reported that
uninitizlied iszBuffer may cause read of uninitialized memory.
So play it safe.
Configure issue.
This has to be more of a configure magic.
To link a program successfully using network, we need
-lsocket and -lnsl library specifications on the link line.
We also need -lrt for programs that use thread scheduling features.
The sample program under upnp/sample requires
-lsocket -lnsl -lrt
for successful linking.
I added -lsocket -lnsl -lrt to Makefile.in.
configure probably needs to take care of these.
I don't know much about configure, automake, etc., so
I am just raising a flag here.
TIA
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@505 119443c7-1b9e-41f8-b6fc-b9c35fce742c
stopping at the first lis
Submitted By: zephyrus ( zephyrus00jp )
Internet Gateway Device description contains nested serviceList (rootdevice
-> servicelist, subdevice
and subdevice has the lower-level serviceList, etc..)
Unfrotunately, the sample code sample_util.c used by tv_device sample,
etc.
has a code that looks for only the first top-level serviceList.
This results in the failure to read all the services of an IGD xml
description.
Attached patch modifies this behavior and looks for the service by
visiting all the serviceList in xml document in turn.
With the modified patch (ad additional modification), I could
simulate an IGD device and created a modified control program for that.
Patch against 1.6.6
TIA.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@502 119443c7-1b9e-41f8-b6fc-b9c35fce742c
* SF Patch Tracker [ 2970872 ] Update ErrorMessages for latest return
code list
Submitted By: Nick Leverton ( leveret )
ErrorMessage[] in upnptools.c has got a bit out of sync, the attached
patch (generated from grep 'define UPNP_E_') should bring it up to date.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@496 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
SF Patch Tracker [ 2546532 ] Missing carriage return between
SOAPACTION and User-Agent headers.
There is something going wrong in soap_ctrlpt.c at line 931 (based on
version 1.6.6 release).
The http_Makemessage call looks as follows:
if (http_MakeMessage(
&request, 1, 1,
"Q" "sbc" "N" "s" "s" "Ucc" "sss",
SOAPMETHOD_POST, path.buf, path.length,
"HOST: ", host.buf, host.length,
content_length,
ContentTypeHeader,
"SOAPACTION:
\"urn:schemas-upnp-org:control-1-0#QueryStateVariable\"",
xml_start, var_name, xml_end ) != 0 ) {
return UPNP_E_OUTOF_MEMORY;
}
This will result in the SOAPACTION header to be immediately followed by the
User-Agent header, while a cr-lf should separate the two. I propose to fix
this by changing the second "s" to "sc" to force the addition of a cr-lf
after the SOAPACTION. This looks consistent to the other Makemessage calls.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@487 119443c7-1b9e-41f8-b6fc-b9c35fce742c
395: Bob Ciora's patch for lazy UpnpAcceptSubscription().
434: Fixed a buffer overflow due to a bug in the calculation of the
CONTENT-TYPE header line size, the length was beeing calculated with
the wrong string, there was a missing colon.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@461 119443c7-1b9e-41f8-b6fc-b9c35fce742c
[pupnp-devel] NetBSD & Mac OS X packages and patches
Okay, I found a couple more things. I have attached a patch file
against the trunk (version 206) that make the repository code compile
and run on both Mac OS X and NetBSD.
This fixes the following issues:
upnp/src/api/upnpapi.c: SIOCGIFCONF didn't work properly, use
getifaddrs() instead (on BSD systems).
threadutil/src/ThreadPool.c: priorities only work if
_POSIX_PRIORITY_SCHEDULING is defined (and greater than 0).
threadutil/src/LinkedList.c and threadutil/src/iasnprintf.c: use
stdlib.h instead of malloc.h on all BSD systems (not just FreeBSD).
This is important, because malloc.h does not exist on Darwin/Mac OS X.
Cheers
,
Rene
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@207 119443c7-1b9e-41f8-b6fc-b9c35fce742c
ax_cflags_warn_all.m4, m4/ax_cflags_warn_all_ansi.m4,
m4/type_socklen_t.m4.
* Fixed an issue with the instalation of the file upnpdebug.h. Since
the last modifications that removed the macro DEBUV_ONLY, this file
must be installed even on a non-debug build.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@204 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Bob Ciora
The field DestAddr of the structure Upnp_Discovery is now a full
SOCKADDRIN instead of a pointer to SOCKADDRIN. Commented code sugests
that in a previous moment, the function ssdp_handle_ctrlpt_msg() did
not use a postponed thread to call ctrlpt_callback(). Now the code
uses a thread, and most probably the original data would get lost and
the pointer would point to an invalid memory region. This fix caused
an interface change in the library and the minor library version was
bumped. Also, the libtool library numbers were changed accordingly.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@203 119443c7-1b9e-41f8-b6fc-b9c35fce742c
defines. These were just aliases, no reason to keep them.
* Changed the comments of the include files that expose the UPnP API
to use only C89 comments and no C99 comments.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@198 119443c7-1b9e-41f8-b6fc-b9c35fce742c
* Enable both device and control point in the same application. Resolve
deadlock in the SSDP processing threads.
* Fix Threadpool expansion condition.
Thanks to Siva Chandran P. for the original patch.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@194 119443c7-1b9e-41f8-b6fc-b9c35fce742c
compatible with WinXP/IE control point. 'in' arguments must appear before
'out' arguments in argument list.
Thanks to Martin Tremblay for pointing out the solution originally
provided by MORIOKA Yasuhiro.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@193 119443c7-1b9e-41f8-b6fc-b9c35fce742c
befor calling va_end().
- Removed all uses of the DBGONLY(x) macro. A static inline empty
function now is used and the compiler takes care of optimizing it out.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@185 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Thanks to David Maass.
* sizeof is unsigned, so %zu is more adequate than %zd.
* Using an invented printf directive PRIzu that on MSVC
expands to "lu", and on normal C99 compilers expands to "zu".
* Rewrote raw_find_str. Now it no longer uses strcasestr(), but it
transforms the first input buffer into lowercase.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@184 119443c7-1b9e-41f8-b6fc-b9c35fce742c
upnp to folder upnp/sample. Moved folder upnp/sample/tvdevice/web
to folder upnp/sample/web. This way, if someone compiles the
tarball and executes upnp_tv_device from its creation directory,
there will be no error -108 for not finding directory web.
Also changed svnignore in the process.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@183 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Glen Masgai
after an UpnpSendActionAsync() for example, i get UPNP_E_OUTOF_MEMORY
in the callback using 1.4.4 on a x86_64 system. This happens in
http_MakeMessage(), which in some cases get called with wrong types
(int instead of size_t) in combination with format "b" and "Q".
The attached patch should fix this.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@166 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Timothy Redaelli - drittz
I made some patches to make it compile under FreeBSD using
gethostbyaddr_r when supported.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@165 119443c7-1b9e-41f8-b6fc-b9c35fce742c
It would loop forever.
- Also strcasestr() is a gnu extension, we need the proper define so that
the prototype is accessable.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@163 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Michael Andersen - miwer
Issue was found to be related to sizeof (size_t) != sizeof (int)
on AMD64 systems. Emil Ljungdahl's AMD64 patch has been applied along
with some other fixes. Original user report follows:
When I run upnpd I get the above mentioned error (UPNP_E_OUTOF_MEMORY).
I've tried with 1.4.1 and 1.4.2-RC3, it's the same. I don't understand why,
because I have plenty of RAM, and I even tried closing some applications,
but it didn't help.
$ upnpd eth1 br0
The following is logged in the /var/log/messages:
Feb 6 01:33:47 server upnpd[6933]: Error registering the root device with
descDocUrl: http://192.168.0.1:49152/gatedesc.xml
Feb 6 01:33:47 server upnpd[6933]: UpnpRegisterRootDevice returned -104
I tried enabling debugging and it looks like it cannot allocate memory
through the membuffer_append function. It's wierd because it's only a few
bytes.
Please note, that I enabled some extra debugging lines that were commented,
in order to get more information. See attached files.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@154 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Jon Foster - jongfoster
This patch gives basic support for building under Cygwin - it compiles,
links, and a simple UPnP device application can initialise. I'm not sure
if it actually works yet, but this is definitely a step in the right
direction.
Patch is against the 1.4.1 release. Changes are:
* threadutil/inc/ithread.h: Fix the ithread mutex support to use
documented, portable APIs (if present) rather than the Non-Portable (_NP)
ones it uses now. This is required because Cygwin implements only the
portable API.
* threadutil/src/ThreadPool.c: Fake SetPolicyType() to do nothing on Cygwin
because otherwise it fails. Should probably investigate why it fails and
add a proper implementation later.
* upnp/src/api/upnpapi.c: On Cygwin, zero out the GlobalHndMutex structure
before initialising it. Without this, the initialisation fails. This
appears to be a bug in Cygwin.
* upnp/src/genlib/net/uri/uri.c: Use gethostbyname() on Cygwin.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@151 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Jonathan - no_dice
Summary: This patch hopefully fixes the remaining types and related
code to enable files >= 2 GiB to be streamed. Jonathan claims to have
tested this with a patched version of ushare-0.9.8 and a D-Link DSM-520.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@121 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By:
Fredrik Svensson - svefredrik
This patch fixes two problems:
* Specify the IP address for the interface when we do setsockopt IP_ADD_MEMBERSHIP. This makes it possible to run when no default router has been configured.
* Explicitly set the multicast interface through setsockopt IP_MULTICAST_IF. Avoids socket error -207 in some cases.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@119 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By:
Fredrik Svensson - svefredrik
Incremented the libray versions and included some comments in the file
configure.ac so that we do not bump the library version excessively,
only the necessary numbers on the next release.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@115 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By:
Fredrik Svensson - svefredrik
A few modifications to the patch were made:
1) Do not introduce new CRLF's where there were none.
2) Applied the same original idea to two other palces in soap_ctrlpt.c.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@114 119443c7-1b9e-41f8-b6fc-b9c35fce742c
in rev.79: largefile patch added.
http_MakeMessage() has a worst than brain damaged "printf" like interface.
In rev.79, the "N" format parameter must be an off_t. Every call of this
function with an "N" format parameter and an int passed on the stack
would fail terribly.
Not every place I touched had a bug, but to review the format and keep my
sanity, I had to format it properly.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@96 119443c7-1b9e-41f8-b6fc-b9c35fce742c
[submitted-by] Erik Johansson - erijo
[patched-by] Erik Johansson - erijo
The SOAP HTTP message that's generated on upnp errors
is missing a \r\n\ between header and body.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@95 119443c7-1b9e-41f8-b6fc-b9c35fce742c
