compile C programs with UNIX system calls (= Unix Programs??)

[jrefactors]

If the C programs have UNIX system calls such as fork(), alarm(),
etc.., we should call it UNIX programs, not traditional C programs?

We couldn't compile the programs with system calls using VC++ compiler.
I need to compile it under UNIX platform. correct? any other
alternatives??

Please advise. Thanks!!

[Rich Teer]

On Mon, 3 Jan 2005 jr********@hotmail.com wrote:

If the C programs have UNIX system calls such as fork(), alarm(),
etc.., we should call it UNIX programs, not traditional C programs?
WHo calls them C programs? Personally, I'd call the UNIX programs.
We couldn't compile the programs with system calls using VC++ compiler.
What do you expect? Windoze programs that compile fine on VC++
probably won't work on UNIX...
I need to compile it under UNIX platform. correct? any other
alternatives??

I don't understand the question. If you're targeting a certain platform,
then of course you need to compile on it. Trying to run (say) a program
that was compiled on Windoze on Solaris will get you nowhere: you need to
compile to program on Solaris if that is what you're targeting.

--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming"

. * * . * .* .
. * . .*
President, * . . /\ ( . . *
Rite Online Inc. . . / .\ . * .
.*. / * \ . .
. /* o \ .
Voice: [phone] * '''||''' .
URL: http://www.rite-online.net ******************

[Chris Croughton]

On Tue, 04 Jan 2005 03:18:18 GMT, Rich Teer
<ri*******@rite-group.com> wrote:

On Mon, 3 Jan 2005 jr********@hotmail.com wrote:

If the C programs have UNIX system calls such as fork(), alarm(),
etc.., we should call it UNIX programs, not traditional C programs?
WHo calls them C programs? Personally, I'd call the UNIX programs.

If they are written in C they are C programs, whatever libraries they
happen to use. Calling them "UNIX programs" helps no one, since a "UNIX
program" could be written in any language from raw binary to COBOL.

We couldn't compile the programs with system calls using VC++ compiler.

What do you expect? Windoze programs that compile fine on VC++
probably won't work on UNIX...

Many won't, many will (if they have been written portably).

I need to compile it under UNIX platform. correct? any other
alternatives??

I don't understand the question. If you're targeting a certain platform,
then of course you need to compile on it.

Never heard of a cross-compiler? I would be really stuck if I had to
compile my programs on the target platform, mobile phones usually don't
support compilers...
Trying to run (say) a program
that was compiled on Windoze on Solaris
You mean "targetted for Windoze".
will get you nowhere: you need to
compile to program on Solaris if that is what you're targeting.

Or use a cross-compiler which targets Solaris. I have one, gcc running
under Cygwin on Windoze targetting a Sparc machine (and others
targetting ARM, M68000 and other platforms).

Chris C

(Note followups)

[Kenny McCormack]

In article <sl******************@ccserver.keris.net>,
Chris Croughton <ch***@keristor.net> wrote:

On Tue, 04 Jan 2005 03:18:18 GMT, Rich Teer
<ri*******@rite-group.com> wrote:

On Mon, 3 Jan 2005 jr********@hotmail.com wrote:

If the C programs have UNIX system calls such as fork(), alarm(),
etc.., we should call it UNIX programs, not traditional C programs?

WHo calls them C programs? Personally, I'd call the UNIX programs.

If they are written in C they are C programs, whatever libraries they
happen to use. Calling them "UNIX programs" helps no one, since a "UNIX
program" could be written in any language from raw binary to COBOL.

(Reading and posting from comp.unix.shell - keep that in mind)

This, incidentally, is *not* the view held in the (curiously named)
newsgroup "comp.lang.c".

They maintain that system-specific stuff, be it:

socket(foo,bar,blaz);

or

lpStr LpHand EXPORT WinPlaceWin(a,b,c);

is, plain and simply, not C.

Of course, what it is, they won't say...

[Dan Espen]

ga*****@yin.interaccess.com (Kenny McCormack) writes:

In article <sl******************@ccserver.keris.net>,
Chris Croughton <ch***@keristor.net> wrote:

On Tue, 04 Jan 2005 03:18:18 GMT, Rich Teer
<ri*******@rite-group.com> wrote:

On Mon, 3 Jan 2005 jr********@hotmail.com wrote:

If the C programs have UNIX system calls such as fork(), alarm(),
etc.., we should call it UNIX programs, not traditional C programs?

WHo calls them C programs? Personally, I'd call the UNIX programs.

If they are written in C they are C programs, whatever libraries they
happen to use. Calling them "UNIX programs" helps no one, since a "UNIX
program" could be written in any language from raw binary to COBOL.

(Reading and posting from comp.unix.shell - keep that in mind)

This, incidentally, is *not* the view held in the (curiously named)
newsgroup "comp.lang.c".

They maintain that system-specific stuff, be it:

socket(foo,bar,blaz);

or

lpStr LpHand EXPORT WinPlaceWin(a,b,c);

is, plain and simply, not C.

Of course, what it is, they won't say...

The first appears to be a BSD/SysV system call.
The second is an abomination.

[J. F. Cornwall]

Kenny McCormack wrote:

In article <sl******************@ccserver.keris.net>,
Chris Croughton <ch***@keristor.net> wrote:

On Tue, 04 Jan 2005 03:18:18 GMT, Rich Teer
<ri*******@rite-group.com> wrote:

On Mon, 3 Jan 2005 jr********@hotmail.com wrote:
If the C programs have UNIX system calls such as fork(), alarm(),
etc.., we should call it UNIX programs, not traditional C programs?

WHo calls them C programs? Personally, I'd call the UNIX programs.

If they are written in C they are C programs, whatever libraries they
happen to use. Calling them "UNIX programs" helps no one, since a "UNIX
program" could be written in any language from raw binary to COBOL.

(Reading and posting from comp.unix.shell - keep that in mind)

This, incidentally, is *not* the view held in the (curiously named)
newsgroup "comp.lang.c".

They maintain that system-specific stuff, be it:

socket(foo,bar,blaz);

or

lpStr LpHand EXPORT WinPlaceWin(a,b,c);

is, plain and simply, not C.

Of course, what it is, they won't say...

Sure they will. They'll say it is off-topic for a group which is
dedicated only to discussing the C language, and they'll flame ya for
daring to discuss an obviously OT issue...

JFC (BTDT)

[Kenny McCormack]

In article <9kxCd.37080$F25.23808@okepread07>,
J. F. Cornwall <JC*******@cox.net> wrote:

Kenny McCormack wrote:

In article <sl******************@ccserver.keris.net>,
Chris Croughton <ch***@keristor.net> wrote:

On Tue, 04 Jan 2005 03:18:18 GMT, Rich Teer
<ri*******@rite-group.com> wrote:
On Mon, 3 Jan 2005 jr********@hotmail.com wrote:
>If the C programs have UNIX system calls such as fork(), alarm(),
>etc.., we should call it UNIX programs, not traditional C programs?

WHo calls them C programs? Personally, I'd call the UNIX programs.

If they are written in C they are C programs, whatever libraries they
happen to use. Calling them "UNIX programs" helps no one, since a "UNIX
program" could be written in any language from raw binary to COBOL.

(Reading and posting from comp.unix.shell - keep that in mind)

This, incidentally, is *not* the view held in the (curiously named)
newsgroup "comp.lang.c".

They maintain that system-specific stuff, be it:

socket(foo,bar,blaz);

or

lpStr LpHand EXPORT WinPlaceWin(a,b,c);

is, plain and simply, not C.

Of course, what it is, they won't say...

Sure they will. They'll say it is off-topic for a group which is
dedicated only to discussing the C language, and they'll flame ya for
daring to discuss an obviously OT issue...

JFC (BTDT)

Best case, yes.

But the truly catholic view is that it is not C. And, in some obscure
sense, this is right. I.e., a function call is not really part of the
C language - it is an invocation of some externally (*) authored
functionality.

(*) Interpret this term loosely. It matters not to this discussion whether
external means any or all of:
1) By someone else
2) By a system implementor (i.e., system libraries)
3) By you, perhaps even in this same source file.

Or whether the target of that function call is written in C or any other
language.

[dandelion]

"Kenny McCormack" <ga*****@yin.interaccess.com> wrote in message
news:cr**********@yin.interaccess.com...

<snip>

They maintain that system-specific stuff, be it:

socket(foo,bar,blaz);

or

lpStr LpHand EXPORT WinPlaceWin(a,b,c);

is, plain and simply, not C.
It (probably) is. But then again, so is an implementation of TicTacToe. So
you suggest any question on TicTacToe should be topical aswell?
Of course, what it is, they won't say...

The *language* C is on topic, not the possible implementations of all kinds
of things in that language. If that restriction would not be there, almost
*anything* would be on topic and the quality of the ng would suffer.

An ng on the english language would not consider a review of the match
Wolverhampton Wanderers - Tottenham Hotspur on topic, would they?

Check out:
http://benpfaff.org/writings/clc/off-topic.html
http://www.ungerhu.com/jxh/clc.welcome.txt
http://www.eskimo.com/~scs/C-faq/top.html

[Joona I Palaste]

Dan Espen <da****@spam.mk.telcordia.com> scribbled the following
on comp.lang.c:

ga*****@yin.interaccess.com (Kenny McCormack) writes:

This, incidentally, is *not* the view held in the (curiously named)
newsgroup "comp.lang.c".
"Curiously named"? It's named comp.lang.c because it discusses C, not
operating systems. If you want comp.unix.programmer or the
comp.os.ms-windows.programmer hierarchy, you know where to find them.
They maintain that system-specific stuff, be it:

socket(foo,bar,blaz);

or

lpStr LpHand EXPORT WinPlaceWin(a,b,c);

is, plain and simply, not C.

Of course, what it is, they won't say...

The first appears to be a BSD/SysV system call.
The second is an abomination.

That makes no difference as far as C is concerned. Both are equally
off-topic

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"We're women. We've got double standards to live up to."
- Ally McBeal

[john_bode]

Kenny McCormack wrote:

In article <sl******************@ccserver.keris.net>,
Chris Croughton <ch***@keristor.net> wrote:

On Tue, 04 Jan 2005 03:18:18 GMT, Rich Teer
<ri*******@rite-group.com> wrote:

On Mon, 3 Jan 2005 jr********@hotmail.com wrote:

If the C programs have UNIX system calls such as fork(), alarm(),
etc.., we should call it UNIX programs, not traditional C programs?
WHo calls them C programs? Personally, I'd call the UNIX

programs.
If they are written in C they are C programs, whatever libraries theyhappen to use. Calling them "UNIX programs" helps no one, since a "UNIXprogram" could be written in any language from raw binary to COBOL.
(Reading and posting from comp.unix.shell - keep that in mind)

This, incidentally, is *not* the view held in the (curiously named)
newsgroup "comp.lang.c".

Curiously?
They maintain that system-specific stuff, be it:

socket(foo,bar,blaz);

or

lpStr LpHand EXPORT WinPlaceWin(a,b,c);

is, plain and simply, not C.

It is not part of the standard C prgramming language, which is what
comp.lang.c discusses, hence the name "comp.lang.c". You will not find
the keywords lpStr, LpHand, or EXPORT described by the C Language
Standard, nor will you find either WinPlaceWin() or socket() in the
standard C library.

Specific implementations of the language are outside the scope of
comp.lang.c. Wanna know how declarators work, or why i=i++ isn't
well-defined, or why gets() is evil and should never be used, then
comp.lang.c is the place to go. Wanna know how to open a socket, or
send a file to a printer, or play a .wmv file, then you need to go
someplace else, because those issues have nothing to do with the C
language itself. Of course, what it is, they won't say...

ISO/IEC 9899:1999.

[Keith Thompson]

ga*****@yin.interaccess.com (Kenny McCormack) writes:
[...]

This, incidentally, is *not* the view held in the (curiously named)
newsgroup "comp.lang.c".

They maintain that system-specific stuff, be it:

socket(foo,bar,blaz);

or

lpStr LpHand EXPORT WinPlaceWin(a,b,c);

is, plain and simply, not C.

No, it's C (presumably), but it's still off-topic. Not everything
that happens to be a C program is necessarily topical in comp.lang.c.

The conventions regarding what's topical in comp.lang.c are fairly
straightforward, but they're too complex to be incorporated into the
newsgroup's name.

See <http://www.stanford.edu/~blp/writings/clc/off-topic.html>.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Micah Cowan]

Kenny McCormack wrote:

In article <sl******************@ccserver.keris.net>,
Chris Croughton <ch***@keristor.net> wrote:

On Tue, 04 Jan 2005 03:18:18 GMT, Rich Teer
<ri*******@rite-group.com> wrote:

On Mon, 3 Jan 2005 jr********@hotmail.com wrote:
If the C programs have UNIX system calls such as fork(), alarm(),
etc.., we should call it UNIX programs, not traditional C programs?

WHo calls them C programs? Personally, I'd call the UNIX programs.
If they are written in C they are C programs, whatever libraries they
happen to use. Calling them "UNIX programs" helps no one, since a "UNIX
program" could be written in any language from raw binary to COBOL.

(Reading and posting from comp.unix.shell - keep that in mind)

This, incidentally, is *not* the view held in the (curiously named)
newsgroup "comp.lang.c".

I don't believe the above statement is true. They are C programs,
using libraries and headers. If the definitions are linked (by
implementation-defined means), then well-defined behavior will
occur in these functions' invocations.

It is simply that these functions, libraries and headers are not
part of C themselves, and therefore strictly off-topic. If you
were to provide C definitions for these functions, which
themselves used only facilities which were defined, either
elsewhere in the post or by the C standard itself, no one will
complain. The chief problem is that people write such posts
without including such definitions, expecting people to assume
the definitions, which makes them off-topic.

They maintain that system-specific stuff, be it:

socket(foo,bar,blaz);

or

lpStr LpHand EXPORT WinPlaceWin(a,b,c);

is, plain and simply, not C.

It clearly is C. The first is either a macro call or (more
probably) a function call. The latter is hard to be sure of
without more definitions in place. Neither have defined results
without more definitions in scope. They are off-topic until such
definitions are given.

[Dave Thompson]

On 3 Jan 2005 19:10:33 -0800, jr********@hotmail.com wrote:

If the C programs have UNIX system calls such as fork(), alarm(),
etc.., we should call it UNIX programs, not traditional C programs?
Call them Unix C programs, not standard or portable C. "Traditional" C
usually means K&R1 syntax as opposed to standard, but could also mean
mean Unix, since that's where C started.
We couldn't compile the programs with system calls using VC++ compiler.
I need to compile it under UNIX platform. correct? any other
alternatives??

If you want to run under Windows programs that were written for Unix,
Cygwin www.cygwin.com is designed to do exactly that. It uses (a port
of) the GCC compiler(s), not the VC++ compiler. And personally I found
the installer much too klunky, but that's a separate question.

If you want to change your programs to run natively under Windows
(perhaps using VC++, perhaps not) instead of or as well as under Unix
(or perhaps certain Unices, since there are some differences though
smaller ones), you may be facing a pretty big job, depending. I have
stumbled across sections on porting from Unix to Windows while
searching for other things, but not been able to find again, in the
huge blob that is MSDN. Good luck.

- David.Thompson1 at worldnet.att.net