It seems the scanf format %[0-9] in Watcom doesn't work the same way as in gcc. Here is a note in the Watcom C/C++ reference: Note: A dash (-) in the scanset doesn't indicate a range of characters. For example, the string [0-9] matches the characters 0, -, and 9, not the characters 0 through 9. I have to make the following change to make -R/-L option of ssh to work: --- ssh.c.orig Tue Apr 23 04:09:46 2002 +++ ssh.c Sun May 26 19:48:49 2002 @@ -467,9 +467,9 @@ case 'L': case 'R': - if (sscanf(optarg, "%5[0-9]:%255[^:]:%5[0-9]", + if (sscanf(optarg, "%5[0123456789]:%255[^:]:%5[012345678 9]", sfwd_port, buf, sfwd_host_port) != 3 && - sscanf(optarg, "%5[0-9]/%255[^/]/%5[0-9]", + sscanf(optarg, "%5[0123456789]/%255[^/]/%5[0123456789]", sfwd_port, buf, sfwd_host_port) != 3) { fprintf(stderr, "Bad forwarding specification '%s'\n",
Here are some more info I gathered from the Watcom newsgroup: The C99 draft explicitly said that: "If a - character is in the scanlist and is not the first, nor the second where the first character is a ^, nor the last character, the behavior is implementation-defined." So (assuming the draft did not change in this respect) for portable programs you can only trust [-09] or [09-] and [0123456789]. But are free to rely on [0-9] if you depend on compiler (library really) X and Y (Borland, glibc, ...), or Z for the other interpretation (the Watcom RTL, IBM VAC++, ...).
Applied
Mass change of RESOLVED bugs to CLOSED