Linux-Development-Sys Digest #851, Volume #7 Sat, 13 May 00 09:13:12 EDT
Contents:
Re: ANSI C & void main() (Joe Pfeiffer)
Re: ANSI C & void main() ("Mark Graybill")
Re: ANSI C & void main() (Kaz Kylheku)
Linux (thread vs fork) ([EMAIL PROTECTED])
Re: How much disk space ? (Christian Winter)
Re: binary compression -- good or bad? ([EMAIL PROTECTED])
Re: Linux (thread vs fork) (bil@p)
Re: Linux (thread vs fork) (Vetle Roeim)
Re: Process timeouts (Anand Krishnamoorthy)
Re: ANSI C & void main() (Johan Kullstam)
Re: Interrupt handler problem (Arnaud Westenberg)
Re: Please help me find a Modem Driver (Christian Winter)
Re: ANSI C & void main() ("Frank")
----------------------------------------------------------------------------
From: Joe Pfeiffer <[EMAIL PROTECTED]>
Subject: Re: ANSI C & void main()
Date: 12 May 2000 23:22:36 -0600
>
> >All the compilers I've used allows for its use, and they don't produce
> >erratic behavior, or undefined behavior as you call it. This is probably
> >due to legacy compatibility (a good attention to detail to have.)
Why do so many of the contributors to this thread fail to understand
that there is no conflict between ``the behavior is not defined in the
standard, so you shouldn't do it'' and ``it works just fine with every
compiler I've ever used. So far.'' ?
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
VL 2000 Homepage: http://www.cs.orst.edu/~burnett/vl2000/
------------------------------
Reply-To: "Mark Graybill" <[EMAIL PROTECTED]>
From: "Mark Graybill" <[EMAIL PROTECTED]>
Subject: Re: ANSI C & void main()
Date: Sat, 13 May 2000 06:09:01 GMT
It seems I didn't read the standard close enough. Today I decided to read
it carefully and completely, I found that it doesn't prohibit non-int types
of main(), but rather only states that all implementations must support the
two prototypes of int main() as a minimum.
The current standards leave it up to the implementation to define the type
of main() its creators wishes to support.
In the current C++ ANSI standard (ICO-IEC 14882) section 3.6.1, paragraph 2
reads:
"An implementation shall not predefine the main function. This function
shall not be overloaded. It shall
have a return type of type int, but otherwise its type is
implementation�defined. All implementations
shall allow both of the following definitions of main:"
"int main() { /* ... */ }"
"and"
"int main(int argc, char* argv[]) { /* ... */ }"
and paragraph 5 reads:
"A return statement in main has the effect of leaving the main function
(destroying any objects with auto�matic
storage duration) and calling exit with the return value as the argument. If
control reaches the end
of main without encountering a return statement, the effect is that of
executing return 0;"
Each implementation is supposed to support int type in the 2 specified
forms; however, it ALLOWS for whatever return type an implementation chooses
to support. So, void main() IS allowable according to the current ANSI C++
standard. You will need to consult your compiler documentation to determine
what it supports.
The behavior is NOT undefined because the type of main() only is important
when it returns to it's calling code. Since paragraph 5 covers the case
where main() does not return anything (regardless of type), which is to
return 0 in those cases.
Therefore, the only undefined behavior would be the behavior of the compiler
passes as validates your code against what it supports. If it does not
support void main(), then you won't get passed the compiling stage and won't
get the chance to execute it. If it compiles, in accordance with this
standard, it must return an exit code of 0, unless main() specifies
something else.
If you think I screwed around with the words, go to www.ansi.org and select
the banner advertising the C++ standard for $18 (PDF file.)
-Mark
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: ANSI C & void main()
Reply-To: [EMAIL PROTECTED]
Date: Sat, 13 May 2000 07:43:58 GMT
On Sat, 13 May 2000 06:09:01 GMT, Mark Graybill <[EMAIL PROTECTED]> wrote:
>It seems I didn't read the standard close enough. Today I decided to read
>it carefully and completely, I found that it doesn't prohibit non-int types
>of main(), but rather only states that all implementations must support the
>two prototypes of int main() as a minimum.
It does not say ``as a minimum''. I don't infer any implicit or explicit
encouragement for the support of other forms from the text.
>implementation�defined. All implementations
>shall allow both of the following definitions of main:"
which means they are *not required* to support any others, nor to define the
behavior of any others in any way.
>Each implementation is supposed to support int type in the 2 specified
>forms; however, it ALLOWS for whatever return type an implementation chooses
>to support. So, void main() IS allowable according to the current ANSI C++
>standard.
Yes it is allowable. It is allowable for an *implementation* to support it.
However, we are talking about using the language, not implementing it.
The behavior of programs which use an alternate form is undefined in the
standard. They are in the hands of the implementor.
There are plenty of other undefined behaviors in the language that are
used as a basis for extensions.
For example, some compilers support the character escape sequence \e in string
and character literals. The behavior of this is undefined, so these compilers
are allowed to do anything at all with it. Their implementors chose to provide
an extension.
Undefined behaviors are often an excellent place to stick in extensions because
these extensions can be available even when the implementation is operated in a
conforming mode.
Another perfect example of this are identifiers that start with two
underscores. Any program which uses such identifiers is undefined, so compilers,
like GCC, use them to introduce extensions: think of things like
__inline__, __attribute__, __asm__ etc.
>You will need to consult your compiler documentation to determine
>what it supports.
Yes; a compiler should be accompanied by documentation which describes its
extensions. Note that something that works, but is not documented, is not
necessarily an extension.
>The behavior is NOT undefined because the type of main() only is important
>when it returns to it's calling code.
You don't seem to understand what calling conventions are all about. When the
type of a call does not match the function definition, there is no telling
whether the call will fail, or whether the return will fail or what happens at
all.
The C language is not a syntactic sugar for the handful of assembly
languages you might know, but an abstract language.
>Therefore, the only undefined behavior would be the behavior of the compiler
>passes as validates your code against what it supports.
>
> If it does not
>support void main(), then you won't get passed the compiling stage and won't
>get the chance to execute it.
You are reading way too much into it. There is no requirement stated that the
translation must stop, or that a diagnostic must be issued, if the particular
form of the startup function which appears in the program is not supported by
the implementation.
Try feeding your compiler this:
struct foo {
char x[500];
} main(int argc, char **argv)
{
struct foo retval = { 0 };
return retval;
}
Chances are that it won't stop compiling and you will get an executable. Does
that mean that your compiler supports the returning of a big structure from
main? Can you cite this support from your compiler's documentation?
I ran the above program on a GNU/Linux system and it produced an a.out.
It died with a core dump. Hmm, it doesn't look like this is a supported
form for main, so why did it pass compilation? Is GCC not conforming?
------------------------------
From: [EMAIL PROTECTED]
Subject: Linux (thread vs fork)
Date: Sat, 13 May 2000 08:14:54 GMT
As long as I know linux maps threads as processes.
My question is that if linux maps threads as processes
is there an advantage of using threads.
It seems to be threading in linux is not a good idea,
or is it?
For example there is a limit for the number of threads
per process. On the other hand the limit for the number
of processes is larger. I know that Apache uses preforking
, but there are some other web servers (Trantula) which
uses other techniques. Consequently I am confused with this.
My goal is to write a scalable chat server. The throughput
is the most important issue in the project. In this case
what is the best way?
Another question is that, is there an efficient way for select (or poll)
in unix. I want to do the same thing that the select does, but I do not
want the penalty (two system calls) of select.
Thanks a lot for the answers?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Christian Winter <[EMAIL PROTECTED]>
Subject: Re: How much disk space ?
Date: Fri, 12 May 2000 16:49:07 +0200
Rini van Zetten <[EMAIL PROTECTED]> schrob:
> Does anybody know how much disk space a Linux based system minimal requires.
> It should have a X-windows system.
> (I would like to have it on a flash disk)
Just have a look at smalllinux+tinyX, which should long with about
2megs. Available via www.freshmeat.net
HTH
Christian
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: binary compression -- good or bad?
Date: Sat, 13 May 2000 08:32:26 GMT
My guess is that the code compression feature would be useful for
those cases where you have running just one instance of a very very
large and obese program, such as Netscape Navigator. It could also
be a break-even on programs that "take heavy advantage" of the COW
feature.
Personlly, I wouldn't bother with binary executeable compression.
And don't even _think_ of suggesting it for libc.
On Thu, 11 May 2000 09:02:57 +0200 Josef Moellers <[EMAIL PROTECTED]>
wrote:
| Yuzheng Ding wrote:
|>
|> I heard the greatness of binary compressors like upx that takes away the fat
|> from an executable while having "no memory penalty". On the other hand I heard
|> that at elast for Windows9x, such compression nullifies code sharing, thus
|> suffering heavy memory penalty if you look at the entire picture.
|>
|> What's the case with Linux? Would code/data sharing be impacted in any ways
|> of means? Do unix programs only share the code other than those in
|> dynamically linked shared libraries? It seems to me that the sharing of
|> dynamically linked shared libraries should not be impacted as they are loaded
|> after the program begins (thus after decompression). Did I miss anything?
|
| I don't know upx, but from what you describe, it works like the kernel
| decompression by putting a small decompression code followed by the
| compressed binary into a single file and execute the decompression code
| when starting the program which, in turn, produces the actual binary.
|
| Linux program code is faulted in, i.e. in theory execution is started
| with no code in memory at all. When the CPU tries to execute the first
| instruction, the page (usually some 4K) containing the first byte of
| that instruction is loaded into memory. Therefore, only those pages are
| loaded into memory that are really referenced, i.e. if you only use some
| 5% of your code, only this 5% is actually loaded into memory.
| Using a decompressor will load the entire program into memory, not
| discriminating between those code parts that will be used and those code
| parts that will never be used.
|
| Also, since the code segment is read-only, it can be shared between
| processes executing the same binary. The decompressed code will have to
| be stored into some kind of writable code segment which then cannot be
| shared. So you'll end up with several copies of identical code segments
| which were loaded entirely (and had to be swapped out in case of memory
| shortage) and could not be shared.
|
| Some architectures might even prohibit executing code from a data
| segment.
|
| My guess is that the time saved by loading a compressed code is more
| than eaten up by de-compressing the code (enetring the kernel again and
| again to allocate additional memory) and coping with the increase in
| memory utilization.
--
| Phil Howard - KA9WGN | My current boycotts: Amazon.Com, DVDs, Mattel, Sony
| [EMAIL PROTECTED] +----------------------------------------------------
| Dallas - Texas - USA | My current websites: linuxhomepage.com, ham.org
------------------------------
From: bil@p
Subject: Re: Linux (thread vs fork)
Date: 13 May 2000 01:53:45 -0700
In article <8fj2to$45t$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>As long as I know linux maps threads as processes.
what does that mean?
>For example there is a limit for the number of threads
>per process.
how does the above make sense given what you said before?
>I know that Apache uses preforking
what is 'preforking' ?
>Another question is that, is there an efficient way for select (or poll)
>in unix.
yes. use select() or poll() .
>I want to do the same thing that the select does, but I do not
>want the penalty (two system calls) of select.
just get the thing to work first, then worry about performance later.
which linux thread model are you talking about?
------------------------------
From: Vetle Roeim <[EMAIL PROTECTED]>
Subject: Re: Linux (thread vs fork)
Date: 13 May 2000 13:03:58 +0200
* bil@p
> >I know that Apache uses preforking
>
> what is 'preforking' ?
creating new processes before requests arrive. it eliminates the
overhead of creating a new process when answering a request.
vr
------------------------------
From: Anand Krishnamoorthy <[EMAIL PROTECTED]>
Subject: Re: Process timeouts
Date: Sat, 13 May 2000 16:57:39 -0400
==============555F8048BBB441C7740567DB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> I'm using Rubini's book to learn Linux device drivers and have come across a
> problem implementing a process timeout as he describes on pp. 135-136. His
> method uses the field current-> timeout; the kernel I am working with is
> 2.2.12, and task_struct has changed and no longer has a timeout field.
>
> Could somebody please let me know how timing out a process works in the
> 2.2.12 kernel.
I do not know about the timeout that was existant before the 2.2.12 kernels but
I believe you might be interested in the routine schedule_timeout() in the file
sched.c and might want to check that out.. Hope this helps..
Anand .K
[EMAIL PROTECTED]
==============555F8048BBB441C7740567DB
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
<I></I>
<BR><I></I>
<BLOCKQUOTE TYPE=CITE><I>I'm using Rubini's book to learn Linux device
drivers and have come across a</I>
<BR><I>problem implementing a process timeout as he describes on pp. 135-136.
His</I>
<BR><I>method uses the field current-> timeout; the kernel I am working
with is</I>
<BR><I>2.2.12, and task_struct has changed and no longer has a timeout
field.</I><I></I>
<P><I>Could somebody please let me know how timing out a process works
in the</I>
<BR><I>2.2.12 kernel.</I></BLOCKQUOTE>
I do not know about the timeout that was existant before the 2.2.12 kernels
but I believe you might be interested in the routine schedule_timeout()
in the file sched.c and might want to check that out.. Hope this helps..
<P>Anand .K
<P>[EMAIL PROTECTED]</HTML>
==============555F8048BBB441C7740567DB==
------------------------------
Subject: Re: ANSI C & void main()
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: Sat, 13 May 2000 11:39:50 GMT
Joe Pfeiffer <[EMAIL PROTECTED]> writes:
> >
> > >All the compilers I've used allows for its use, and they don't produce
> > >erratic behavior, or undefined behavior as you call it. This is probably
> > >due to legacy compatibility (a good attention to detail to have.)
>
> Why do so many of the contributors to this thread fail to understand
> that there is no conflict between ``the behavior is not defined in the
> standard, so you shouldn't do it'' and ``it works just fine with every
> compiler I've ever used. So far.''?
it's not really a compiler issue, but a linker/operating system
issue. unix requires an int return for main. the linker assumes that
main returns an integer and passes it on to the caller. thus whatever
mechanism is used for returning an int is invoked and you get what you
get.
we understand the conflict. it is the difference between "you deserve
to lose" and "yet you seem to be winning".
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
Date: Sat, 13 May 2000 12:14:49 +0200
From: Arnaud Westenberg <[EMAIL PROTECTED]>
Subject: Re: Interrupt handler problem
Mario Klebsch wrote:
> WHen having multiplexed register access, you need to disable
> interrupts (didn't someone wrote, that cli() shall not be used
> anymore?) prior to the first access, and you have to reenable the
> original state after the second access.
True, you have to use spinlocks now.
Still nobody with a great idea to spead up the code?
Greetings Arnaud
------------------------------
From: Christian Winter <[EMAIL PROTECTED]>
Subject: Re: Please help me find a Modem Driver
Date: Sat, 13 May 2000 11:48:57 +0200
Marina <[EMAIL PROTECTED]> schrob:
> HELP!!!!!
That's what many people posting in usenet groups need. So no need
to shout ;-)
> I have a Aztech Labs modem. It works fine in Windows, but I need
> a driver to use in Linux. I am currently running both Win 98 and Mandrake
> Linux 7.0...
Quite inspecific. Is it an external or an internal one, and if one of
the latter, is it a real "SoftModem" or does it supply it's own com-port?
If it is a real softmodem (mostly if there also is a soundcard on the same
board) it will be difficult or impossible to find a driver, since most
manufacturers don't give out details about those cards (for a few there
are already drivers available, maybe you'll find one using SuSEs Hardware-DB
on www.suse.com).
If it is no "softmodem", then there shouldn't be problems - just adapt settings
to the matching com-port, maybe fill in the right initialisation strings from
the modem doku (in nearly all cases standard hayes commands should work)
and go online :)
> Does any one know where I might be able to find one, or how I can make my
> modem work??
If it is internal, what chip is it based on? (Manufacturer and ID)
Regards
Christian
------------------------------
From: "Frank" <[EMAIL PROTECTED]>
Subject: Re: ANSI C & void main()
Date: Sat, 13 May 2000 13:02:00 GMT
Kaz Kylheku <[EMAIL PROTECTED]>...
^
^ Try feeding your compiler this:
^
^ struct foo {
^ char x[500];
^ } main(int argc, char **argv)
^ {
^ struct foo retval = { 0 };
^ return retval;
^ }
^
^ Chances are that it won't stop compiling and you will get an executable.
Does
^ that mean that your compiler supports the returning of a big structure from
^ main? Can you cite this support from your compiler's documentation?
^
^ I ran the above program on a GNU/Linux system and it produced an a.out.
^ It died with a core dump. Hmm, it doesn't look like this is a supported
^ form for main, so why did it pass compilation? Is GCC not conforming?
So Linux doesn't support the struct return type. If I wrote an OS, Bigix, that
fails to understand int returns and only supports struct returns then are you
suggesting that I could never use C?
Frank Westlake
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
