473,320 Members | 2,073 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

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

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!!

Jul 22 '05 #1
12 3380
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: +1 (250) 979-1638 * '''||''' .
URL: http://www.rite-online.net ******************
Jul 22 '05 #2
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)
Jul 22 '05 #3
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...

Jul 22 '05 #4
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.
Jul 22 '05 #5
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)

Jul 22 '05 #6
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.

Jul 22 '05 #7

"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
Jul 22 '05 #8
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
Jul 22 '05 #9

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.

Jul 22 '05 #10
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.
Jul 22 '05 #11
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.
Jul 22 '05 #12
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
Jul 22 '05 #13

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

10
by: Jean-David Beyer | last post by:
I have some programs running on Red Hat Linux 7.3 working with IBM DB2 V6.1 (with all the FixPacks) on my old machine. I have just installed IBM DB2 V8.1 on this (new) machine running Red Hat...
3
by: Abby | last post by:
I'm now using Cygwin as my compiler for C code. I use Dev-c++ as my editor. The reason why I chose Cygwin compiler instead of the compiler that came with Dev-C++ is that I believe it uses the same...
17
by: hugo27 | last post by:
hugo27 July 13, 2004 > >The teachy books and documentation I've read do not >mention the Escape key, but everytime I hit it during >runtime my programs go bananas. > >This relates to a larger...
5
by: markus | last post by:
Hi, I have a question that deals with the standard c library VS (Unix) system calls. The question is: which header files (and functions) are part of the C library and which header files (and...
18
by: jrefactors | last post by:
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++...
36
by: lovecreatesbeauty | last post by:
In the C programming language, I/O operation functions are declared in stdio.h, for example, fopen(), fclose(), fwrite(), fread(), fseek() ... But another set of I/O functions are also defined in...
2
by: parag_paul | last post by:
I have been seeing a consistent slowness in g++ compilation for a small file like the following , The uptime is near ( load Is near to 0 ) . I have put the time output for the same, The file...
0
by: dot | last post by:
I spent a few headache filled days trying to use GMP on windows (XP pro) I finally got it to work and since I found little help on the Web I thought someone might find what i did useful. ...
35
by: jleslie48 | last post by:
I've written a cgi program in C using the borland 5.5 free compiler, and it runs just fine on an Apache server. My only issue is if I issue some system calls the cgi suspends until the call...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.