#552 PORTOPEN doesn't check return code properly, never reports failure

[David Costanzo]

PORTOPEN doesn't report an error when the port cannot be opened. This is reproducible in FMSLogo 7.7.0 and as far back as MSWLogo 6.5b.

This is due to a simple coding copied from MSWLogo. First, the port is stored in in a global ComId, which is of type HANDLE. From the MSWLogo code DEVWIND.CPP:

#if !defined(__WIN32__)
int ComId;
#else
HANDLE ComId;
#endif

PORTOPEN is implemented in lportopen:

#if !defined(__WIN32__)
      ComId = OpenComm(comport, 1024, 1024);
#else
      ComId = CreateFile(comport, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);
      ...
#endif
      if (ComId < 0)
         {
         MainWindowx->CommandWindow->MessageBox("Could not open PORT", "Error");
         err_logo(STOP_ERROR, NIL);
         }
      else
         {
         ComIsOpen = TRUE;
         }

Since HANDLE is unsigned, it is never negative, and so checking ComId < 0 always returns false.

Given the pre-processor instructions and the fact that ComId is an int when __WIN32__ is not defined, this was likely introduced when MSWLogo was ported from 16-bit windows to 32-bit windows.

Impact:
Medium. Confusion if the port could not be opened. Errors are reported on the next instruction.

Likelihood:
Low. Most computers today don't have communication ports. I don't know if anyone uses this procedure, anymore.

How Reproducible:
Every Time

Steps to Reproduce:
1) Run PORTOPEN "||
2) Run PORTOPEN "COM1

What Happens:
The first PORTOPEN instruction returns without error.
The second PORTOPEN instruction reports a "port already open" error, indicating that FMSLogo thinks the first instruction opened a port successfully.

Expected Result:
The first PORTOPEN reports an error.
The second PORTOPEN succeeds or fails, depending on whether you can open COM1. It does not report a

[David Costanzo]

This is fixed by [r5443], which will be available in FMSLogo 8.0.0.

While the bug, itself, isn't important, fixing it enables complete testing of the error paths, which is important for fixing Bug #547.