[comp.sys.ibm.pc] uupc for MS-DOS problem

skl@van-bc.UUCP (Samuel Lam) (09/10/87)

The "sscanf(name, "COM%d", &i);" saga continues...

After much was said, I fell that some explanations from the
source of the posted uupc binaries is in order here.

> The source code is correct.  The problem that the original poster
> observed was probably caused by the fact that the source code as posted
> seems not to be the source code that was actually used to generate the
> posted compiled code.

As the person who compiled the "official" uupc binaries which was
posted, I can swear on a stack of K&R's that the uupc sources
posted was (in all intends and purposes) *exactly the same*
sources that was actually used to generated the uupc binaries
posted.

> One of the documentation files says that the
> port must be called "COM1" or "COM2."

The README file for the IBM-PC/MS-DOS uupc said that, so that
only applies to the IBM-PC/MS-DOS version of uupc.

> The above sscanf should work correctly if this is so.

And it does when you use it with the IBM-PC/MS-DOS version of
uupc.

> BUT one of the example files, called Systems, uses a different
> convention for the port name:  it uses "a" instead of "COM1" and,
> presumably, would use "b" instead of "COM2".

That example file, which was distributed in the uupc general
sources distribution, was for the Macintosh version of uupc.
(The Mac refers to its two serial port as port 'a' and 'b'.)

The unfortunate thing here is that we forgot to mention that the
"port" field in the "systems" file is a *system-dependent* field
(i.e. it accepts different sets of values depending on which
system you run uupc on) and those who setup that file for a
system should consult the sources to determine the set of valid
values for that field.

Consider that much of the uupc documentation was written up
quickly in a few nights before the release, we couldn't have
possibly covered all the areas where questions might arise.
(Remember that the uupc project is a volunteer effort, we all
have *real* work to do during the day, to keep our paid cheque
coming.)

> And the binary that was
> posted actually seems to accept "a" if you want to use COM1.

That is *purely* an coincident.  i.e. It all depends on what
"garbage" is on the stack at the localation where the
*uninitialized* baud rate variable (in this case "i") is.  Since
the assember code which actually does the port selection only
test the rightmost bit of "i" for a 1 to decide if it should use
COM1, any odd value in the uninitialized variable "i" will cause
COM1 to be used.  Likewise, any even value will cause COM2 to be
used.  (Don't look at me, I didn't write those code.)

If you specify "a" as the serial port to use in the IBM-PC/MS-DOS
version, the "sscanf(name, "COM%d", &i);" call will fail and the
value of "i" will be left unchanged.  And since "i" is a local
variable of openline() and is allocated on the stack upon entry
of that procedure, it will contain whatever garbage left there by
the last user of that part of the stack.  (Although for various
reasons the result might be consistent throughout, it certainly
wasn't intended that "a" and "b" be valid input in this case.)

Actually, if you had specify "b" as input, it will probably still
use the COM1 port anyways.

> So if you compile the source, you need to simply make your Systmes file
> say "COM1" where it currently says "a".

Again, only if you are using uupc with IBM-PC/MS-DOS.

> However, to maintain compatibility with the posted binary, I chose to
> change the source code to accept both "a" and "COM1" for the first port
> and both "b" and "COM2" for the second port.

Since the names of serial ports are really system dependent
values, and "COM1" and "COM2" are used universally in the IBM-PC/
MS-DOS world, I would say that accepting "COM1" and "COM2" for
the port field is enough.  What we need is just to have this fact
documented in the README file for the IBM-PC/MS-DOS uupc.

[from earlier]
> I have just finished converting the posted uupc source to compile and
> run using Turbo C.
...
> Regrettably, I did not follow the admonishment that users change only
> the system-dependent portions of the code.  There were a lot of unused
> variables that I removed.  There were quite a few undeclared functions
> throughout the source that I declared.  There were a few other minor
> things that I wasn't happy leaving unchanged.  One or two compiler-
> specific header files had to be changed.  Not all these changes were
> necessary, but I like to leave all of Turbo C's warning messages turned
> on so I made the changes.

We are doing cleanups on uupc et al as well.  The reason why only
the sources was posted initially, and the IBM-PC/MS-DOS binaries
only posted after much demand, was to make it possible for those
who have the time and energy to do more work on it to do so.

The originally sources release was initially intended mostly for
programmers only, and hence the terse documentation.

If you have any changes that you would like to share, you are
welcome to send it to <uupc@van-bc.UUCP>.  We will do the best we
could to incorporate them into the next release of uupc, which is
currently targeted at late fall.

> Rahul Dhesi         UUCP:  {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi

...Sam
-- 
Samuel Lam     {sesimo,ihnp4!alberta,uw-beaver}!ubc-vision!van-bc!skl