Socket state confusion

Using WIPlib 5.20
i just got this:

09/11/18,02:00:32:375	ADL	10	[gprsMonitor] ADL_GPRS_EVENT_ME_UNREG
09/11/18,02:00:32:375	ADL	 1	[WIP] Error: ch_channel.c:262: WIP API call with NULL as a channel
09/11/18,02:00:32:375	ADL	10	[gprsMonitor] socketState: 30
09/11/18,02:00:32:375	ADL	10	[gprsMonitor] Can't stop socket! -994
09/11/18,02:00:32:375	ADL	10	[gprsMonitor] bearer wasn't stopped  -24

wip_getState gets 30!
how is that possible when the enum it’s based on only contains 4 items?


Does the enum start at 0?

ciao, Dave

Yes?, (there’s nothing specified)
typedef enum wip_cstate_t in wip_channel.h


The following bit of code:

	wip_cstate_t myCstate;

    for (myCstate=WIP_CSTATE_BUSY; myCstate <= WIP_CSTATE_LAST; myCstate++)
    	TRACE (( 1, "myCstate = %d", myCstate));


myCstate = 0
myCstate = 1
myCstate = 2

Which is what I would have expected.

Now I’m confused - although there’s nothing new about that :smiley:.

Are you sure that you are printing out the state variable, and not something from within the WIP DEBUG system? I’ve found that the values output by WIP DEBUG DO NOT match up with the error numbers in the API guide…

ciao, Dave


I’ve been observing such a behaviour through a number of WIP plugin versions.
Return value sometimes is unpredictable and not in enum range.
I presume this happens due to call wip_getState() for closed/not valid socket handle.
If this is the case, I do not understand why special enum value for such state was not implemented :confused:


that makes sense

worst even… they have error codes for that…
but they just don’t seem to be using them.

Actually you should have not been mentioned ADL errors because wip_getState() function declared to return one of predefined values - enum wip_cstate_t :slight_smile:
Instead of implementing deterministic behaviour of WIP functions sometimes there are notes in WIP development guide that being called for closed/invalid handles function might behave in unpredictable way :confused: