Fedora Linux Support Community & Resources Center
  #1  
Old 13th July 2012, 02:29 PM
JoeNapoleon Offline
Registered User
 
Join Date: Oct 2011
Location: Wuhan , China
Posts: 22
windows_7chrome
where to learn c code?

Did you know some place in internet where there is good C programming code? because i want to research those code to learn C programming language, and practice.
and how to join in the C newsgroup?
thank you.

question2 :
"Many system calls relate to the file system.To create a new file, the CREAT call is used. It's parameters provide the name of the file and the protection mode. Thus

fd = creat("abc", 0751);

create a file called abc with mode 0751 octal .
CREAT not only create a new file but also opens it for writing, regardless of the file's mode. The file descriptor returned, fd, can be used to write the file. ......"
"To read or write an existing file, the file must first be opened using OPEN.
This call specifies the file name to be opened, either as an absolute path name or
relative to the working directory, and a code of 0-RDONLY. 0-WRONLY, or
0-RDWR, meaning open for reading, writing, or both. The file descriptor
returned can then be used for reading or writing. Afterward, the file can he closed
by CLOSE, which makes the file descriptor available for reuse on a subsequent
CREAT or OPEN."

" When manipulating file descriptors, the DUP call is occasionally helpful. Consider,
for example, a program that needs to close standard output (file descriptor
l), substitute another file as standard output, call a function that writes some output
onto standard output, and then restore the original situation. Just closing file
descriptor 1 and then opening a new file will make the new file standard output
(assuming standard input, file descriptor 0, is in use), but it will be impossible to
restore the original situation later.
The solution is first to execute the statement

fd = dup(1);

which uses the DUP system call to allocate a new file descriptor, fd, and arrange
for it to correspond to the same file as standard output. Then standard output can
be closed and a new file opened and used. When it is time to restore the original
situation, file descriptor 1 can be closed, and then

n = dup(fd)

executed to assign the lowest file descriptor, namely, 1, to the same file as jd.
Finally, fd can be closed and we are back where we started.
The DUP call has a variant that allows an arbitrary unassigned file descriptor
to be made to refer to a given open file. It is called by

dup2(fd, fd2)

where fd refers to an open file and fd2 is the unassigned file descriptor that is to be
made to refer to the same file as fd. Thus if fd refers to standar$ input (file
descriptor 0) and fd2 is 4, after the call, file descriptors 0 and 4 will both refer to
standard input. "

Interprocess communication in MINIX uses pipes, as described earlier. When
a user types

cat file1 file2 | sort

the shell creates a pipe and arranges for standard output of the first process to
write to -the pipe, so standard input of the second process can read from it. The
PWE system call creates a pipe and returns two file descriptors, one for writing and
one for reading. The call is

pipe(&fd[0]);

where fd is an array of two integers and fd[O) is the file descriptor for reading and
fd [I] is the one for writing. Typically, a FORK comes next, and the parent closes
the file descriptor for reading and the child closes the file descriptor for writing
(or vice versa), so when they are done, one process can read the pipe and the other
can write on it.
Figure 1- 13 depicts a skeleton procedure that creates two processes, with the
output of the first one piped into the second one.
First a pipe is created, and then the procedure
forks, with the parent eventually becoming the first process in the pipeline
and the child process becoming the second one. Since the files to be executed,
process] and process2, do not know that they are part of a pipeline, it is essential
that the file descriptors be manipulated so that the first process' standard output be.
the pipe and the second one's standard input be the pipe. The parent first closes
off the file descriptor for reading from the pipe. Then it closes standard output
and does a DUP call that allows file descriptor 1 to write on the pipe. It is important
to realize that DUP always returns the lowest available file descriptor, in this
case, 1 . Then the program closes the other pipe file descriptor.



#define STD_INPUT 0 /* file descriptor for standard input */
#define STD_OUTPUT 1 /* file descriptor for standard output */

pipeline(process1, process2)
char *processl, *process2; /* pointers to program names */
{
int fd[2];
pipe(&fd[0]); /* create a pipe */
if (fork() != 0) {
/* The parent process executes these statements. */
close(fd[0]); /* process 1 does not need to read from pipe */
close(STD_OUTPUT); /* prepare for new standard output */
dup(fd[1]); / * set standard output to fd[l] */
close(fd[1]); /* this file descriptor n d needed any more */
execl(process1, process1 ,0);
) else {
/* The child process executes these statements. */
close(fd[1]); /* process 2 does not need to write to pipe */
close(STD_INPUT); /* prepare for new standard input */
dup(fd[0]); /* set standard input to fd[0] */
close(fd[0]); /* this file descriptor not needed any more */
execl(process2, process2,0);
}
}
Figure 1-13. A skeleton for setting up a two-process pipeline.

/* what is the file descriptor? */
/* what is system calls ? */
/* what is the meaning of dup(1) , dup(fd), dup2? */
thank you.

Last edited by JoeNapoleon; 19th July 2012 at 03:28 PM. Reason: more
Reply With Quote
  #2  
Old 13th July 2012, 04:03 PM
jpollard Offline
Registered User
 
Join Date: Aug 2009
Location: Waldorf, Maryland
Posts: 6,105
linuxfirefox
Re: where to learn c code?

1. The pipe system call returns two descriptors, one in fd[0] (open for read), and the other in fd[1] (open for write). One way you can think of it is that both descriptors are pointing to a single buffer. The read descriptor takes bytes from the buffer, the write descriptor puts bytes into the buffer. If you try to put more data in the buffer than it will hold, the write will wait for space. If you attempt to read more data than is in the buffer, the read will wait until data is there.

2. Not sure of your question - every function call in the example makes a system call.

3. dup(fd) causes the file descriptor fd to be copied to the lowest numbered closed file descriptor available. In the sequence
close(0); dup(fd[0]); first closes file descriptor 0 (stdin), the dup(fd[0]) then copies fd[0] into descriptor 0. If descriptor 0 is already closed (possible, but not likely in the example) then the close system call will return an error. This is a "don't care" situation as you don't want the descriptor open anyway.

dup(1) says copy the file descriptor 1. dup(fd) says copy the file descriptor specified by the value of fd.

dup2 specifies both the descriptor to be copied, and the descriptor to copy it to. The dup2 system call will close the specified target descriptor before the copy, so it isn't necessary to close it explicitly.

The fork system call is used to create a new process with the same memory mapping as the parent process. This means funny things can happen if the new process does things to memory (it can corrupt a stack by returning and calling different functions before the the parent process - so care is taken in the child process.

The fork system call returns the process id of the new process to the parent (the old process). The function returns 0 to the new process. This is why the "if (fork() != 0)" test is done. The true part of the if is processed by the new process. The else part is processed by the old process.

Note the care with the new process - after setting up the stdin/stdout file descriptors it then execs a program. This causes the memory mapping of the process to switch to that of the program specified.

ALSO NOTE: There is a bug here that is not handled - what happens if the exec (execl is a function that ends up using the exec system call) system call fails? (execl is a function that ends up using the exec system call, it just handles the parameters a bit differently). On an error, the execl returns... but the error isn't handled which allows funky things to happen...

As to "where to learn", you can check several of the universities - I believe MIT likely has some of the best tutorials and class videos. They are not the only ones available.

Last edited by jpollard; 13th July 2012 at 04:05 PM.
Reply With Quote
  #3  
Old 20th July 2012, 04:22 AM
JoeNapoleon Offline
Registered User
 
Join Date: Oct 2011
Location: Wuhan , China
Posts: 22
windows_xp_2003chrome
Re: where to learn c code?

Thank you for replying. Although MIT is the best of the USA in science and technology, but Johns Hopkins and U.C. Berkeley are also very good. especially i knew Johns Hopkins university in wiki, Veritas vos liberabit.

Last edited by JoeNapoleon; 20th July 2012 at 02:51 PM.
Reply With Quote
Reply

Tags
code, learn

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
How do you learn? Jake Wibble 26 16th March 2009 01:15 PM
Looking to learn, but need help Night Fire Programming & Packaging 6 29th May 2008 09:05 PM
I want to learn more n need some help virusvivivi Using Fedora 2 1st November 2007 11:38 PM
I want to Learn DdOs Fedora Focus 14 3rd December 2005 05:25 AM
OK...I know I have a lot to learn.... Sulblk27 Security and Privacy 5 5th July 2005 07:29 PM


Current GMT-time: 04:53 (Wednesday, 22-05-2013)

TopSubscribe to XML RSS for all Threads in all ForumsFedoraForumDotOrg Archive
logo

All trademarks, and forum posts in this site are property of their respective owner(s).
FedoraForum.org is privately owned and is not directly sponsored by the Fedora Project or Red Hat, Inc.

Privacy Policy | Term of Use | Posting Guidelines | Archive | Contact Us | Founding Members

Powered by vBulletin® Copyright ©2000 - 2012, vBulletin Solutions, Inc.

FedoraForum is Powered by RedHat