On 28-Jan-2003 John Reynolds~ wrote:
> 
> We need to echo a string *and* a NUL character (\0) into a stream so that a
> program that delimits its input by \0 characters will do the right thing.
> 
> He had been doing this via printf(1) like so:
> 
>   % printf "some string\0" | some_process
> 
> however, it never worked under FreeBSD. Upon further inspection, our
> printf(1) does not work like the GNU one with the above string. Consider
> this from a linux box:
> 
>   linux [~]<374>% printf "foo\0bar\0" | od -c
>   0000000   f   o   o  \0   b   a   r  \0
>   0000010
> 
> Now the same command from a FreeBSD (4.7-STABLE) box:
> 
>   freebsd [~]<76>% printf "foo\0bar\0" | od -c
>   0000000    f   o   o                                                    
>   0000003

Works fine under -current:

$ printf "foo\0bar\0" | od -c
0000000    f   o   o  \0   b   a   r  \0

> After checking the man pages, I also used a complete octal constant but that
> doesn't work either:
> 
>   linux [~]<376>% printf "foo\0000" | od -c
>   0000000   f   o   o  \0
>   0000004
> 
>   freebsd [~]<77>% printf "foo\0000" | od -c
>   0000000    f   o   o                                                    
>   0000003

This also works under -current:

$ printf "foo\0000" | od -c
0000000    f   o   o  \0                                                
0000004

> I checked our implementation and it seems wrong. The first step done in the
> source code is to interpolate all escape sequences. However, when it does
> this and the octal number happens to be "0", this fact is not "captured"
> later on and that 0 becomes the NULL terminator for the string and nothing
> else is printed after it.
> 
>   linux [~]<379>% printf "foo\0%d" 4 | od -c
>   0000000   f   o   o  \0   4
>   0000005
>   
>   freebsd [~]<78>% printf "foo\0%d" 4 | od -c
>   printf: missing format character
>   0000000    f   o   o                                                    
>   0000003

This also works under -current:

$ printf "foo\0%d" 4 | od -c
0000000    f   o   o  \0   4                                            
0000005

> This behavior has been checked on HP-UX and Solaris and those two systems are
> identical to the Linux one. It seems to me that our printf(1)'s behavior is
> incorrect. Comments?

It may very well be that printf (or libc?) has a bug under -stable.  Are you
using any unusual optimization settings in /etc/make.conf, by the way?  When
did you last upgrade?
 
-- 
Conrad Sabatier <[EMAIL PROTECTED]> - "In Unix veritas"


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message

Reply via email to