Subject: Linux-Development Digest #918
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Fri, 15 Jul 94 18:13:09 EDT

Linux-Development Digest #918, Volume #1         Fri, 15 Jul 94 18:13:09 EDT

Contents:
  Re: POP3 server for Linux (1.1.24)? (Mitchum DSouza)
  Re: system("ls") doesn't display anything to screen? (bobs@apgea.army.mil (J. Robert Suckling ))
  Re: Returning free'd memory (Elan Feingold)
  Duff's Device (Elan Feingold)
  Re: Programming in Linux (rodrigo vanegas)
  Re: Linux Performance Enhance ? (Chris Bitmead)
  Re: mstats.o missing in libc.a (H.C.W. Kwok)
  Re: Duff's Device (Dick Edgar)
  Re: Returning free'd memory (Patrick Schaaf)
  Re: Returning free'd memory (Ken Pizzini)
  Re: Linux Performance Enhance ? ("John E. Davis")
  Re: Can DOSEMU execute a unix shell or program?? (Daniel Barlow)
  Re: Starting New DIP (Paul Cadach)

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

From: Mitchum DSouza <m.dsouza@mrc-apu.cam.ac.uk>
Subject: Re: POP3 server for Linux (1.1.24)?
Date: 15 Jul 1994 10:30:23 -0400
Reply-To: m.dsouza@mrc-apu.cam.ac.uk


Pete Kruckenberg asks:
| I'm trying to get a POP3 server set up on my Linux (1.1.24) box, and
| am having some problems. I got the pop3d-1.00.4.tar.gz from sunsite,
| and when I try to compile, there are two #include files from util.c it
| can't find: shadow/shadow.h and shadow/pwauth.h. These are only
| included when SHADOWPWD is defined, which maybe I don't need. I just
| want to set up a server people can connect into from their (PC)
| workstation or remotely. I don't know what the SHADOWPWD does--maybe
| if someone could explain, I might just disable it.

Have a look to see if all the encrypted password field entries in your
/etc/passwd file hasv an astreix "*" in them instead of some garbled
characters. If they do have "*" in the second field then you are using shadow
passwords and you need the SHADOWPWD define along with the shadow library and
its related includes. Read Questin 32 of the GCC-FAQ on sunsite.unc.edu
/pub/Linux/docs/faqs for more info.

| While I'm on the subject, I'd really like to find some good
| documentation on what POP can do and how to configure both a client
| and a server. Ultimately, I'd like to use POP to provide a high-volume

The pop server is fairly easy. Just put the appropriate entry in
/etc/inetd.conf. As for the client side, Unix machines don't really have much
pop client software. You can however use the client by Carl Harris

        csugrad.cs.vt.edu:/pub/pop/popclient-2.21.tar.gz

| mailing list over our 28.8k link by using POP to send a single copy of

You (or I) are getting confused here. The pop server (via inetd) just sits
there waiting for requests. It doesn't have the ability to push messages.
It will be the responsibility of the remote sites to request a message from
the POP server.

| each out-going message to our provider, where it would be distributed.
| That way I would only send one message over our bandwidth, and the 200
| or so copies would go out from our provider. Is this possible to do,
| and can I do it with a list server such as LISTSERV, MajorDomo, or
| others?  Any pointers or suggestions would be appreciated.

It sounds feasible, but I haven't any experience with listservers.

Mitch

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

From: bobs@apgea.army.mil (J. Robert Suckling <bobs>)
Subject: Re: system("ls") doesn't display anything to screen?
Date: Fri, 15 Jul 94 14:38:45 GMT

In article <305rv6$hp5@harbinger.cc.monash.edu.au> kevinl@bruce.cs.monash.edu.au (Kevin Lentin) writes:
>Tim Smith (tcsmith@csi.nb.ca) wrote:
>> Hello
>
>> Why doesn't system("ls") display anything to the screen.
>> This is the case for both c and perl.
>
>
>Works fine for me. Any more details than that?
>
>-- 
>[==================================================================]
>[ Kevin Lentin                   |___/~\__/~\___/~~~~\__/~\__/~\_| ]
>[ kevinl@bruce.cs.monash.edu.au  |___/~\/~\_____/~\______/~\/~\__| ]
>[ Macintrash: 'Just say NO!'     |___/~\__/~\___/~~~~\____/~~\___| ]
>[==================================================================]


I have done that more times then I will admit. :)

Let me guess, you are running this with cron!
You likly do not have your PATH set right.

How about running: system("/bin/ls");



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

From: feingold@zko.dec.com (Elan Feingold)
Subject: Re: Returning free'd memory
Date: 15 Jul 1994 14:55:17 GMT
Reply-To: feingold@zko.dec.com (Elan Feingold)



> What about mprotect() while we are at it?

Yes, please!  This might make it easier to add fast watchpoints to GDB.

elan

--
===============================================================================
|| Elan Feingold                  ||
|| Software Engineer II           ||
|| Digital Equipment Corporation  ||
|| Work: 603.881.1115             ||
===============================================================================

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

From: feingold@avette.zko.dec.com (Elan Feingold)
Subject: Duff's Device
Date: 15 Jul 1994 14:57:07 GMT
Reply-To: feingold@avette.zko.dec.com (Elan Feingold)


Can anyone give me a concise definition of what a Duff's Device is?

elan

--
===============================================================================
|| Elan Feingold                  ||
|| Software Engineer II           ||
|| Digital Equipment Corporation  ||
|| Work: 603.881.1115             ||
===============================================================================

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

From: rv@cs.brown.edu (rodrigo vanegas)
Subject: Re: Programming in Linux
Date: Fri, 15 Jul 1994 17:41:18 GMT

In article <1994Jul12.175746.17418@desaster.student.uni-tuebingen.de>, michaelw@desaster.student.uni-tuebingen.de (Michael Will) writes:

>>#ifdef notdef
>>blah, blah
>>#endif 

>>I mean really, what is the "notdef" variable supposed to mean???

> It is meant as an undefined variable - it is yet another way to comment
> out code :-)

What ever happened to 

  #if 0
  blah(blech);
  #endif

which is more straightforward.


rodrigo vanegas
rv@cs.brown.edu

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

From: chrisb@cssc-syd.tansu.com.au (Chris Bitmead)
Subject: Re: Linux Performance Enhance ?
Date: 15 Jul 1994 10:38:11 +1000

andy@eng.kvaerner.no (Andrew Walker) writes:


>Ron Smits (ron@draconia.hacktic.nl) writes:

>|     Rob> static int try_to_free_page(int priority)
>|     Rob> {
>|     Rob>    int i = 5;
>|     Rob>    static int what = 0;
>| 
>|     Rob>    switch (what)
>|     Rob>    {
>|     Rob>        while (i--)
>|     Rob>        {
>|     Rob>        case 0:
>|     Rob>          if (priority != GFP_NOBUFFER && shrink_buffers(i)) {
>|     Rob>            what = 1;
>|     Rob>            return 1;
>|     Rob>          }
>|     Rob>          /* drop */
>|     Rob>        case 1:
>|     Rob>          if (shm_swap(i)) {   
>|     Rob>            what = 2;
>|     Rob>            return 1;
>|     Rob>          }
>|     Rob>          /* drop */
>|     Rob>        case 2:
>|     Rob>          if (swap_out(i)) {
>|     Rob>            what = 0;
>|     Rob>            return 1;
>|     Rob>          }
>|     Rob>        }
>|     Rob>    }
>|     Rob>    return 0;
>|     Rob> }
>| 
>| 
>|     Rob> How is that?
>| 
>|     Rob> Rob
>| 
>| This is the best version I have seen sofar, but what is the unknown
>| C-language feature?
>| 

>Check out the while(i) statement that encloses the switch cases -
>the code jumps into a while loop. To be honest I can't even be bothered
>to check the legality of this in K&R (I think its totally non-intuitive,
>and thus "BAD CODE", but I'd defend it in the kernel if it really
>generates better code).

Can anyone confirm if this is really portable C? And if it is what does it
mean? 

How is this:

switch (what)
    {
        while (i--)
        {
        case 0:

different to this:

while (i--)
    {
    switch (what)
        {
        case 0:


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

From: cwhk@ic.ac.uk (H.C.W. Kwok)
Subject: Re: mstats.o missing in libc.a
Date: Fri, 15 Jul 94 15:50:30 BST

In article <1994Jul15.110416.2342@cc.ic.ac.uk> cwhk@ic.ac.uk (H.C.W. Kwok) writes:
>Hi there,
>
>I just found a curious problem in my Slackware 1.2.0 distribution.
>
>I was writing some code that and I wanted to monitor it the memory
>usage by malloc at various stage. So I used the mstats routine defined
>in malloc.h as:
>                       extern struct mstats mstats __P ((void));
>When I complied the program, I had the message that mstats was not 
>defined.
>
>So I looked in the libs. using nm, and couldn't find this routine.
>But I know this routine does exist in libc.a as I complied gcc
>at college:
>               >nm libc.a | grep mstats
>               mstats.o:
>               00000000 T _mstats
>Was it a bug in the distribution? And how can I fix the problem
>without recompiling/reinstalling gcc on my linux box? (i.e. are
>there any files that I can grep and just compile the missing links
>and then add to the lib libc.a?)
>
>Thanks 
>
>

Since my first posting, I have downloaded the GCC lib. from
the sunsite.mirror at src.doc:/packages/linux/sunsite.unc-mirror/GCC
Also, I have downloaded the glibc-1.08.1 also from src.doc:/packages/gnu

When I looked the content for the two files I found these differences:

glibc-1.08.1.tar.gz
rw-rw-rw-5281/0   3234 May  4 04:33 1994 glibc-1.08.1/malloc/Makefile
rw-rw-rw-5281/0   1118 Dec 29 23:26 1992 glibc-1.08.1/malloc/OChangeLog
rw-rw-rw-5281/0   1284 Jul 17 20:50 1991 glibc-1.08.1/malloc/TODO
rwxrwxrwx5281/0   1321 Jun 26 02:07 1992 glibc-1.08.1/malloc/calloc.c
rwxrwxrwx5281/0   1137 Mar  4 17:25 1994 glibc-1.08.1/malloc/cfree.c
rw-rw-rw-5281/0   1741 Feb 22 17:46 1993 glibc-1.08.1/malloc/dist-Makefile
rw-rw-rw-5281/0    658 Mar 17 21:40 1992 glibc-1.08.1/malloc/dist-README
rwxrwxrwx5281/0   6320 Aug 26 23:16 1992 glibc-1.08.1/malloc/free.c
rwxrwxrwx5281/0    626 Jul 30 23:30 1993 glibc-1.08.1/malloc/getpagesize.h
rwxrwxrwx5281/0  10323 Apr 21 21:54 1994 glibc-1.08.1/malloc/malloc.c
rwxrwxrwx5281/0   8612 May  4 00:24 1994 glibc-1.08.1/malloc/malloc.h
rw-rw-rw-5281/0    176 Mar 22 20:37 1993 glibc-1.08.1/malloc/malloc/gmalloc-head.c
rw-rw-rw-5281/0   1145 Mar  8 21:35 1992 glibc-1.08.1/malloc/mcheck-init.c
rwxrwxrwx5281/0   4715 Mar 28 21:55 1994 glibc-1.08.1/malloc/mcheck.c
r--r--r--5281/0   3731 Apr 19 23:52 1994 glibc-1.08.1/malloc/mem-limits.h
rwxrwxrwx5281/0   1723 Apr 20 22:55 1994 glibc-1.08.1/malloc/memalign.c
rwxrwxrwx5281/0   1346 Jun 26 02:06 1992 glibc-1.08.1/malloc/mstats.c
rwxrwxrwx5281/0    860 Nov 12 01:40 1991 glibc-1.08.1/malloc/mtrace.awk
rwxrwxrwx5281/0   4090 Jul 22 20:20 1993 glibc-1.08.1/malloc/mtrace.c
r--r--r--5281/0  14861 Feb  9 22:34 1994 glibc-1.08.1/malloc/obstack.c
r--r--r--5281/0  19732 Apr  5 09:26 1994 glibc-1.08.1/malloc/obstack.h
r--r--r--5281/0  13893 Nov 29 23:00 1993 glibc-1.08.1/malloc/ralloc.c
rwxrwxrwx5281/0   6360 Mar  3 22:55 1994 glibc-1.08.1/malloc/realloc.c
rwxrwxrwx5281/0   1403 Aug 13 00:26 1993 glibc-1.08.1/malloc/valloc.c
rwxrwxrwx5281/0   3572 Oct 14 21:08 1993 glibc-1.08.1/malloc/vm-limit.c
rw-rw-rw-5281/0   5108 Feb 17 02:37 1994 glibc-1.08.1/malloc/TAGS
rw-rw-rw-5281/0   1679 Jul 19 02:13 1993 glibc-1.08.1/malloc/mallocbug.c



libc.4.5.26.tar.gz :

rwxr-xr-x958/220      0 Apr  4 19:29 1994 ./libc-linux/malloc-930716/
rw-r--r--958/220    985 Dec 21 03:18 1993 ./libc-linux/malloc-930716/cfree.c
rw-r--r--958/220   2042 Dec 21 03:18 1993 ./libc-linux/malloc-930716/README
rw-r--r--958/220    860 Dec 21 03:18 1993 ./libc-linux/malloc-930716/calloc.c
rw-r--r--958/220   4473 Dec 21 03:18 1993 ./libc-linux/malloc-930716/free.c
rw-r--r--958/220   7330 Dec 21 03:18 1993 ./libc-linux/malloc-930716/malloc.c
rw-r--r--958/220   3068 Dec 21 03:18 1993 ./libc-linux/malloc-930716/malloc.h
rw-r--r--958/220    886 Dec 21 03:18 1993 ./libc-linux/malloc-930716/morecore.c
rw-r--r--958/220   3459 Dec 21 03:18 1993 ./libc-linux/malloc-930716/realloc.c
rw-r--r--958/220    963 Dec 21 03:18 1993 ./libc-linux/malloc-930716/valloc.c
rw-r--r--958/220    700 Jan 14 16:29 1994 ./libc-linux/malloc-930716/Makefile


It seems like that they do not have those routine like mstats, mtrace included.

This leads to further questions:

1) Who maintain the linux version of glib etc? So that I can discuss this with
   him/her
2) How can I port the 1.08 version to linux? Pointers to docs is appreciated.
   Or can I just compile the 1.08 codes?

Thanks!
-- 
|==========================================================| 
|   Hansel Kwok < h.kwok@ic.ac.uk >                        |
|   Imperial College of Science, Technology and Medicine   |
|==========================================================|

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

From: edgar@uwast.astro.wisc.edu (Dick Edgar)
Subject: Re: Duff's Device
Date: 15 Jul 1994 17:50:45 GMT

In article <306843$mmf@jac.zko.dec.com>,
Elan Feingold <feingold@avette.zko.dec.com> wrote:
>
>Can anyone give me a concise definition of what a Duff's Device is?

Here it is:


!From the "Jargon File":

! Duff's device: n. The most dramatic use yet seen of {fall
! through} in C, invented by Tom Duff when he was at Lucasfilm.
! Trying to {bum} all the instructions he could out of an inner
! loop that copied data serially onto an output port, he decided to
! {unroll} it.  He then realized that the unrolled version could
! be implemented by *interlacing* the structures of a switch and
! a loop:
!
!        register n = (count + 7) / 8;       /* count > 0 assumed */
!        switch (count % 8)
!         {
!         case 0: do {    *to = *from++;
!         case 7:         *to = *from++;
!         case 6:         *to = *from++;
!         case 5:         *to = *from++;
!         case 4:         *to = *from++;
!         case 3:         *to = *from++;
!         case 2:         *to = *from++;
!         case 1:         *to = *from++;
!         } while (--n > 0);
!         }
!
! Having verified that the device is valid portable C, Duff announced
! it.  C's default {fall through} in case statements has long been
! its most controversial single feature; Duff observed that "This
! code forms some sort of argument in that debate, but I'm not sure
! whether it's for or against."

=========
Richard J. Edgar  (edgar@uwast.astro.wisc.edu)
University of Wisconsin--Madison, Department of Astronomy
"An astrophysicist is someone who sees something working in practice,
and wonders whether it will work in principle." -- Harvey Liszt

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

From: bof@wg.saar.de (Patrick Schaaf)
Subject: Re: Returning free'd memory
Date: Fri, 15 Jul 1994 01:45:37 GMT

graphix@iastate.edu (Kent A Vander Velden) writes:

>Are there any planed changes to the Linux kernel to actually completely give 
>the memory back to the system which was free'd by the program before the 
>program exits?

Why would this require changes to the kernel? I'm sure there is some
malloc out there that uses mmap/munmap instead of brk.

Patrick

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

From: ken@chinook.halcyon.com (Ken Pizzini)
Subject: Re: Returning free'd memory
Date: 15 Jul 1994 00:18:39 GMT

In article <graphix.774209621@spiff.cc.iastate.edu>,
Kent A Vander Velden <graphix@iastate.edu> wrote:
>Are there any planed changes to the Linux kernel to actually completely give 
>the memory back to the system which was free'd by the program before the 
>program exits?

Unless you're claiming that the brk() system call is broken,
this isn't a kernel issue, but a library issue.  If one really
wanted to one could rewrite the malloc()/free()/etc. library
code and add a "reset_brk()" call, but care must be exercised
to be sure that the memory being returned to the system is
all unused.

                --Ken Pizzini

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

From: davis@pacific.mps.ohio-state.edu ("John E. Davis")
Subject: Re: Linux Performance Enhance ?
Reply-To: davis@amy.tch.harvard.edu (John E. Davis)
Date: Fri, 15 Jul 1994 19:47:02 GMT

In article <jqbCsz4sC.I0r@netcom.com> jqb@netcom.com (Jim Balter) writes:
  >In article <DAVIS.94Jul12144609@pacific.mps.ohio-state.edu>,
  >John E. Davis <davis@amy.tch.harvard.edu> wrote:
  >>
  >>It is true that the two pieces of code are different.  However, even setting
  >>`what' to zero and re-executing the loop will fail since `what' has been
  >>declared static.  Here is the original code.  My suggested replacement
  >>follows.

  >You are hallucinating.  The fact that "what" is static is irrelevant.

No. Look again.  The basic form of the code is this:

   static int what = 0;
   int i = 5;   
   
   switch (what)
     {
        label:
        case 0:
           if (some_condition) what = somthing;
        case 1:
           if (some_condition_1) what = somthing_else;
        case 2:
           if (some_condition_2) what = yet_somthing_else;
     }
   
  if (i--) goto label;

Suppose that what is 2 but some_condition fails during the 5 loops through the
tests.  The fact that what has been declared static means that the next time
the function is called, what will be 2 again.  Setting it to zero and looping
back to the switch invalidates this.

Perhaps this thread should be directed to comp.lang.c.newbie.  
--
     _____________
#___/John E. Davis\_________________________________________________________
#
# internet: davis@amy.tch.harvard.edu
#   bitnet: davis@ohstpy
#   office: 617-735-6746
#

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

Subject: Re: Can DOSEMU execute a unix shell or program??
From: u92drb@ecs.ox.ac.uk (Daniel Barlow)
Date: 15 Jul 94 21:50:34 BST

In article <2v0avg$5a@zola.apana.org.au> lukeh@zola.apana.org.au (Luke Howard) writes:
>
>Surely one could build these hooks into DOSEMU and then write the 
>appropriate Windows applications? Then, assuming performance is ok, it 
>might provide a reasonable front end for users with - I suppose 8meg 
>would be the minimum amount of ram - lowish end systems who don't want to 
>run X.

Ahem.  Speaking as the user of an 8Mb system, I have to say that X
runs a lot faster than Windows for me (two xterms, emacs & (TeX or gcc
as appropriate)).  Or maybe you really mean "don't want", not "can't",
for people who like the way Windows looks.  Personally I think it's
pig-ugly, (all that screen space wasted on big fat title bars) but
hey...

What might be a neat feature for dosemu is to test whether its input
is a tty when it gets EOF on it, and if not to copy it to a temporary
file and run it as a batch file after booting (and open the real
keyboard so people can use it, of course) then exit
That way you could do something like

dos <<__EOF__
cd \games\fs4
fs4
__EOF__

or maybe even scripts starting with #!/usr/bin/dos.  What do people think?

I like the suggestion about dumping DOS memory too.  That way I could
save & restore cosmic cosmo at the _end_ of level 10 instead of the
beginning ...

Daniel

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

From: paul@paul.east.alma-ata.su (Paul Cadach)
Subject: Re: Starting New DIP
Date: 16 Jul 1994 00:45:56 +0700

Rob Janssen (rob@pe1chl.ampr.org) wrote:
> In <2vrftq$6dk@doorway.invlogic.com> mmclagan@homebase.linux.org (Mike McLagan) writes:

> >   I'm going to start working on a new DIP.  (I need it for a specific purpose)
> >and I'd like to gather ideas and specs from people.

[skipped]
> - be careful to setup the line and the controlling tty stuff in such a
>   way that carrier drops are noticed (SIGHUP) and handled.
>   it would be nice to have the option to re-try the connection when it
>   has been established before and the carrier just drops unexpectedly.
>   (i.e. the command to terminate the connection or the idle timeout were
>   not the cause of the connection end)

I did make some changes in dip-3.3.7 for auto-redialing when carrier is
dropped. It very simple: I checking for zero return of 'read' function in
tty_getc procedure. The kernel changing tty-function's table when modem
switching CD from high to low (drop carrier), and the 'read' function in
'hangupped' table will always return 'zero'.

If it interested for somebody I can put sources of dip-3.3.7 with my
changes on mailserv@east.alma-ata.su.

> Good luck with the project!

Good luck too!

Sorry my english,
Paul.
-- 
Paul Cadach        System Programmer | kADA^ pAWEL   sISTEMNYJ PROGRAMMIST
e-mail:   paul@paul.east.alma-ata.su | FIDO:    2:5083/11.39
phone:    +7-(3232)-66-0538          | TEL.:    +7-(3232)-66-0538
=====================================+====================================

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


** 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: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************
