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