Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Weird I/O bug

Reply
Thread Tools

Weird I/O bug

 
 
Spencer Rugaber
Guest
Posts: n/a
 
      09-06-2008
I ran across an interesting bug, which I have isolated to the
following:

/* 1*/ import java.io.*;
/* 2*/ public class WordCount {
/* 3*/ public static void main (String[] args) {
/* 4*/ InputStreamReader tr = new InputStreamReader(System.in);
/* 5*/ try {
/* 6*/ tr.read(); /* Input intentionally ignored */
/* 7*/ } catch (Exception e) {
/* 8*/ System.exit(-1);
/* 9*/ }
/*10*/ System.out.println(0);
/*11*/ System.exit(0);
/*12*/ }
/*13*/ }

When run with input consisting of an empty file from standard in,
the output is a line consisting only of "0D".

If input is from a file, rather than the command line, the program
works, printing only "0". If lines 4-9 are removed, the program
works.

The problems, occurs in Java 1.3, 1.4, 1.5. It occurs on Linux,
Solaris and Windows systems.

The only thoughts I have are 1) that somehow stdin and stdout both
being the terminal confuses things, or 2) somehow, conversion between
bytes and ints is a problem.

I can't be the first person to notice this problem. All suggestions
appreciated.

Thanks.

Spencer
--

Spencer
-------

Spencer Rugaber
2406 Klaus Advanced Computing Building
College of Computing, Georgia Tech, Atlanta GA 30332-0280
Internet: http://www.velocityreviews.com/forums/(E-Mail Removed)
Phone: (404) 894-8450 Fax: (404) 894-9442
WWW: http://www.cc.gatech.edu/fac/Spencer.Rugaber
 
Reply With Quote
 
 
 
 
Mark Space
Guest
Posts: n/a
 
      09-06-2008
Spencer Rugaber wrote:

> When run with input consisting of an empty file from standard in,
> the output is a line consisting only of "0D".
>
> If input is from a file, rather than the command line, the program
> works, printing only "0". If lines 4-9 are removed, the program
> works.


For me it simply prints 0 both times, which I think is correct. What
output where you expecting?
 
Reply With Quote
 
 
 
 
Roedy Green
Guest
Posts: n/a
 
      09-06-2008
On 5 Sep 2008 21:44:27 -0400, (E-Mail Removed) (Spencer Rugaber)
wrote, quoted or indirectly quoted someone who said :

>When run with input consisting of an empty file from standard in,
>the output is a line consisting only of "0D".


that is as invalid file. It shoulds be either 0D 0A or 0A.

The problem is similar to having only half of a multibyte unicode
encoding.

There needs to be an InvalidDataException.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      09-06-2008
Roedy Green wrote:
> On 5 Sep 2008 21:44:27 -0400, (E-Mail Removed) (Spencer Rugaber)
> wrote, quoted or indirectly quoted someone who said :
>> When run with input consisting of an empty file from standard in,
>> the output is a line consisting only of "0D".

>
> that is as invalid file. It shoulds be either 0D 0A or 0A.
>
> The problem is similar to having only half of a multibyte unicode
> encoding.


Not at all.

CR is a valid line terminator in older versions of Mac OS.

0x0D is valid file content not being a line terminator with
counted record formats.

Arne
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      09-06-2008
On 5 Sep 2008 21:44:27 -0400, (E-Mail Removed) (Spencer Rugaber)
wrote, quoted or indirectly quoted someone who said :

>When run with input consisting of an empty file from standard in,
>the output is a line consisting only of "0D".


i presume you mean one 8-bit hex char 0d, not two chars 0 D
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
Reply With Quote
 
John B. Matthews
Guest
Posts: n/a
 
      09-06-2008
In article <g9sn9r$(E-Mail Removed)>,
(E-Mail Removed) (Spencer Rugaber) wrote:

[...]
> When run with input consisting of an empty file from standard in,
> the output is a line consisting only of "0D".
>
> If input is from a file, rather than the command line, the program
> works, printing only "0". If lines 4-9 are removed, the program
> works.

[...]

$ java -version
java version "1.5.0_13"
....
$ touch temp.txt
$ java WordCount < temp.txt
0
$ java WordCount
0D

The last result required control-D (EOT) to terminate input. Is that
what you're seeing?

--
John B. Matthews
trashgod at gmail dot com
home dot woh dot rr dot com slash jbmatthews
 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      09-06-2008
On Sat, 6 Sep 2008, John B. Matthews wrote:

> In article <g9sn9r$(E-Mail Removed)>,
> (E-Mail Removed) (Spencer Rugaber) wrote:
>
> [...]
>> When run with input consisting of an empty file from standard in,
>> the output is a line consisting only of "0D".
>>
>> If input is from a file, rather than the command line, the program
>> works, printing only "0". If lines 4-9 are removed, the program
>> works.

> [...]
>
> $ java -version
> java version "1.5.0_13"
> ...
> $ touch temp.txt
> $ java WordCount < temp.txt
> 0
> $ java WordCount
> 0D
>
> The last result required control-D (EOT) to terminate input. Is that
> what you're seeing?


This is what i assumed he meant - i think this discussion of hex values is
off-beam. And i get the same result on MacOS X, FWIW.

I think what this is is the shell (or possibly the terminal driver, or
maybe even the java binary) echoing "^D" to the screen when you type that
escape sequence - that's standard behaviour. When the app then prints that
0, it overwrites the ^, and you see 0D.

If you modify the program to print the empty string, then what you see on
screen is "^D". If you modify it to print 99, you just see the 99. If you
modify it not to call print at all, then you very briefly see ^D, but this
is then overwritten by the prompt that appears after the program
terminates (or at least, i do - your console may be faster than mine!). If
you run the unmodified program, but redirect the output to a file, it just
contains 0. All this fits with the explanation i give above.

tom

--
Ed editor textorum probatissimus est -- Cicero, De officiis IV.7
 
Reply With Quote
 
Spencer Rugaber
Guest
Posts: n/a
 
      09-06-2008
In article <(E-Mail Removed)>,
Roedy Green <(E-Mail Removed)> wrote:
>>When run with input consisting of an empty file from standard in,
>>the output is a line consisting only of "0D".

>
>i presume you mean one 8-bit hex char 0d, not two chars 0 D


What I see on the screen is a line by itself containing only the
characters 0 and D, adjacent to each other. This is not what I
expected to see, which was a 0 by itself on a line.

Spencer
--

Spencer
-------

Spencer Rugaber
2406 Klaus Advanced Computing Building
College of Computing, Georgia Tech, Atlanta GA 30332-0280
Internet: (E-Mail Removed)
Phone: (404) 894-8450 Fax: (404) 894-9442
WWW: http://www.cc.gatech.edu/fac/Spencer.Rugaber
 
Reply With Quote
 
Spencer Rugaber
Guest
Posts: n/a
 
      09-06-2008
In article <(E-Mail Removed)>,
John B. Matthews <(E-Mail Removed)> wrote:
>The last result required control-D (EOT) to terminate input. Is that
>what you're seeing?


Exactly.

Spencer
--

Spencer
-------

Spencer Rugaber
2406 Klaus Advanced Computing Building
College of Computing, Georgia Tech, Atlanta GA 30332-0280
Internet: (E-Mail Removed)
Phone: (404) 894-8450 Fax: (404) 894-9442
WWW: http://www.cc.gatech.edu/fac/Spencer.Rugaber
 
Reply With Quote
 
Spencer Rugaber
Guest
Posts: n/a
 
      09-06-2008
In article <(E-Mail Removed)> ,
Tom Anderson <(E-Mail Removed)> wrote:
>I think what this is is the shell (or possibly the terminal driver, or
>maybe even the java binary) echoing "^D" to the screen when you type that
>escape sequence - that's standard behaviour. When the app then prints that
>0, it overwrites the ^, and you see 0D.


>If you modify the program to print the empty string, then what you see on
>screen is "^D". If you modify it to print 99, you just see the 99. If you
>modify it not to call print at all, then you very briefly see ^D, but this
>is then overwritten by the prompt that appears after the program
>terminates (or at least, i do - your console may be faster than mine!). If
>you run the unmodified program, but redirect the output to a file, it just
>contains 0. All this fits with the explanation i give above.


This sounds reasonable, but why don't I see the ^D when I talk to the
shell directly, as with the command "cat" (by itself taking input from
the command line). If that input is only ^D, then nothing is echoed.

So Java's behavior still seems weird to me. Is this what I should
expect from Java? I could find no justification for it in the API
description.

Thanks.

Spencer
--

Spencer
-------

Spencer Rugaber
2406 Klaus Advanced Computing Building
College of Computing, Georgia Tech, Atlanta GA 30332-0280
Internet: (E-Mail Removed)
Phone: (404) 894-8450 Fax: (404) 894-9442
WWW: http://www.cc.gatech.edu/fac/Spencer.Rugaber
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: A Weird Appearance for a Weird Site Beauregard T. Shagnasty HTML 1 01-21-2011 04:17 PM
Re: A Weird Appearance for a Weird Site richard HTML 0 01-21-2011 07:10 AM
Re: A Weird Appearance for a Weird Site dorayme HTML 1 01-21-2011 06:51 AM
Re: A Weird Appearance for a Weird Site richard HTML 0 01-21-2011 06:46 AM
*bug* *bug* *bug* David Raleigh Arnold Firefox 12 04-02-2007 03:13 AM



Advertisments