The fact that we now have an active developer on branch ipv6 made me do this before I would like to.
The idea here is to hide libupnp internal data structures from the outside world so that
developers can be free to change them without breaking the interface. There is still some work to do
before a formal release, but the samples (device and control point) should be working.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@353 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By Luke Kim - nereusuj
Version 1.6.5 cannot be compiled because of some changes in 1.6.3.
MSVC does not support stdint.h, gettimeofday(), sys/param.h, const int
variables in array size and Windows does not define _WINDOWS_ but define
_WINDOWS.
* MSVC does not understand "const int"'s as declarators of array
dimensions, we must use #define'd constants.
* Use WIN32 instead of _WINDOWS_ or _WINDOWS.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@331 119443c7-1b9e-41f8-b6fc-b9c35fce742c
to (virtualDirCallback.open)(filename, UPNP_WRITE) (notice the
parenthesis) due to a change in glibc that produces compilation
errors.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@223 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
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: 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
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
