Hi,
I've attached simple cpp program which demonstrates the problem.
The program works fine from cmd.exe, but fails when started from cygwin.
The program does the following:
- The main thread creates a helper thread which reads stdin and prints
the data read.
- stdin is read via ReadFile() Win32
Hi,
I've attached simple cpp program which demonstrates the problem.
The program works fine from cmd.exe, but fails when started from cygwin.
The program does the following:
- The main thread creates a helper thread which reads stdin and prints
the data read.
- stdin is read via ReadFile()
Alexey Zakharov wrote on 25 April 2008 15:48:
The program does the following:
- The main thread creates a helper thread which reads stdin and prints
the data read.
- stdin is read via ReadFile() Win32 API function.
No, that's *not* stdin. Stdin is file descriptor zero, and you aren't
Corinna Vinschen corinna-cygwin at cygwin.com writes:
You should nevertheless use /dev/com4 or /dev/ttyS3. I might be wrong
but it still looks like you don't quite see what Brian was up to.
Corinna
Hmm...I think I see what you're getting at. I'm (obviously) not really all that
On Oct 22 21:50, Todd Rearick wrote:
Brian Dessent brian at dessent.net writes:
What I was trying to emphasize is that passing COM4 to open() in a
Cygwin program sets you up for a world of hurt...
Brian
It's even worse than you think. In this case...COM4 is not even a real serial
Brian Dessent brian at dessent.net writes:
Your test case does not compile...
...good point...I was just trying to cut down on the length of the post...but
it really didn't save that much anyway...I'll attach the full code on the end
of this post in case anyone wants to try it.
Is there
Todd Rearick wrote:
#define OUTPUT_DEVICE COM4
*cough*
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
On Oct 22 07:06, Todd Rearick wrote:
while(1)
{
char buf[80];
int len;
len = recv(infd,buf,1,0);
if (len 1)
{
printf(len = %d\n,len);
printf(errno = %d\n,errno);
printf(This
Corinna Vinschen corinna-cygwin at cygwin.com writes:
On Oct 22 07:06, Todd Rearick wrote:
while(1)
{
char buf[80];
int len;
len = recv(infd,buf,1,0);
if (len 1)
{
printf(len = %d\n,len);
Brian Dessent brian at dessent.net writes:
#define OUTPUT_DEVICE COM4
*cough*
Like I said. I'm not having a problem with output. The program fails even
when I run it with the options -x -din this case, COM4 is never even
opened..and no attempts are made to write to it. All
On Oct 22 13:31, Todd Rearick wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
What you're entirely missing at this point is the fact that a return
value of 0 (zero) indicates EOF. You don't test for this. Instead
you're also testing errno in case of EOF, which has no meaning
Corinna Vinschen corinna-cygwin at cygwin.com writes:
This I can't tell you since I don't know the server side of the
connection. It's normal to get EOF (== 0) over and over again if EOF
has been detected. This behaviour can be observed on, for instance,
Linux, too.
Well..I thought it
Todd Rearick trearick_news at cox.net writes:
Thanks for all of your help. Unfortunately...now the problem isn't really
directly under my control...hope I can find a solution.
HAHA!!! I'm such an idiot. I have firewall software running on the 2 PC's
that don't work (Norton Internet
On Oct 22 14:58, Todd Rearick wrote:
Todd Rearick trearick_news at cox.net writes:
Thanks for all of your help. Unfortunately...now the problem isn't really
directly under my control...hope I can find a solution.
HAHA!!! I'm such an idiot. [...]
No worries, me too. Thanks to your
Todd Rearick wrote:
#define OUTPUT_DEVICE COM4
*cough*
Like I said. I'm not having a problem with output. The program fails even
when I run it with the options -x -din this case, COM4 is never even
opened..and no attempts are made to write to it. All the program does in this
Brian Dessent brian at dessent.net writes:
What I was trying to emphasize is that passing COM4 to open() in a
Cygwin program sets you up for a world of hurt...
Brian
It's even worse than you think. In this case...COM4 is not even a real serial
port...but a virtual serial port constructed
I've created a simple program that is supposed to do the following:
1.) Open a socket to port 8080 on the local machine localhost
2.) Open a COM port
3.) Read data that comes in on the socket and write the same data out the COM
port
...great performance is not a requirement...so I did the
[EMAIL PROTECTED] wrote:
I'm assuming I'm doing something wrong here...and I'm just lucky to have it
work right on my laptop...can anyone help?
Your test case does not compile, because you've omitted the #includes
and #defines. I think you will find that posting code that someone can
Dear colleagues,
I encountered some unexpected problems when opening a data file in a
FORTRAN program and reading characters from it. I work on WINDOWS XP and
I downloaded today the latest version of cygwin from
http://sources.redhat.com/cygwin/. g77 claims to be version 3.3.3
The problem
Is anybody aware of any issue related to the system
call of read(filedescriptor, buffer, nbytes) under
cygwin? The function is supposed to return 0 if EOF
or # of bytes read otherwise. I get a 4GB read -
clearly not correct (nbytes == 277).
Appreciating,
Nic. Santean
20 matches
Mail list logo
