Bug 15929
| Summary: | printf(1) truncates if it sees \000 | ||
|---|---|---|---|
| Product: | Documentation | Reporter: | Archie Cobbs <archie> |
| Component: | Books & Articles | Assignee: | freebsd-doc (Nobody) <doc> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Archie Cobbs
2000-01-06 01:20:00 UTC
Responsible Changed From-To: freebsd-alpha->freebsd-bugs Category should be 'bin' instead of 'alpha'. On Wed, 5 Jan 2000, Archie Cobbs wrote: # >Number: 15929 # >Category: alpha # >Synopsis: printf(1) truncates if it sees \000 # >Description: # # If '\000' is used in a printf(1) format string, the # string is trunctated at that point # # >How-To-Repeat: # # $ printf 'a\000truncated\n' # # This outputs "a" instead of "a<NUL>truncated" This really isn't an Alpha-specific problem is it? I just tried it on both i386 and Alpha boxes, and I get the similar results depending on the shell I use. None I tried give the behavior you suggest. Which shell were you using and what does 'which printf' say? Thanks. -steve On Wed, 05 Jan 2000 17:14:14 PST, Archie Cobbs wrote:
> $ printf 'a\000truncated\n'
>
> This outputs "a" instead of "a<NUL>truncated"
What would you expect to happen, given that printf(3) exhibits the same
behaviour?
Ciao,
Sheldon.
Sheldon Hearn writes: > > $ printf 'a\000truncated\n' > > > > This outputs "a" instead of "a<NUL>truncated" > > What would you expect to happen, given that printf(3) exhibits the same > behaviour? No, I'm not at all surprised. But that's not the point, of course. Either the bug should be fixed or else at least declared 'normal' and so documented in the man page. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com On Thu, 06 Jan 2000 09:33:49 PST, Archie Cobbs wrote:
> But that's not the point, of course. Either the bug should be fixed
> or else at least declared 'normal' and so documented in the man page.
That's the bit I'm after. What's the bug? From printf(3):
These functions return the number of characters printed (not including
the trailing `\0' used to end output to strings).
Presumably, you want some indication in the printf(1) manual page that a
null character in the string terminates it? Or is there something else
you think we can do?
Ciao,
Sheldon.
Sheldon Hearn writes: > > But that's not the point, of course. Either the bug should be fixed > > or else at least declared 'normal' and so documented in the man page. > > That's the bit I'm after. What's the bug? From printf(3): > > These functions return the number of characters printed (not including > the trailing `\0' used to end output to strings). > > Presumably, you want some indication in the printf(1) manual page that a > null character in the string terminates it? Or is there something else > you think we can do? Yes, that would be good enough. All I'm saying is that the behavior doesn't match what the man page says. If you forget printf(3), POSIX, etc. and just read the man page, there's nothing in it that says that \000 is in any way special, yet in functionality it is. A simple note in the BUGS section (or wherever) would be just fine with me. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com Does this adequately explain it? -Daniel Index: printf.1 =================================================================== RCS file: /src/cvs/src/usr.bin/printf/printf.1,v retrieving revision 1.7 diff -c -r1.7 printf.1 *** printf.1 1999/09/14 11:46:03 1.7 --- printf.1 2000/01/18 16:36:39 *************** *** 281,283 **** --- 281,289 ---- .Pp .Tn ANSI hexadecimal character constants were deliberately not provided. + .Pp + The escape sequence \e000 is the string terminator. When present in the + .Ar format , + the + .Ar format + will be truncated at the \e000 character. -- Daniel Hagan Computer Science CSE dhagan@cs.vt.edu http://www.cs.vt.edu/~dhagan/ Daniel Hagan writes: > Does this adequately explain it? Looks great, thanks. .. but why "\e000" and not "\000" ? > + .Pp > + The escape sequence \e000 is the string terminator. When present in the > + .Ar format , > + the > + .Ar format > + will be truncated at the \e000 character. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com On Tue, 18 Jan 2000, Archie Cobbs wrote: > Looks great, thanks. .. but why "\e000" and not "\000" ? Well, I'm not familiar with man-page source formats (Troff?), but that's what it appears to take to make a \000 appear in the output. For reference, refer to lines 90-106 where the ANSI escape sequences are listed. \000 resulted in \00 when I tried it. Daniel -- Daniel Hagan Computer Science CSE dhagan@cs.vt.edu http://www.cs.vt.edu/~dhagan/ Daniel Hagan writes: > > Looks great, thanks. .. but why "\e000" and not "\000" ? > > Well, I'm not familiar with man-page source formats (Troff?), but that's > what it appears to take to make a \000 appear in the output. For > reference, refer to lines 90-106 where the ANSI escape sequences are > listed. \000 resulted in \00 when I tried it. Ah, of course.. my ignorance :-) -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com Responsible Changed From-To: freebsd-bugs->freebsd-doc Patch for -doc. This way we will not loose track of it. State Changed From-To: open->closed Daniel Hagan <dhagan@cs.vt.edu>'s patch was committed. |
