In <[EMAIL PROTECTED]>, on 06/23/2005
at 07:23 PM, Joe Zitzelberger <[EMAIL PROTECTED]> said:
>While the preprocessors usually do a decent job, blind faith in their
> abilities is excessive. There are many cases where they can produce
> errors in a compile. How will having more documentation about a
>perfectly valid mangled literal help one diagnose a preprocessor
>problem?
By explaining the nature of the munging? By suggesting[1] that the
programmer examine the literal in hex?
>It won't.
Sure it will; see above.
>In all contexts, this message means you have a screwed up DBCS
>literal in your source code.
I don't understand CJK languages. Why would a reasonable author expect
me to know what DBCS is in the first place, much less what SI and SO
are. None of those are terms used by COBOL programmers not involved in
Asian languages.
>and that is exactly what the self-describing message says.
There was no self-describing message. There was an opaque message that
was meaningless to its target audience. Even had there been an
explanation it would have been appropriate to fix the message
contents.
Now, admittedly I understood the message, but my background is broader
than that of most programmers, and even I would have been frustrated
by the absence of the data in error from the message. It would have
been better had the message contained the hexadecimal code points for
SI, SO and the literal text in error.
>To get any sort of a constructive fix a programmer will have to quit
> trying to lay blame on the compiler and address the root cause --
>the preprocessor.
Finger pointing. The message itself is broken, which makes it more
difficult than it needs to be for the programmer to identify the
preprocessor as the problem. The message is an issue in contexts where
there is no preprocessor.
>No amount of message manuals from IBM will ever help
>them in this effort
Wrong. A manual that suggested looking at the literal in hexadecimal
and suggested that the literal might have come from a preprocessor
would have saved a lot of time in the incident under discussion.
>and requests for such are only trying to treat
>the symptom while ignoring the real problem.
The message is the real problem; the preprocessor is only one of the
avenues for hitting it.
Note: I have frequently defended IBM error messages as adequate and
told people to RTFM when they couldn't understand them, but in this
case the message is inadequate and there is no FM.
[1] Raising the question of why the error message didn't include a
brief section of the literal in hex.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
