GetTotalBytesSent() can't parse value, if it's negative about goupnp HOT 3 CLOSED

Hm, that's fiddly. But not the first time that a device doesn't match the standard in this place.

There's an existing "hack" here:
https://github.com/huin/goupnp/blob/master/cmd/goupnpdcpgen/metadata.go#L57

The UPNP standard states "ui4" (aka uint32 in Go), which this hack promotes to "ui8" (uint64 as you've probably seen). This was contributed by someone else using this library who ran into a device that exceeded a value of 2^31-1.

Two options spring to mind:

1. We could try changing this hack from "ui8" to "int" (yeah, gotta love the consistency: https://github.com/huin/goupnp/blob/master/cmd/goupnpdcpgen/typemap.go#L18). The thing that bothers me is that it could cause incompatibilities with other people using this library -- i.e their existing code reads this value into a variable/field of type uint64, which would now no longer compile.

2. Another alternative might be to try and introduce another hack that creates another method that has a different name, calls the same SOAP method, but returns int64 instead. A bit more complex and ugly, but keeps compatibility.

Thoughts?

from goupnp.

I would suggest to follow standards and make less hacks. AFAIK it works without any problem with miniupnpd, tho not with some weird implementations. Even, if goupnp could parse that value, it's going like sinusoid - difficult to track existing state. I would rather allow to let weird implementation router to deprecate.

from goupnp.

Just revisiting this years later. A workaround in specific cases where this happens could be to fork a copy of the implementation of the existing function, and use that instead of changing this package.

from goupnp.