Very Computer

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

Quote:> 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.

Quote:> 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...

Quote:> 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                     ******************

On Tue, 04 Jan 2005 03:18:18 GMT, Rich Teer

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.

Quote:>> 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).

Quote:>> 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...

Quote:> Trying to run (say) a program
> that was compiled on Windoze on Solaris

You mean "targetted for Windoze".

Quote:> 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)

(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.

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.

<snip>

Quote:> 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?

Quote:> 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

on 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.

Quote:>> 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

--

\-------------------------------------------------------- rules! --------/
"We're women. We've got double standards to live up to."
   - Ally McBeal

Curiously?

Quote:> 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.

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

ISO/IEC 9899:1999.

[...]

Quote:> 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>.

--

San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

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.

Quote:

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

Quote:> 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.

Quote:> 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