Possible string leak and null dereference in Windows openPort() #202

I found a possible JNI string leak and an unchecked-null dereference in the Windows implementation of openPort().

File: src/main/cpp/windows/jssc.cpp

Function: Java_jssc_SerialNativeInterface_openPort

Relevant code:

const char* port = env->GetStringUTFChars(portName, JNI_FALSE);

//since 2.1.0 -> string concat fix
char portFullName[MAX_PORT_NAME_STR_LEN];

if(strlen(prefix) + strlen(port) + 1 > sizeof(portFullName)){
    return (jlong)((HANDLE)jssc_SerialNativeInterface_ERR_PORT_NOT_FOUND);
}

strcpy_s(portFullName, prefix);
strcat_s(portFullName, port);
//<- since 2.1.0

HANDLE hComm = CreateFile(portFullName, ...);
env->ReleaseStringUTFChars(portName, port);

GetStringUTFChars() returns a native string that must be paired with
ReleaseStringUTFChars(). The only release is after CreateFile(), but the
length-check path returns early:

if(strlen(prefix) + strlen(port) + 1 > sizeof(portFullName)){
    return (jlong)((HANDLE)jssc_SerialNativeInterface_ERR_PORT_NOT_FOUND);
}

port is still held here, so an overlong port name leaks the acquired chars on
every call — reachable with an ordinary Java string, no OOM required.

GetStringUTFChars() can also return NULL (typically with OutOfMemoryError
pending). The result is used immediately by strlen(port) with no null check, so
on acquisition failure the code dereferences NULL and can crash the process
instead of propagating the exception.

Suggested fix: check the result for NULL right after acquisition, and release
port before the early return on the length-check path.