| > fputs() returns "0" after installing ECO ALPACRT01_071 (CSCPAT_2216).
>
> The data (14 bytes) is still written, but "0" for the return status
> is not correct. The documentation says EOF or a non-negative value
> is returned.
Actually, your test program shows, that fputs() returns non-zero value:
^^^^^^^^
> if (fputs("%!PS-ADOBE-3.0\n", fp))
> perror("fputs");
> else
> printf("print ok");
> ** $ RUN test
> ** fputs: error 0
This was the change done to the puts() and fputs() functions to return the
number of characters written instead of zero. Both zero and a positive number
of characters are pretty legal success status for fputs().
According to ANSI C, fputs()/puts() return "a nonnegative value" on success.
From DEC C RTL Reference Manual:
Return Values
Nonnegative value Indicates success
EOF Indicates an error
The goal of the change was to make OpenVMS' implementation consistent with
Digital Unix where the number of characters written is returned on success.
An application which relies on the old behaviour and expects fputs()/puts()
to return zero on success, should define logical name DECC$FPUTS_RETURN_ZERO
(any equivalence string).
Boris
|
| The "problem" was that we failed to include this change in the
release notes of the ECO kit. We will add a release note in the
next kit, noting that this release note should have been in the
first ECO kit.
Would like a second opinion on this...
This update not only after applying the ECO, but when upgrading to
OpenVMS Alpha V7.2 or later could have SERIOUS impact on existing
applications which check for "0". The logical name is cute, but
this PROBLEM does not jump out saying "please define the logical
name DECC$FPUTS_RETURN_ZERO", instead application fails after an
upgrade and then they call Digital. Maybe the programmer coded
this wrong, but it always worked!
When a customer calls Digital, do we first ask them to define a
number of logical names to see if the application works? This
logical is not application specific, so now we need to know how
the application used puts(), then we group the applications by
SYSTEM, GROUP, JOB, PROCESS, etc because this is how logical
names work. Application works for one user, but not another on the
same system, does this one user have a process logical DECC$...?
Just think about how the RTL change can affect existing applications,
then you begin to see how difficult support is.
This is a hard decission, can't be made easily. I can see the
impact for an application needing the correct return value, maybe
the logical needs to be defined to get the correct behavior (could
even add this to the documentation).
Just give this a second look, maybe nobody (other than DECdocument)
would check for "0" and this is water over the dam, but if this
change should impact a number of customers (third party, VAX ports,
etc) you'll be hearing from us.
Thanks for understanding... -drew
|
| Drew,
Thanks for the update. For now, we will be backing out the change
that was made in both the 7.1 ECO kit and in the RAVEN stream. I
will not say that I am happy to be doing this, but we have always
tried to not break applications. The justification for pulling it
is that the V7.1 ECO kit was just the tip of the iceberg. For the
printf optimization, coming in DEC C V5.6, to work, this change
would be made everywhere.
You can go ahead and tell Touch Technologies (DECdocument) that a
workaround for the V7.1 ECO kit environment is to define the logical.
You can even tell them that we did mistakedly included this change
in the ECO kit. I would also appreciate you informing them that
their code is wrong and should never assume that a return value of
zero indicates success. They can assume that EOF indicates an
error and that is how it should be coded. The code "happens" to
work, but is relying on behavior as opposed to the documented
interface to the routine. The code "will not" work on other
platforms such as Digital UNIX which is documented as returning the
number of characters written.
Duane
|
| That is good news. I wish there was a way to correct the RTL without
affecting exisitng applications.
When we determined that "0" was an invalid check, we immediately
informed Touch Technologies Inc that they would have to change their
code and once correctly coded would work on all versions of the RTL.
They never responded in one way or another, so I can't say whether
they planned a new release or cautioned against this ECO.
I'm still bothered by someone reporting an SPR because the count is
not returned or that a UNIX port fails... I suspect this is the
exception and would only fail with new development.
In closing, there are disadvantages to using RTLs...
-drew
|