Conference turris::decc

    I have reproduced both the VAXC and DECC behavior that you have
    indicated.  The DECC behavior is reproducible in our current sources.
    We will investigate this problem.

If the customer is looking for a workaround, it appears that replacing the 
fscanf with an fgets/sscanf combination works around the problem.


#include stdio
void main()
{
    FILE *screen;
    char buffer[100];
    char fred[100];

    screen = fopen ( "SYS$COMMAND", "r+" );

    fprintf ( screen, "Enter script file name > " );
    fgets (buffer, 100, screen);
    sscanf (buffer, "%s", fred);

/*    fflush( screen );  -- uncommenting this also makes the output appear
immediately */

    fprintf ( screen, "Enter script file name > " );
    fgets (buffer, 100, screen);
    sscanf (buffer, "%s", fred);

    fclose (screen);
}

I've had so many problems over the years with scanf()/fscanf() (or my faulty 
understanding of its behavior) that I always use the gets(), sscanf() 
combination. It precludes a whole lot of problems.

\dave

As always, I am impressed at the speed and accuracy of replies.
The customer was wondering if there was anything dodgy about 
what he was up to and wasn't really sure that it was a bug.
If it is a bug, however, is there any need for it to be 
escalated formally?

I'll try to keep him at bay with the workaround for now.

Thanks again, muchly.

Neil.

    The problem report has been recorded and will be worked.  If the
    customer is satisfied with the workaround, then there is nothing
    more that you need to do.  If, on the other hand, the customer is
    not able to use the workaround and proceed, then I strongly encourage
    you to file an IPMT case.
    
    Either way, please thank the customer for bringing this to our
    attention.  This particular problem truly amazes me since it is 
    day one behavior.

>    screen = fopen ( "SYS$COMMAND", "r+" );
>
>    fprintf ( screen, "Enter script file name > " );
>    fscanf ( screen, "%s", fred );
        
        From X3.159-1989 section 4.9.5.3 (The fopen Function) page 131
        
        	When a file is opened with update mode ('+' as the
        	second or third character in the above list of mode
        	argument values), both input and output may be
        	performed on the associated stream.  However, output
        	may not be directly followed by input without an
        	intervening call to the fflush function or to a file
        	positioning function (fseek, fsetpos, or rewind) and
        	input may not be directly followed by output without
        	an intervening call to a file position funciton,
        	unless the input operation encounters end-of-file.
        
        The above code violates that.  I'm not sure if we impose or
        document the above restriction though.  How does it work with
        the "required" sequence fprintf / fflush / fscanf?
        
        Dan

    > How does it work with
    >    the "required" sequence fprintf / fflush / fscanf?
    
    It doesn't.  Same behavior.

The customer has approx 2 million lines of code source to check through,
I would guess that searching through for all occurrences and changing 
them would be a real pain.

Stand by for an escalation.

Neil.

[This update was sent from D_SMITH on 28-MAY-1997 15:49:36.38]
[CTG Support responsible for next action, Problem is undefined]

My apologies for taking so long to update this case.  What is happening is
the result of unconsumed characters remaining in the buffer after the fscanf
call is complete.  This unconsumed character is the terminator.  As suggested
earlier, the easiest workaround is to change the format specifier to "%s\n".

The behavior of the DEC C RTL is ANSI compliant.  I point to the following
paragraph contained in the ANSI description of the fopen function:

     When a file is opened with update mode ('+' as the second or third
     character in the above list of mode argument values), both input
     and output may be performed on the associated stream.  However,
     output may not be directly followed by input without an intervening
     call to the fflush function or to a file positioning function
     (fseek, fsetpos, or rewind) and input may not be directly followed
     by output without an intervening call to a file position function,
     unless the input operation encounters end-of-file.


The reason I did not provide this update earlier is that when SYS$COMMAND
points to a terminal device, the DEC C RTL does not allow file positioning
functions to succeed.  The behavior is being changed to allow positioning
to the beginning of the buffer using all of the above mentioned positioning
functions.  The easiest to add to the program is rewind().

After spending approximately 40 hours trying to change the DEC C RTL to
not require the code changes in the application, I have come up empty.
Please reconsider adding the "\n" to your format specifier.  If you end
up adding a positioning call, then your application will require that the
next round of ECO kits be installed to function correctly.  The change in
the format specifier would not require the ECO kit.


Duane Smith