Linux-Development-Sys Digest #759, Volume #7     Tue, 11 Apr 00 23:14:40 EDT

Contents:
  Re: =?iso-8859-1?Q?R=E9cuperation?= d'1 PID en C and a question myself  
(nightstalker)
  2.3.99pre4 make problem (bill davidsen)
  Re: struct passwd * (Nix)
  Re: Packaging software... (Mark Wooding)
  Re: Idea !!! (nightstalker)
  Re: Absolute failure of Linux dead ahead? (Andy Newman)
  Re: How compatible is Linux with .. Linux ("Peter T. Breuer")
  Re: To core or not to core - You tell me (Mark McIntyre)
  Re: To core or not to core - You tell me (Mark McIntyre)
  Re: To core or not to core - You tell me (Mark McIntyre)
  Re: To core or not to core - You tell me (Erik Max Francis)
  Re: To core or not to core - You tell me (Erik Max Francis)
  Re: syscall during shrinking? (Juergen Heinzl)
  Re: Idea !!! (Kenneth Mankoff)
  Re: Kernel development (Philip)
  Re: struct passwd * (Juergen Heinzl)
  Re: readline() ("T.E.Dickey")
  Re: logging xterm seesions ("T.E.Dickey")
  fork and pipe ("Celestial Wizard")
  Re: Linux Daemon problem (Atcq4eva)
  Re: To core or not to core - You tell me (Floyd Davidson)
  Re: Q: How good is Linux when the computer is suddenly loses power ? ("Celestial 
Wizard")

----------------------------------------------------------------------------

From: nightstalker <[EMAIL PROTECTED]>
Crossposted-To: 
fr.comp.lang.c,fr.comp.developpement,alt.comp.lang.learn.c-c++,comp.os.linux.development.apps
Subject: Re: =?iso-8859-1?Q?R=E9cuperation?= d'1 PID en C and a question myself 
Date: Tue, 11 Apr 2000 21:45:30 GMT

Julien Curto wrote:

> Salut,
>
> 2 Questions :
>
> * Comment est-ce que peut-on récuperer un PID en C.
>
> * Comment peut-on savoir si un programme est déjà activer en C. (ex. :
> par recherche du PID)
>
> D'avance merci
>
> Merci de répondre à l'adresse indiquée.
>
> Mïll#99

i don't know french to well but i'll try to help you :)

1) getpid() gets the pid of your current running program. (type man
getpid for
more info)

2) some programs (like dhcpcd & gpm ) use a 'lock-file' in the /var/run
dir
they store their pid's there in a file named for example dhcpcd.pid
when you try to start dhcpcd it checks if the file exists, if so : it
gives you
a warning and refuses to start unless you specify a parameter explicitly
stating you want to run it.
ofcourse these programs need to delete this file after they are done
executing :)

hope this helps

ns.

ps: consider writing your question in english next time :) lot's of ppl
read
newsgroups and don't know french

ps2: to all of you out there : i noticed i could read /var/run/dhcpcd.pid
as a
normal user. i know that with a kernel patch you can disable certain
programs
from being listed by for example 'ps' .. couldn't this be a security hole
??
you can still know as a user that a certain program is running.  (the
/var/run
dir is normally only used by programs started by root anyway, so why not
make it readable/writable only by root ?)
if this is a silly question, nevermind :)
i'm running slackware btw


------------------------------

From: bill davidsen <[EMAIL PROTECTED]>
Subject: 2.3.99pre4 make problem
Date: 11 Apr 2000 21:50:36 GMT


  Just downloaded the pre4 source and started build from scratch:

deathstar:root> make menuconfig
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
make -C scripts/lxdialog all
make[1]: Entering directory `/usr/src/linux-2.4pre4/scripts/lxdialog'
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -DLOCALE
-I/usr/include/ncurses -DCURSES_LOC="<ncurses.h>" -D__KERNEL__
-I/usr/src/linux/include  -c lxdialog.c -o lxdialog.o
In file included from /usr/src/linux/include/linux/types.h:4,
                 from /usr/include/sys/types.h:4,
                 from dialog.h:22,
                 from lxdialog.c:22:
/usr/src/linux/include/linux/config.h:4: linux/autoconf.h: No such file
or directory
make[1]: *** [lxdialog.o] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4pre4/scripts/lxdialog'
make: *** [menuconfig] Error 2
deathstar:root>

  Some part of the Makefile should create the header, or it should not
be used. I think it's an empty file, I used touch to make an empty one
and the error went away. All other references to it are gone.

--
bill davidsen <[EMAIL PROTECTED]>  CTO, TMR Associates, Inc
  The Internet is not the fountain of youth, but some days it feels like
the fountain of immaturity.

------------------------------

From: Nix <$}xinix{$@esperi.demon.co.uk>
Subject: Re: struct passwd *
Date: 11 Apr 2000 22:36:02 +0100

[EMAIL PROTECTED] (bill davidsen) writes:

> In article <[EMAIL PROTECTED]>,
> Dan McGuirk  <[EMAIL PROTECTED]> wrote:
> | bill davidsen wrote:
> | >   Someone have the source for glibc handy? I don't, and I'm not going to
> | > go grab it.
> |
> | You don't need the source, just the documentation.  From the glibc
> | manual:
> 
>   I'm looking at a Redhat 5.2 man page right now, and it doesn't say
> anything like that, and even warns that you can get ENOMEM if there's no
> memory available to allocate.

Bear in mind that {passwd|name} database lookup routines can allocate
memory themselves, and this has to be reported somehow.

-- 
`ndbm on Linux is an emulation, not the original. It comes in several
 flavours; `slightly broken', `moderately broken', and `totally and
 utterly broken'.' --- Nick Kew

------------------------------

From: [EMAIL PROTECTED] (Mark Wooding)
Crossposted-To: comp.os.linux.misc
Subject: Re: Packaging software...
Date: 11 Apr 2000 21:52:44 GMT

Andre Charbonneau <[EMAIL PROTECTED]> wrote:

> I'm currently working on a regional settings control panel protoype
> (that works with system-level localization and uses Qt for UI) and I
> would like to put it in a nice package so that other linux users can
> give it a try.  I would like users to be able to do a './configure' to
> generate the makefiles according to their system's settings.  Can anyone
> help me on this one?  Where can I find good documentation about this
> topic?

This looks like a job for Autoconf.  You write a (usually quite brief)
description of the sorts of things which need configuring using some m4
macros, and it creates a configure script which works just like all the
other configure scripts provided with GNU packages.  Fetch it from your
nearest friendly GNU mirror, and read the provided documentation,
because it's quite good.  There are also lots of good examples to look
at.

I find Automake is quite helpful too.  It generates Makefiles which do
all sorts of useful things as well as just building programs (such as
handling automatic dependencies on header files, and building source
distributions).

Fitting one or both of these into your existing program will be a bit of
work, but I suspect that it'll be worth it in the long run.

-- [mdw]

------------------------------

From: nightstalker <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: Idea !!!
Date: Tue, 11 Apr 2000 22:03:51 GMT

Akbar Avliyaev wrote:

> The main problem of Linux is hardware support.
> On the other hand Windows supports most of hardware,
> most vendors ship products with drivers for windows.
> I'm thinking about making a way to use windows drivers in Linux.
> Have anyone thought about it?
> Is it reasonable/possible?

read www.slashdot.org :) there's an announcement of some kind about
this very thing today.

there's a company deliviring cross platform driver development kits.
the main problem is : speed.
also maybe the fact that it's so simple, a newbie can write a driver
using the thing. would you want drivers written by newbies ? :)

anyways, for your idea .. these drivers would have to be emulated
somehow ... i think the overhead this would cause would be
enormous. because you would have to first emulate the binary
code from the driver, and translate it into linuxlike system calls.

it would definately be a lot slower than drivers you are experiencing
today in linux.


------------------------------

From: [EMAIL PROTECTED] (Andy Newman)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Wed, 12 Apr 2000 08:14:09 +1000
Reply-To: [EMAIL PROTECTED]

Tom Mitchell wrote:
>Are there M3 compilers in the gnu world that are up to the task?
>
>   At least three processor targets.

Not the gnu world but look at,

    http://www.research.digital.com/SRC/modula-3/html/home.html



-- 
Chuck Berry lied about the promised land

------------------------------

From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: 11 Apr 2000 22:44:46 GMT

In comp.os.linux.development.apps aflinsch <[EMAIL PROTECTED]> wrote:
: "Peter T. Breuer" wrote:

:> : I liked the basis of the technology, if IBM would have built a micro370, and
:> : a trimmed down version of VM/370 instead of signing on with Microsoft, we
:> : would all be using true blue systems for this stuff.
:> 
:> Possibly. JCL was inflexible gobbledegook.

: gobbledegook perhaps, but very flexible, IF you understand it. Main
: purpose was to seperate ties to i/o from the program, and provide a
: consistrent method to bind files to a program symbolically. Once one
: understands the basic concepts of it, it becomes rather simple.

So could one do pipes?

Peter

------------------------------

From: Mark McIntyre <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Wed, 12 Apr 2000 00:08:50 +0100
Reply-To: [EMAIL PROTECTED]

On 11 Apr 2000 17:54:49 GMT, [EMAIL PROTECTED]
(Dave Vandervies) wrote:

>In article <[EMAIL PROTECTED]>, Dima Volodin  <[EMAIL PROTECTED]> wrote:
>>Floyd Davidson wrote:
>>
>>> The macro NULL must be a null pointer constant, which is either
>>> an integral constant expression of value 0 or such an expression
>>> cast to a void*.  (In other words, it has an all 0 bit pattern.)
>>
>>There's no requirement that ((void*)0) produced all 0 bit pattern.
>
>That's irrelevant until run time, though; it _is_ required that (void *)0
>(or any pointer to which it has been assigned) compares equal to 0, so
>what it produces at run time is irrelevant to the programmer.

Not quite. It must only compare equal to (int)0 when cast to int
(either explicitly or implicitly). It may be represented by all-ones
or all zeros or half of each. If you were to compare it to char* or
double or something else, then the conversion would not be guaranteed
(unless an intermediate conversion to int is guaranteed) and it might
well fail. 
Mark McIntyre

C- FAQ: http://www.eskimo.com/~scs/C-faq/top.html

------------------------------

From: Mark McIntyre <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Wed, 12 Apr 2000 00:05:44 +0100
Reply-To: [EMAIL PROTECTED]

On Tue, 11 Apr 2000 00:30:02 GMT, "Mike Spooner"
<[EMAIL PROTECTED]> wrote:

>
>
>Mark McIntyre <[EMAIL PROTECTED]> wrote in article
><[EMAIL PROTECTED]>...
>> On Wed, 05 Apr 2000 10:07:09 -0400, Ron Natalie <[EMAIL PROTECTED]>
>> wrote:
>> 
>> >
>> >
>> >Joe Pfeiffer wrote:
>> >> 
>> >> David Williams <[EMAIL PROTECTED]> writes:
>> >> >
>> >> >   a) 0 == NULL (an integral constant expression with value 0...
>> >> >      converted by comparsion...this produces a null pointer..)
>> >> >      ^^^^^^^^^^^^^^^^^^^^^^^
>> >> >      ??? are they the same or not?? NB A conversion could be
>taking
>> >> >      place implying that they are not.
>> >> 
>> >> This is a subtle point, and you've picked up on it perfectly.  It
>is
>> >> possible, in principle, for the conversion to take place so that
>> >> (void *) 0 is not a word full of all zeroes, and NULL need not be
>> >> represented as all zeroes.
>> >
>> >NULL is necessarily an integer zero constant.
>> 
>> n2874 
>> 7.17
>>               NULL
>>        which  expands  to  an  implementation-defined  null pointer
>>        constant
>> 6.3.2.1
>>        [#3] An integer constant expression with  the  value  0,  or
>>        such  an  expression  cast  to type void *, is called a null
>>        pointer constant.
>> 
>> thus NULL may be either an integer or a void*. Its incorrect to state
>> that it _must_ be an integer.
>> 
>
>It is also not comletely correct to say that it must be zero. The ANSI
>C standard
>allows NULL to be an arbitrary bit-pattern, but insists that the
>compiler convert
>it to a zero value when assigning or comparing it with an integer type.

In fact the standard says nothing at all about the bitpattern of NULL
so long as it is either (int)0  or (void*)(int)0. 
Mark McIntyre

C- FAQ: http://www.eskimo.com/~scs/C-faq/top.html

------------------------------

From: Mark McIntyre <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Wed, 12 Apr 2000 00:18:32 +0100
Reply-To: [EMAIL PROTECTED]

On 11 Apr 2000 11:52:01 -0800, Floyd Davidson <[EMAIL PROTECTED]>
wrote:

>Dima Volodin <[EMAIL PROTECTED]> wrote:
>>Floyd Davidson wrote:
>>
>>> The macro NULL must be a null pointer constant, which is either
>>> an integral constant expression of value 0 or such an expression
>>> cast to a void*.  (In other words, it has an all 0 bit pattern.)
>>
>>There's no requirement that ((void*)0) produced all 0 bit pattern.
>
>Yes there is.  It is a *null pointer constant* with a value of 0,
>and will not be _converted_ to a null pointer unless it is compared or
>assigned to a pointer type.

No there isn't. Reread 6.3.2.3 again

        "An integer constant expression with  the  value  0,  or
       such  an  expression  cast  to type void *, is called a null
       pointer constant."

This says that either its (int)0 or else (void*)(int)0. it says
nothing at all about whether the bit pattern is all-zeros or all ones.

And by the way, if the hardware chooses to store (void*)0 as all-ones
then thats up to it. the C standard makes no assertions at all about
that! 


Mark McIntyre

C- FAQ: http://www.eskimo.com/~scs/C-faq/top.html

------------------------------

From: Erik Max Francis <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Tue, 11 Apr 2000 16:46:40 -0700

Mark McIntyre wrote:

> This says that either its (int)0 or else (void*)(int)0. it says
> nothing at all about whether the bit pattern is all-zeros or all ones.
> 
> And by the way, if the hardware chooses to store (void*)0 as all-ones
> then thats up to it. the C standard makes no assertions at all about
> that!

He knows that.  Don't mix up the null pointer constant 0 or (void *) 0
with the null pointer itself, which may be represented internally as
something other than than all-bits-zero.

-- 
   Erik Max Francis | email [EMAIL PROTECTED] | icq 16063900
    Alcyone Systems | web http://www.alcyone.com/max/ | q3a Product
       San Jose, CA | languages en, eo | icbm 37 20 07 N 121 53 38 W
                USA | 969.656 Ms p.L. | 264 days left | &tSftDotIotE
 __
/  \ My life was better before I knew you.
\__/ Edith Wharton (to Morton Fullerton)

------------------------------

From: Erik Max Francis <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Tue, 11 Apr 2000 16:50:07 -0700

Mark McIntyre wrote:

> In fact the standard says nothing at all about the bitpattern of NULL
> so long as it is either (int)0  or (void*)(int)0.

NULL is a macro.  The confusion happening here is that people are mixing
up the concepts of NULL (the macro), the null pointer constant (the
expression in C or C++ that you write to get a null pointer -- 0 or
(void *) 0), and the null pointer itself (which is the
platform-dependent pattern pattern of bits in a pointer context). 
Everyone is saying the same thing, but some are using less clear
language and are misinterpreting what others are saying.

-- 
   Erik Max Francis | email [EMAIL PROTECTED] | icq 16063900
    Alcyone Systems | web http://www.alcyone.com/max/ | q3a Product
       San Jose, CA | languages en, eo | icbm 37 20 07 N 121 53 38 W
                USA | 969.656 Ms p.L. | 264 days left | &tSftDotIotE
 __
/  \ We're here to preserve democracy, not to practice it.
\__/ Capt. Frank Rasmey

------------------------------

From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: syscall during shrinking?
Date: Wed, 12 Apr 2000 00:19:17 GMT

In article <[EMAIL PROTECTED]>, 
Weiguang Shi wrote:
>Thanks for your response.
>
>It seems to me that "ed" will "truncate" a file to zero before writing the
>modified file (in memory?) to it.
>
>That's really strange.

No really.
[...]
>> To answer the question as asked, `ed' will:
>> 
>>   * open(file, O_RDONLY)
>>   * read() the file until EOF (read returns zero).
>>   * close()
>> 
>> Then you edit, and save the file.  `ed' will then:
>> 
>>   * open(file, O_WRONLY | O_CREAT | O_TRUNC, 0666)
>>   * write() all of the file's contents
>>   * close()
>> 
>> That's probably not what you wanted to hear.  I suspect that you really
>> wanted to know about the ftruncate(2) function, which you should look up
>> in a convenient manual page.
[...]
You see, O_TRUNC is mentioned here and the thing is, that a simple
close is never going to truncate a file. In other words, you open
a file, you read it, you write only half of it back and nada ... the
file is still going to have the same size.

I guess the man(ual) a./o. info pages do mention that, but I have
not had a look to be honest as this is the "normal" behaviour.

I cannot tell what ed does as it is a really old programme and
so it might not use (f)truncate(), but the general idea applies,
even the previous poster did not explicitly highlight that.

Cheers,
Juergen

-- 
\ Real name     : Jürgen Heinzl                 \       no flames      /
 \ EMail Private : [EMAIL PROTECTED] \ send money instead /

------------------------------

From: Kenneth Mankoff <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: Idea !!!
Date: Tue, 11 Apr 2000 18:27:32 -0600

>Akbar Avliyaev wrote:
>
>> The main problem of Linux is hardware support.
>> On the other hand Windows supports most of hardware,
>> most vendors ship products with drivers for windows.
>> I'm thinking about making a way to use windows drivers in Linux.
>> Have anyone thought about it?
>> Is it reasonable/possible?
>
>read www.slashdot.org :) there's an announcement of some kind about
>this very thing today.
>
>there's a company deliviring cross platform driver development kits.
>the main problem is : speed.
>also maybe the fact that it's so simple, a newbie can write a driver
>using the thing. would you want drivers written by newbies ? :)
>
>anyways, for your idea .. these drivers would have to be emulated
>somehow ... i think the overhead this would cause would be
>enormous. because you would have to first emulate the binary
>code from the driver, and translate it into linuxlike system calls.
>
>it would definately be a lot slower than drivers you are experiencing
>today in linux.
>

VMWare does it. You can watch DVD's through Windows running in VMWare on
Linux.

-k.


------------------------------

From: Philip <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Kernel development
Date: Wed, 12 Apr 2000 00:31:48 GMT

Ivan Van den Bossche wrote:
> 
> Hello everybody,
> 
> Where can I find the right documentation on the WEB to get started with
> Kernel development?  What do I need to know?
>

C



-- 
Philip van Hoof aka freax         _/_/_/                                
http://users.pandora.be/skatan  _/_/  _/ _/_/   _/_/_/    _/_/   _/   _/
mailto:[EMAIL PROTECTED]        _/_/     _/ _/  _/       _/  _/   _/  _/ 
Microsoft OS are bad, and   _/_/_/_/   _/  _/ _/_/    _/_/_/_/   _/_/   
their morals are even worse  _/_/     _/     _/      _/    _/  _/  _/   
(Linus Torvalds 8 Sept.1996)_/_/     _/      _/_/_/ _/    _/ _/     _/

------------------------------

From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: struct passwd *
Date: Wed, 12 Apr 2000 00:46:11 GMT

In article <8ctcrg$sva$[EMAIL PROTECTED]>, bill davidsen wrote:
>
>In article <[EMAIL PROTECTED]>,
>Dan McGuirk  <[EMAIL PROTECTED]> wrote:
>| bill davidsen wrote:
>| >   Someone have the source for glibc handy? I don't, and I'm not going to
>| > go grab it.
>|
>| You don't need the source, just the documentation.  From the glibc
>| manual:
>
>  I'm looking at a Redhat 5.2 man page right now, and it doesn't say
>anything like that, and even warns that you can get ENOMEM if there's no
>memory available to allocate.
>
>  Oops, RH did change something, or the library implementation changed,
>I checked a 6.1 machine, and it does say static, but it also reports
>the same error message. Obviously you can't get a memory unavailable if
>you have a static allocation, perhaps they save the result of the first
>dynamic allocation and reuse it. Another case for the source code.
>
>  Unfortunately, you really *must* know which it is, since you don't
>want to free a static buffer, but if you don't free a dynamic buffer you
>leak memory. Not as clear as I might hope, and possibly not the same
>with all glibc versions. My 2.0.7 doesn't say static, and I think I
>downloaded that.
[...]

Usually I do not do this, but in this case .. never, repeat .. *never*
make an assumption regarding how the mentioned functions handle their
memory. It can be static memory, it can be memory allocated on the
first call, whatever.

The official documentation is pretty clear regarding that and in can
be boiled down to ...
() if you need the returned value copy the contents.
... and that is it, full stop, no room left for any interpretation.

There is no memory leak either, this is, sorry, nonsense.

Ta',
Juergen

-- 
\ Real name     : Jürgen Heinzl                 \       no flames      /
 \ EMail Private : [EMAIL PROTECTED] \ send money instead /

------------------------------

From: "T.E.Dickey" <[EMAIL PROTECTED]>
Subject: Re: readline()
Date: Wed, 12 Apr 2000 01:22:51 GMT

Philip <[EMAIL PROTECTED]> wrote:

> I need a function that reads a defined amount of characters from the
> keyboard (stdin?). When the user presses to much characters it should
> stop reading these (do a beep or..). the function should also allow the
> user to use the arrowkeys , delete key and backspace key (so like
> reading something in textboxes like in windows/X/<form><input
> type=text>/.. but then in the console -text mode-). I would like an ANSI
> C method so I dislike using curses and/or readline in linux (using these
> it would be possible with the standard functions in these libs).

you can't - in ANSI C (it's an faq in comp.lang.c)

-- 
Thomas E. Dickey
[EMAIL PROTECTED]
http://www.clark.net/pub/dickey

------------------------------

From: "T.E.Dickey" <[EMAIL PROTECTED]>
Subject: Re: logging xterm seesions
Crossposted-To: comp.os.linux.development,comp.os.linux.misc
Date: Wed, 12 Apr 2000 01:24:38 GMT

In comp.os.linux.development.system Gast Primus <[EMAIL PROTECTED]> wrote:
> I've noticed that the logging of xterms is not supported by linux - the menu
> option does not exist and the xterm help states that it is unsupported. How
> do I log my xterm sessions.

it's a compilation option (for xterm).

but 'script' does a better job.

-- 
Thomas E. Dickey
[EMAIL PROTECTED]
http://www.clark.net/pub/dickey

------------------------------

From: "Celestial Wizard" <[EMAIL PROTECTED]>
Subject: fork and pipe
Date: Sat, 8 Apr 2000 13:28:28 +1000
Reply-To: "Celestial Wizard" <[EMAIL PROTECTED]>

Hi there,


i need to create a program that will fork n times and open pipes between the
processes so they can act as a ring.
so far, i am able to create two pipes and redirect them using dup2 to stdin
and stdout, and create a child process from the parent.

the user has to be able to say on the commandline how many processes they
want.  what i think i will need to do is

int childpid;
int nprocs;
int i;

if ((childpid = fork ()) != 0) /* parent */
{
  /* blah */
} else { /* child */
  for (i = 0; i <= nprocs; i++)
  {
    if ((childpid = fork ()) != 0) /* parent child */
    {
      /* something */
    } else { /* child child */
    }
  }
}


does that look right??



--


   The Celestial Wizard
   President - South East Brisbane Linux Users Group
   Linux - Where You WANT To Be!



------------------------------

From: Atcq4eva <[EMAIL PROTECTED]>
Subject: Re: Linux Daemon problem
Date: Wed, 12 Apr 2000 01:34:58 GMT

Manoj Patil wrote:
> 
> Dear All,
> 
> I am facing a weired problem on linux system. I have a client server
> application. The server is a daemon.  The client can inform the server
> to restart itself.
> Now I have two scenarios
> 
> 1. When I start the server from the shell prompt, the application works
> properly. The client informs the server to restart and it happens
> graciously
> 
> 2. However, when I start the server from init routine (rc.d), the server
> does not restart itself when the client asks it to do so.
> 
> The code is a neatly written standard code and it works fine on AIX and
> solaris. Thsi problem occurs only on linux
> 
> Any guesses ????
> 
> Regards

Seems like deja vu all over again :) I just debugged a similar problem
where application would run fine from a terminal but would exit when
launched by the rc.d on Tru64. What happened was a SIGHUP signal was
being sent when the terminal window running the start up scripts closed
and the application was stopping. Added a handler to ignore the SIGHUP
signal and all was happy. I don't know if this holds in your situation
but it's an angle to look at.

Olu

------------------------------

From: Floyd Davidson <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: 11 Apr 2000 16:54:39 -0800

Mark McIntyre <[EMAIL PROTECTED]> wrote:
>Floyd Davidson <[EMAIL PROTECTED]> wrote:
>>Dima Volodin <[EMAIL PROTECTED]> wrote:
>>>Floyd Davidson wrote:
>>>
>>>> The macro NULL must be a null pointer constant, which is either
>>>> an integral constant expression of value 0 or such an expression
>>>> cast to a void*.  (In other words, it has an all 0 bit pattern.)
>>>
>>>There's no requirement that ((void*)0) produced all 0 bit pattern.
>>
>>Yes there is.  It is a *null pointer constant* with a value of 0,
>>and will not be _converted_ to a null pointer unless it is compared or
>>assigned to a pointer type.
>
>No there isn't. Reread 6.3.2.3 again
>
>       "An integer constant expression with  the  value  0,  or
>       such  an  expression  cast  to type void *, is called a null
>       pointer constant."
>
>This says that either its (int)0 or else (void*)(int)0. it says
>nothing at all about whether the bit pattern is all-zeros or all ones.
>
>And by the way, if the hardware chooses to store (void*)0 as all-ones
>then thats up to it. the C standard makes no assertions at all about
>that! 

Where does that allow the value of an "null pointer constant" to
be anything except a value of 0?  Are you not confusing a "null
pointer constant" with a "null pointer"?  The entire context of
6.2.2.3 (note, not 6.3.2.3) is:

    "An integral constant expression with the value
    0, or such an expression cast to type void *,
    is called a _null_pointer_constant_.  If a null
    pointer constant is assigned to or compared for
    equality to a ponter, the constant is converted
    to a pointer of that type.  Such a pointer,
    called a _null_pointer_, is guaranteed to
    compare unequal to a pointer to any object or
    function.

    Two null pointers, converted through possibly
    different sequences of casts to pointer types,
    shall compare equal."

It is not the "null pointer constant" which can have an
implementation defined bit pattern, it is the "null pointer".
They are distinctly to different concepts, and a "null pointer
constant" is only converted to a "null pointer" under the two
explicit circumstances.

Essentially, 

   if (NULL) {...}

does not cause the null pointer constant to be converted to a
null pointer, while,

   char *p = NULL;
   if (p) {...}

does result in a null pointer.  That is the way I read it, and
it appears to reduce the number of places where a conversion to
a null pointer takes place.  It also allows each type to more
easily have a different bit representation for a null pointer of
that type.

  Floyd

-- 
Floyd L. Davidson                          [EMAIL PROTECTED]
Ukpeagvik (Barrow, Alaska)

------------------------------

From: "Celestial Wizard" <[EMAIL PROTECTED]>
Crossposted-To: 
comp.os.linux.hardware,comp.os.linux.development.apps,linux.redhat.devel
Subject: Re: Q: How good is Linux when the computer is suddenly loses power ?
Date: Sat, 8 Apr 2000 13:27:12 +1000
Reply-To: "Celestial Wizard" <[EMAIL PROTECTED]>

no you twit, it means that when he trips on the cable, it dont pull out so
easily, because there is slack

--


   The Celestial Wizard
   President - South East Brisbane Linux Users Group
   Linux - Where You WANT To Be!
Miguel Cruz <[EMAIL PROTECTED]> wrote in message
news:nFnt4.317$[EMAIL PROTECTED]...
> Markus Wandel <[EMAIL PROTECTED]> wrote:
> > (I have since gotten a longer power cord, eliminating the accidental
> > powerdowns!)
>
> Does that work the same way that a longer garden hose means you have a
> little more water around when the main gets shut off?
>
> miguel





------------------------------


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

Reply via email to