Thread View: comp.lang.java.api
6 messages
6 total messages
Started by Michael Tobin
Thu, 07 Dec 2000 04:18
Strange I/O behavior
Author: Michael Tobin
Date: Thu, 07 Dec 2000 04:18
Date: Thu, 07 Dec 2000 04:18
84 lines
4402 bytes
4402 bytes
I've been trying to get a java program to run on my Mac. It is a
microprogramming simulator (for use with "Structured Computer
Organization" by Andrew Tanenbaum). The package comes with an assembly
language assembler and a microprogram assembler. The problem is that it
runs perfectly well on Windows and Unix systems, but for some reason, it
will not work on my Mac. After much effort and debugging, I have found
the culprit (the variable 'in' is of type BufferedInputStream):
private String readLine()
{
int ctemp;
String s = new String();
try
{
int ch = 0;
while (((char)ch) != '\n' && ch > -1)
{
ch = in.read();
if (ch == -1 && s.length() == 0)
{
return null;
}
if (ch == '/')
{
ctemp = in.read();
if ((char)ctemp == '/')
{
ch = in.read();
/***********************************************************************/
/* This loop right HERE!
while (((char)ch) != '\n' && ch > -1)
{
ch = in.read();
}
/**********************************************************************/
lineno++;
return s + " ";
}
else if (ch != 13)
{
s = s + ((char)ch) +
Character.toLowerCase((char)ctemp);
}
}
if (ch != '\n' && ch > -1 && ch != 13)
{
if ((char)ch == '\'')
{
ctemp = in.read();
s = s + (char)ch + (char)ctemp;
}
else
{
s = s + Character.toLowerCase((char)ch);
}
}
}
lineno++;
return s;
}
catch (Exception e)
{
e.printStackTrace();
}
return s;
}
For some reason, this has to do with the Macintosh style line breaks
because if I resave my files with Unix line breaks everything compiles
just fine. But for some reason it will not work on a Macintosh. Most
of my test programs start out with a bunch of commented lines (in the
assembly language comments are delimited with the // marker just like in
Java or C++). It works just fine until it reaches the statement
'ch=in.read()' in the area I marked off. Then it seems that the read
method won't return (when I try stepping through the code line by line)
or just returns -1 which indicates it has reached the end of the stream.
however, I've inspected the input buffer and see that there are is an
entire list of valid input data to be read. Does anyone have any idea
what could possibly be going on here? I know it's rather
complicated--at least it seems to me--but any help on why it works with
Unix line breaks but not Mac ones would be greatly appreciated. Thanks!
Mike Tobin
Re: Strange I/O behavior
Author: Eric Albert
Date: Thu, 07 Dec 2000 00:00
Date: Thu, 07 Dec 2000 00:00
21 lines
1390 bytes
1390 bytes
In article <mwron-0712001211280001@c243286-a.bcreek1.mi.home.com>,
mwron@metrowerks.com (MWRon) wrote:
> Try
>
> while (((char)ch) != ('\n' || '\r') && ch > -1)
>
> Note I'm a C programer not Java so I'd appreciate any corrections on my
> assumptions.
Your code won't do the right thing in C and won't compile in Java, but
it's the right idea. :) I think this is what you meant:
while((char) ch != '\n' && (char) ch != '\r' && ch > -1)
In C, the ('\n' || '\r') will evaluate to 1, so you'd get while(ch != 1
&& ch > -1), which ain't quite what you're expecting. :)
-Eric
--
Eric Albert ejalbert@stanford.edu
http://www.stanford.edu/~ejalbert/
Re: Strange I/O behavior
Author: MWRon
Date: Thu, 07 Dec 2000 00:00
Date: Thu, 07 Dec 2000 00:00
23 lines
1573 bytes
1573 bytes
In article <ejalbert-B35454.10542507122000@nntp.stanford.edu>, Eric Albert
<ejalbert@stanford.edu> wrote:
>Your code won't do the right thing in C and won't compile in Java, but
>it's the right idea. :) I think this is what you meant:
> while((char) ch != '\n' && (char) ch != '\r' && ch > -1)
>In C, the ('\n' || '\r') will evaluate to 1, so you'd get while(ch != 1
>&& ch > -1), which ain't quite what you're expecting. :)
<slapping forehead> that is what I get for trying to think with verifying
anything.
Thanks for the catch.
Ron
--
CodeWarrior PersonalJava Edtion
The speed, integration, and flexibility of the product are truly impressive.
Java Report Online
http://www.javareport.com/html/from_pages/product_review.cfm?articleID=1616
Metrowerks "Software Starts Here" MWRon@metrowerks.com
Re: Strange I/O behavior
Author: MWRon
Date: Thu, 07 Dec 2000 17:11
Date: Thu, 07 Dec 2000 17:11
39 lines
2421 bytes
2421 bytes
In article <mtobin-99A222.22175206122000@news.earthlink.net>, Michael
Tobin <mtobin@macalester.edu> wrote:
>I've been trying to get a java program to run on my Mac. It is a
>microprogramming simulator (for use with "Structured Computer
>Organization" by Andrew Tanenbaum). The package comes with an assembly
>language assembler and a microprogram assembler. The problem is that it
>runs perfectly well on Windows and Unix systems, but for some reason, it
>will not work on my Mac. After much effort and debugging, I have found
>the culprit (the variable 'in' is of type BufferedInputStream):
>/***********************************************************************/
> /* This loop right HERE!
> while (((char)ch) != '\n' && ch > -1)
> {
> ch = in.read();
> }
>/**********************************************************************/
It is because Macs use a different line ending than UNIX does. the 0xA
and 0xD are turned around.
Try
while (((char)ch) != ('\n' || '\r') && ch > -1)
Note I'm a C programer not Java so I'd appreciate any corrections on my
assumptions.
Ron
--
CodeWarrior PersonalJava Edtion
The speed, integration, and flexibility of the product are truly impressive.
Java Report Online
http://www.javareport.com/html/from_pages/product_review.cfm?articleID=1616
Metrowerks "Software Starts Here" MWRon@metrowerks.com
Re: Strange I/O behavior
Author: Ron Webster
Date: Fri, 08 Dec 2000 01:24
Date: Fri, 08 Dec 2000 01:24
14 lines
1862 bytes
1862 bytes
Wait a minute... MWRon wrote: > > It is because Macs use a different line ending than UNIX does. the 0xA > and 0xD are turned around. > I thought that Macs use 0x0d line termination, UNIX uses 0x0a line termination, and DOS uses 0x0d 0x0a line termination, so any code that works under all platforms has to hunt for both CR and LF. Many programs have been burned by that, including Netscape, early PC versions of which couldn't read the the bookmark file created on the Mac version until the LFs had been added.
Re: Strange I/O behavior
Author: MWRon
Date: Fri, 08 Dec 2000 14:42
Date: Fri, 08 Dec 2000 14:42
33 lines
2312 bytes
2312 bytes
In article <3A303861.F2CF902C@optonline.net>, ronw@optonline.net wrote: >Wait a minute... waiting ....... :) >MWRon wrote: > >> >> It is because Macs use a different line ending than UNIX does. the 0xA >> and 0xD are turned around. >> > >I thought that Macs use 0x0d line termination, UNIX uses 0x0a line termination, >and DOS uses 0x0d 0x0a line termination, so any code that works under all >platforms has to hunt for both CR and LF. Many programs have been burned by >that, including Netscape, early PC versions of which couldn't read the the >bookmark file created on the Mac version until the LFs had been added. but.... if unix has 0xA and Windows has 0xD/0xA if you searched for 0xA while you would always get an extra "CR' in the Windows code it would parse the line correctly. I assumed that Java just ignores 'CR'. However since Macs have no 0xA they never get an end of line. Ron -- CodeWarrior PersonalJava Edtion The speed, integration, and flexibility of the product are truly impressive. Java Report Online http://www.javareport.com/html/from_pages/product_review.cfm?articleID=1616 Metrowerks "Software Starts Here" MWRon@metrowerks.com
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads