sveer@sssab.se (Sven L Eriksson) (01/03/90)
Everybody knows that escape sequences like these works fine with printf
printf("\thello\n") ;
Usually these escape sequences are recognized and converted by the
compiler.
However SVID (Issue 2) states that the format string may contain these
escape sequences. This implies that it is possible for the actual
format string printf sees to contain the characters '\' and 'n', and
still be converted into a newline. This whould be very convenient if
the format string is received from elsewhere, e.g. stdin.
(X/Open portability guide (issue 2) does not mention these escape
sequences, but says that the printf() chapter is derived from SVID
issue 1.)
Is this a correct interpretation that printf() (according to SVID)
should handle escape sequences or is SVID wrong?
--
- Sven L Eriksson, 3S AB (Scandinavian System Support AB)
- Address: Agatan 4, Box 535, S-581 05 Linkoping, Sweden
- Phone: +46-13-11 16 60 Fax: +46-13-11 51 93
- Email: sveer@sssab.se UUCP: uunet!mcvax!sssab!sveerdavidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (01/04/90)
In article <1990Jan3.144808.6319@sssab.se> sveer@sssab.se (Sven L Eriksson) writes: | Everybody knows that escape sequences like these works fine with printf | | printf("\thello\n") ; | | Usually these escape sequences are recognized and converted by the | compiler. If the compiler is one for the C language, ALL escape sequences are converted to their single character form. Not usually, always. | | However SVID (Issue 2) states that the format string may contain these | escape sequences. This implies that it is possible for the actual | format string printf sees to contain the characters '\' and 'n', and | still be converted into a newline. This whould be very convenient if | the format string is received from elsewhere, e.g. stdin. I hope your misreading this... it isn't common to include stuff like this, but an error message might well do so. If I define a string as "xx\\n" it will have two x's, one \, one n, and a terminating zero byte. That is what you get printed with existing C compilers, and I doubt that SVID breaks it. For that matter, what has SVID got to do with the C language, and why are they even mentioning this? X3J11 didn't respecify the unix calls ;-) -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
barmar@think.com (Barry Margolin) (01/04/90)
In article <1974@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: >For that matter, what has SVID got to do with the C >language, and why are they even mentioning this? X3J11 didn't respecify >the unix calls ;-) At the time the SVID was being developed, there was no C standard, so apparently AT&T included some standard libraries as part of the System V spec. Otherwise, a system could claim to be compatible with System V even though its C libraries are incompatible. Since most programs use more than just the system calls, specifying just the Unix system calls would be insufficient to promote a decent amount of portability. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
gwyn@smoke.BRL.MIL (Doug Gwyn) (01/05/90)
In article <1990Jan3.144808.6319@sssab.se> sveer@sssab.se (Sven L Eriksson) writes: >However SVID (Issue 2) states that the format string may contain these >escape sequences. This implies that it is possible for the actual >format string printf sees to contain the characters '\' and 'n', and >still be converted into a newline. This whould be very convenient if >the format string is received from elsewhere, e.g. stdin. You're right about the SVID (Issue 3 as well as Issue 2) implying that the two adjacent character codes '\' and 'n' in the format string are treated as meaning "output a new-line". However, that is simply a mistake in the SVID, which should have called these "control characters" or better yet have described the control actions separately from the printf() description. In fact, such an implementation would run directly counter to the C Standard (which requires that these "ordinary characters" be output without interpretation by printf()), and AT&T has indicated that that was NOT their intent. Presumably, if you bring this to AT&T's attention it might get fixed in a future Issue of the SVID.