use of serial and parrallel port using C

[SM Ryan]

# Your code does not open a serial port on my fully ANSI-C conforming
# MS windows system. Also it does not open a serial port on my
# Linux system, where my usual username does not have permission to
# open those devices. Please respond when you have fixed your code
# so that it works on all ANSI-C conforming systems (including those
# with no serial ports).

Sorry, kiddo, but wrong answer.

You're whinging that different implementations may have different results
for the same code, but this can happen for something as simple (4.2-4.1).

If you really want to claim that any code that can have different results
is not ANSI C, then you're saying all I/O and real arithmetic is not ANSI
C. Doesn't leave alot left. Even something like
fopen("abcdefghijklmnopqrstuvwxyz","w") will fail on the system C was
originally implemented on.

# > if (!system(0)) return 0;
#
# Undefined behaviour: system() in the C standard library expects
# a pointer and you gave it an int. (You should fix this by
# including stdlib.h)

I think you better read the definition of system() a little more closely.
And you should also learn how 0 is really parsed in C. The behaviour is
fully defined and produces an important result.

# It is impossible to portably talk to a device in ANSI C.

You answerred the wrong question. The original question was whether
it was possible to talk to a serial port or parallel port in ANSI C.
The answer is yes contingent on the system makes the ports accessible
and configurable through fopen, system, etc.

 

[Flash Gordon]

# Your code does not open a serial port on my fully ANSI-C conforming
# MS windows system. Also it does not open a serial port on my
# Linux system, where my usual username does not have permission to
# open those devices. Please respond when you have fixed your code
# so that it works on all ANSI-C conforming systems (including those
# with no serial ports).

Sorry, kiddo, but wrong answer.

You're whinging that different implementations may have different
results for the same code, but this can happen for something as simple
(4.2-4.1).

If you really want to claim that any code that can have different
results is not ANSI C, then you're saying all I/O and real arithmetic
is not ANSI C. Doesn't leave alot left. Even something like
fopen("abcdefghijklmnopqrstuvwxyz","w") will fail on the system C was
originally implemented on.

That is defined as opening the file in the specified mode if it is
possible to. opening /dev/whatever is not defined as opening a device,
it just happens that on some systems is does.

# > if (!system(0)) return 0;
#
# Undefined behaviour: system() in the C standard library expects
# a pointer and you gave it an int. (You should fix this by
# including stdlib.h)

I think you better read the definition of system() a little more
closely. And you should also learn how 0 is really parsed in C. The
behaviour is fully defined and produces an important result.

You did not include stdlib.h therefor the compiler does not know that
system takes a pointer and thus won't convert 0 to a null pointer. On
some implementations this will mean setting a data register to 0 and not
touching the address register from which the system function will read
the pointer value. So Old Wolf is correct in what he said.

You should learn C.

# It is impossible to portably talk to a device in ANSI C.

You answerred the wrong question. The original question was whether
it was possible to talk to a serial port or parallel port in ANSI C.
The answer is yes contingent on the system makes the ports accessible
and configurable through fopen, system, etc.

No, the original question was how to do it and your suggestion will not
work on most systems including the systems the OP is most likely to be
using. Therefor the question belongs on a group dedicated to the
appropriate system where they will know such things as how to get a
parallel port into a mode where you can read from it, something it may
not be in by default.