From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Thu, 18 Nov 93 06:13:59 EST Subject: Linux-Development Digest #233 Linux-Development Digest #233, Volume #1 Thu, 18 Nov 93 06:13:59 EST Contents: Re: How many BogoMips on a Pentium? (Alec Muffett) Re: How many BogoMips on a Pentium? (Mark A. Davis) Re: Berkeley Fast Filesystem (Hamish Macdonald) Re: Motif - Pay? BAH! (Nhi Vanye) Re: Help with s|gtty() (Mr D. Peethamparam) Re: Don't use Motif for free sw: it now requires runtime royalties! (Alan S. Mazer) Re: Don't use Motif for free sw: it now requires runtime royalties! (Doug Sewell) Re: Thought... (Richard Watts) Re: What's wrong with a DOS to Linux disk access? (John R. Campbell) Re: 16550A handling in serial.c (John R. Campbell) Re: Debugger wants libc source?! (J. M. O'Donnell) Re: [Q] Big modem installation for Linux? (Andreas Klemm) Re: Problem with Emacs/gdb/pl13. (Andreas Klemm) Re: Debugger wants libc source?! (Mark Eichin) Re: Berkeley Fast Filesystem (Stephen Williams) Re: STRLEN() == 3 ??!?? (Matthew Rhoten) ---------------------------------------------------------------------------- From: alecm@uk-usenet.uk.sun.com (Alec Muffett) Subject: Re: How many BogoMips on a Pentium? Date: 17 Nov 1993 12:57:42 GMT Reply-To: alecm@uk-usenet.uk.sun.com In article 93Nov16222300@deathstar.cs.hut.fi, hpasanen@cs.hut.fi (Harri Pasanen) writes: >If you have booted Linux on a Pentium machine, how many BogoMips did you >get? > >For the record, my Intel 386/33 gives 5.99 BogoMips. I hear Cyrix 486DLC40 >should give around 13. What about other processors? 486dx2/66 -> 33 BogoMips ------------------------------ From: mark@taylor.wyvern.com (Mark A. Davis) Subject: Re: How many BogoMips on a Pentium? Date: Wed, 17 Nov 1993 13:22:20 GMT ftlofaro@unlv.edu (Frank Lofaro) writes: >In article hpasanen@cs.hut.fi (Harri Pasanen) writes: >>Hi, >> >>Just to satisfy my curiosity: >> >>If you have booted Linux on a Pentium machine, how many BogoMips did you >>get? >> > This begs the question, does Linux even boot on a Pentium? No, actually it begs for more information. I doubt there will be much performance improvement if he is talking about the stipped down version stuck into a regular clone body of today running software not "optimized".... But then, if he is talking about the non-stripped down Pentium in a suitable machine with 64 bit fast memory access and such, then it gets interesting. -- /--------------------------------------------------------------------------\ | Mark A. Davis | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 | | Sys.Administrator| Computer Services | mark@taylor.wyvern.com .uucp | \--------------------------------------------------------------------------/ ------------------------------ From: Hamish.Macdonald@bnr.ca (Hamish Macdonald) Crossposted-To: comp.os.linux.admin Subject: Re: Berkeley Fast Filesystem Date: 12 Nov 1993 01:23:50 GMT >>>>> On 11 Nov 1993 15:42:59 EST, >>>>> In message , >>>>> wayne@backbone.uucp (Wayne Schlitt) wrote: Wayne> The Berkeley Fast Filesystem changed things to use a 8k block Wayne> size, which is better for a disk access size, but horrible for Wayne> an allocation size. In order to "fix" the problem with the Wayne> allocation size, they created fragments, which are 1k. Wayne> Unfortunately, you can only use a fragment if the entire file Wayne> fits in the fragment, so the FFS wastes, on average 4k any time Wayne> the file is over 1k in size. This last statement isn't true. In general, in the FFS, the file consists of 0 or more blocks, plus 0-7 fragments, where both the blocksize and fragment size can vary. Thus I could have a 18K file which consists of 2 full 8K blocks, and 2 1K fragments. The other 6 fragments from the block *my* fragments were allocated are available as fragments for other files. ------------------------------ From: offer@robots.ox.ac.uk (Nhi Vanye) Subject: Re: Motif - Pay? BAH! Date: Wed, 17 Nov 1993 14:38:55 GMT Replacing Motif look-and-feel from the users view is fairly easy (see the FWF widgets or Xaw3d) and mwm can be simulated with fvwm. The real problem is producing a Motif compatable (from the programmers point of view) widget set. Its taken OSF over 4 years to write their API, and I for one will never again look inside the RowColumn widget source, it gave me nightmares for weeks after :-) May I ask a simple question, what is wrong with paying for Motif? With the money I saved by not having to pay for MS-DOG/Windows/compilers etc. I could afford to pay the UK$130 motif cost me. richard (ex-Motif Hacker, now paying the rent by sys-admining). ------------------------------ From: ins308z@mdw054.cc.monash.edu.au (Mr D. Peethamparam) Subject: Re: Help with s|gtty() Date: 17 Nov 1993 14:03:08 GMT > I was trying to use "stty(1, tty_settings)" (where tty_settings is type > struct sgttyb), but I haven't had much success with it. I found the > needed structure in , but I haven't found the actual stty > and gtty function calls. On my Ultrix box, they're in . > > Does anyone know how I can perform the equivalent "stty" and "gtty" > calls without shelling to the system? (Perhaps an ioctl?) Any help > is much appreciated! (Oh, I know about curses, but I want to use that > as a 2nd to last resort -- last being "system (stty raw)".) I came across this problem when trying to compile tput for my box. I finally had to search sunsite for a compiled binary, but I found a patch provided by Rik Faith. The gist of it is, you need : #define stty(fd,buf) #define gtty(fd,buf) That's it. I don't know why this works, but it does -- for tput anyway. Anyone care to enlighten me? :) Deeran ------------------------------ From: alan@elroy.jpl.nasa.gov (Alan S. Mazer) Crossposted-To: comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: 17 Nov 1993 21:06:40 GMT > * the XView library, donated by Sun, is rather high quality and easy > to program into. NOT! I've used XView for years. Motif is much more flexible and easier to structure and use. Plus, even Sun is giving up on XView. Switching from Motif to XView is the wrong transition to be making. (Hey, when I change it's because there is really really no reason to stay. I'm always one of the last to jump on a bandwagon.) > * the Interviews library, for C++ programmers, is also very high > quality and easy to program for, and rumour is that it will become > a standard part of X11R6. People I know who've used it haven't liked it much. Granted, this info is a year or two old. > * the venerable Athena widget library is standard with most all X11 > packages, and there are several high quality high level widgets > available in the Free Widget Foundation collection, which cover > the functionality of the more sophisticated XView/Motif/Interviews > widgets. > > * if you really want a Motif Look&Feel, there are libraries that are > not sold by OSF which have a different API and less restrictions. > > * perhaps you might consider using wxWin, a freeware library > with an API that is independent of the windowing system used. While helpful for the task of writing something and getting it out, Motif is here to stay and isn't going to leave room for this other stuff, as far as I can see, for very long. I sympathize with the distribution problem, but grabbing stuff from here and there isn't the answer. We have enough problems without avoiding the standards that are there. >Finally a personal note: I think that this decision of the OSF is ill >considered; I am hard pressed to think of *any* supplier of graphical >libraries of any sort that requires the payment of a royalty on every >copy of a program using a runtime library. I agree on the latter point. It stinks. But from a business perspective, they've got the customers. They may as well "turn the screw". Look at who you're dealing with: IBM, Dec, etc, companies that are very comfortable with getting others in a tight spot and then making all the money they can from them. The only alternative solution is a new "standard" library and I don't think you'll see that unless something develops with Windows NT. -- -- Alan # Mountain Dew and doughnuts... ..!ames!elroy!alan # because breakfast is the most important meal alan@elroy.jpl.nasa.gov # of the day. ------------------------------ From: doug@cc.ysu.edu (Doug Sewell) Crossposted-To: gnu.misc.discuss,comp.sources.d Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: 17 Nov 1993 21:50:29 GMT Alan S. Mazer (alan@elroy.jpl.nasa.gov) wrote: : them. The only alternative solution is a new "standard" library and I don't : think you'll see that unless something develops with Windows NT. And I doubt Microsoft will be any more benevolent/etc than OSF and companies, about their interface. Hell, I bet if they had their wish, they'd change the Windows API, make it proprietary (like Nintendo), and charge royalties to use it - if they liked you enough to let you use it in the first place (maybe I shouldn't have read Dvorak's column in PC Magazine recently...) -- Doug Sewell, Tech Support, Computer Center, Youngstown State University doug@cc.ysu.edu doug@ysub.bitnet !cc.ysu.edu!doug Barney the Dinosaur: Insipidus Rex -- anonymous Seen on a bumper sticker: I don't like President Clinton - or her husband. ------------------------------ From: rrw1000@cl.cam.ac.uk (Richard Watts) Subject: Re: Thought... Reply-To: rrw1000@hermes.cam.ac.uk Date: Wed, 17 Nov 1993 17:03:36 GMT In article <2cce58$5rh@rainbow.sosi.com>, aos@rainbow.sosi.com (Michael Aos) writes: |> I was just thinking.... |> |> scenario...two linux boxes w/sound cards, speakers, mic's and ethernet. |> |> Can I set up something so when I speak into my microphone it comes out |> the other guys speakers? Some sort of socket thing? You can, but it'd be a bugger to write - see later... |> |> I can digitize and play, which is OK, but I'm after something a little |> closer to "real-time". Audio doesn't have to be fancy. 8Khz mono for |> voice would be fine. .. this kind of thing requires real-time guaranteed network and OS performance. Fine - there are OSs and networks that will do this, and very nice they are too. Sadly UNIX isn't one of them, and neither is ethernet. It would be fairly (very?) simple to use udp (or possibly 'raw' ethernet sockets - I haven't used these - maybe someone would like to comment on their feasability) sockets to transfer the data, and (assuming the sound cards have a hardware buffer capable of holding preloaded data for a few jiffys - usually 50ths of a second, but I don't know what Linux uses) have a couple of programs to send and recieve information, but you'd have no guarantee that it'd work fast enough to provide reasonable performance. One interesting possibility is to hack the kernel so that your process runs along with the scheduler every jiffy (generally, UNIX kernel processes are nonpreemptable, so I assume Linux follows the trend ? please correct me if I'm wrong), but this would almost certainly involve some Deep Hacking that I've no idea how to do (and would slow your machine down something chronic, probably) ... |> |> Thanks, |> |> Mike |> -- |> [sig deleted] Richard. -- nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm [Ruler ^^^. -- blame xrn ] ------------------------------ From: soup@penrij.UUCP (John R. Campbell) Subject: Re: What's wrong with a DOS to Linux disk access? Date: 16 Nov 93 07:28:29 GMT matt@krikkit1.apana.org.au (Matt McLeod) writes: >John R. Campbell (soup@penrij.UUCP) wrote: >: OK, _which_ Linux FileSystem? MINIX? EXT? EXT2? XIAFS? It's >: really MUCH easier to access the DOS filesystem from Linux than >: any other direction. >EXT2 to start with, I'd have thought - most people are now using that, >aren't they? (Well, I know *I* am). I use Linux as my *primary* system, so, when I _need_ to run DOS (and I try to find ways _not_ to) I copy the files down and reboot into DOS. Since I boot from a floppy (my system at work has a pair of IDE drives and SCSI drives, DOS on the IDE primary, Linux on /dev/sda1) all I've gotta do is pop the floppy and shutdown, hit reset, and *THUNK*, there's DOS! Besides, backup of my DOS partition can be done across the network to the one machine that has a tape drive :-) WITHOUT requiring PC/NFS (which I am reluctant to install on my DOS disk since we've a limited number of licenses). >: Neither MS-DOG nor WINDOZE have a functional immune system. If you >: look up the term "security hole" the MS-DOG is second only to the >: Macintosh finder. >DOS is not perfect. True. But it isn't *that* bad. I've heard that there _is_ proof that Windoze is *NOT* a virus: Viruses DO something... Actually, someone else summed it up well: 1) UNIX and OS|2 qualify as Operating Systems 2) Windows is a User Shell 3) MS-DOS is a boot sector virus. Now consider- DOS is equivalent to the first generation OSes which were nothing more than I/O service libraries. It also (I don't care what you say about TSRs, they're an example of subversion) can only support 1 process (i.e. execution thread) at a time. I avoid DOS because I don't like to wait for my machine to be returned to me when I'm compiling or whatnot. On a _real_ OS I simply change to another virtual terminal and do something else. Of course, when I'm running X-Windows w/ Open Look, I've got 80X50 terminal windows which really helps when editing source code. (Having a 19-inch monitor does not hurt here, either). -- John R. Campbell soup%penrij@kd3bj.ampr.org or: uunet!kd3bj!penrij!soup ------------------------------ From: soup@penrij.UUCP (John R. Campbell) Subject: Re: 16550A handling in serial.c Date: 16 Nov 93 07:33:35 GMT koenig@ceres.tat.physik.uni-tuebingen.de (Harald Koenig) writes: >My interesst is not in performance or reliability. >I'm using a RS232 line to connect a radio clock receiver which sends >one character per second at 50 baud. To adjust the UNIX clock as exact as >possible it is important to know the exact time of the rising edge of the >signal (which is detected as start bit). with the current UARTs I only get >a resolution of 1.25 ms which isn't god enough. I suggest doing away with the UART completely (or, if needed, try this:) connect the RxD line (after conversion to TTL) to an IRQ pin; when the IRQ is hit, turn it off (after processing) and then turn it back on again when the character has been fully received by the UART. Sure, it wastes 2 IRQs, but you're already wasting one, eh? This way you get your "accurate" time tick. -- John R. Campbell soup%penrij@kd3bj.ampr.org or: uunet!kd3bj!penrij!soup ------------------------------ Crossposted-To: comp.os.linux.admin From: odonnell@mpx0.lampf.lanl.gov (J. M. O'Donnell) Subject: Re: Debugger wants libc source?! Date: Wed, 17 Nov 1993 16:46:00 GMT In article , thompson@indigo.cuug.ab.ca (Bruce Thompson 295-5967(w) or 229-3370(h)) writes... >In article <2be9at$p5m@fbi-news.informatik.uni-dortmund.de> muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes: > > Guten Tag! > > Unfortunately, while debugging various pieces of code, I really that my > debuggers -- gdb and ups -- demand the sources of libc when libc calls, > like printf or whatever, are reached. > > I can pass it by using "next" instead of "step"ping into the call. However, > it's not very comfortable. Moreover, I always get a disturbing little "beep" > for each call with a missing source. > > My libs are from image-4.4.1.tar.gz (or so) from the GCC directory on sunsite. > > So: what I am doing wrong? > > Thank you in advance! Any information will be appreciated! > > Holger Muenx (muenx@heike.informatik.uni-dortmund.de) > >What are you doing wrong? Nothing. The behavior you're describing is >correct, assuming that the libraries you are referring to were >compiled with debugging enabled. The debugger is assuming that since >you stepped into the library routines, you want to debug them. That >is, after all, what the step command is for. The debugger `should' >step completely over any routine that is not compiled for debugging >unless you specify to step to the next machine instruction. > >If you have the sources for libc, I'd recommend that you recompile >them without debugging, not to mention turning optimization on. If you >don't have the sources, I'd suggest looking into finding a libc that >is nott compiled with debugging on. > >In the mean time, here are a couple of things you can do once you've >stepped into a routine you don't have source for: > 1) Try the `continue -return' command (I think that's it). > Check the gdb manual for more info, but I believe there's > an option to continue that means continue until this > routine is exited. > > 2) Move up one stack frame and set a one time breakpoint on > the next line after the call you're currently in. > >Hope this helps some. I'd check my own system, but I don't yet have >it. > > Cheers, > Bruce. >-- >Bruce Thompson, |I do not speak for CUUG, ACTC Technologies, >Software Development Engineer,|Renegade Legion nor NAPRA, just myself. >ACTC Technologies Inc. |"So this is it, we're going to die!" >Renegade Legion, NAPRA #473 | -- Dent Arthur Dent >-- >Bruce Thompson, |I do not speak for CUUG, ACTC Technologies, >Software Development Engineer,|Renegade Legion nor NAPRA, just myself. >ACTC Technologies Inc. |"So this is it, we're going to die!" >Renegade Legion, NAPRA #473 | -- Dent Arthur Dent The libc-4.4.4 documentation says that if gcc is invoked with -g then it will link to a set of libraries with debugging on. I only installed 4.4.4 yesterday so I haven't played with this yet, but two posibilities come to mind: (1) do the compile only with -g, then invoke gcc again to link, (this does not need the -g flag so the normal libraries will be used). (2) specify the non-debugging libraries explicityl on the gcc command line. John. ------------------------------ From: andreas@knobel.knirsch.de (Andreas Klemm) Subject: Re: [Q] Big modem installation for Linux? Date: 17 Nov 1993 17:58:27 -0000 byron@cc.gatech.edu (Byron A Jeff) writes: >In article <2bo97j$lvs@belfort.daimi.aau.dk>, >Jesper Bach Larsen wrote: >> >>As headline says, I wan't to run a Unix installation, preferable Linux, as it >>is free, with multiple modem lines. By multiple I mean in the amount of >>30-50 modems. I suppose I will have to purchase somekind of hardware support >>for this project. My question is: what would be the most effective (measured >>in system-resources) installation? What kind of system-resource is required >>for this (particular RAM recomendations, special I/O interfaces etc.) >I'm presuming that you want to attach that many modems to 1 machine. For >multiple machines you can possibly use 4-6 networked machines with STB >4Ports such that each machine has 8 modems attached. [///] I'd suggest buying a Terminal server from Xyplex or Xylogic. I think the Xylogic ones are so called communication servers, which offer an option, that all ports have full modem control and RS-232 DB 25 connector. You can get those devices up to 16,32 or more ports. An additional advantage is, that those devices automatically understand slip and ppp. I never personally tried such an installation, but I think such a configuration is more stable than any other installation using so called intelligent multiport serial cards, that require special drivers .... -- Andreas Klemm /\/\____ Wiechers & Partner Datentechnik GmbH andreas@knobel.knirsch.de ___/\/\/ andreas@sunny.wup.de (Unix Support) ------------------------------ From: andreas@knobel.knirsch.de (Andreas Klemm) Subject: Re: Problem with Emacs/gdb/pl13. Date: 17 Nov 1993 17:47:59 -0000 eric@tantalus.nrl.navy.mil (Eric Youngdale) writes: > I have been noticing some kind of strange problem with pl13 that >involves debugging something with gdb under Emacs. The idea is that if the >program being debugged is running, and you type C-c C-z to interrupt it, >you end up hanging both the process running the application and the process >running gdb. Both of them end up in the TASK_STOPPED state. > I have no idea when this problem came up, but I know that it worked at >some point in the past. I was going to try and track this down, but I was >wondering whether someone else had seen this and knew what the problem was. > Emacs: 18.59 > gdb: 4.10 > libc: 4.4.1 > kernel pl13. Same here, Slackware: 1.1.0 emacs: 19.19 gdb: 4.10.pl1 kernel: pl13 original libc: 4.4.4 ps -axlww shows this: 0 0 5078 77 1 0 1317 1236 113aa5 S v01 0:01 emacs 0 0 5079 5078 1 0 1565 1052 114243 T pp0 0:00 /usr/bin/gdb -fullname /local/tmp/xxx 0 0 5068 1 1 0 28 12 1140f4 T ? 0:03 /local/tmp/xxx 10 0 5080 5079 1 0 28 12 1140f4 T pp0 0:03 /local/tmp/xxx 0 No way to suspend or interrupt the job. -- Andreas Klemm /\/\____ Wiechers & Partner Datentechnik GmbH andreas@knobel.knirsch.de ___/\/\/ andreas@sunny.wup.de (Unix Support) ------------------------------ From: eichin@cygnus.com (Mark Eichin) Subject: Re: Debugger wants libc source?! Date: 17 Nov 1993 13:00:41 -0500 In article , Bruce Thompson 295-5967(w) or 229-3370(h) wrote: >In article <2be9at$p5m@fbi-news.informatik.uni-dortmund.de> muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes: > Unfortunately, while debugging various pieces of code, I really that my > debuggers -- gdb and ups -- demand the sources of libc when libc calls, > like printf or whatever, are reached. > >If you have the sources for libc, I'd recommend that you recompile >them without debugging, not to mention turning optimization on. If you >don't have the sources, I'd suggest looking into finding a libc that >is nott compiled with debugging on. Well, actually, libc is compiled with gcc -- which, on all platforms, allows you to compile for debugging *and* optimization. (Last I checked, the Linux libc was built with -g -O6 :-) So compiling without debugging is only a loss of information, it doesn't gain you any optimization (unlike *most* [not all, though] commercial compilers.) >In the mean time, here are a couple of things you can do once you've >stepped into a routine you don't have source for: > 1) Try the `continue -return' command (I think that's it). The gdb command "finish" is probably what you meant. It certainly behaves that way. It then puts the return value from the function in the history (so you can refer to it as $27 or whatever...) As far as I can tell, continue only takes a numeric argument. > 2) Move up one stack frame and set a one time breakpoint on > the next line after the call you're currently in. GDB has a "tbreak" command if you decide to use this technique (for other reasons -- finish will do more of what you want.) tbreak sets a temporary breakpoint which evaporates when you hit it. Another, equally reasonable alternative, is to *get* the sources to libc. They're on sunsite and tsx-11 after all. (Somewhere. You can find them.) However, it sounds like you don't really care what's happenning in libc (I guess you haven't yet passed bad arguments to something and needed to get a stack trace from inside of libc somewhere. Then you'll be *happy* that libc has debugging symbols :-) I guess I'd suggest simply being more careful about your use of next vs. step. In most debugging, unless you've already got a particular crash point to work from, you'll want to do multiple runs with next to narrow down the problem area, only using step when you know you need to "dive deeper". (gdb has some conveniences, like user-definable aliases [and defaults of "n" for next and "s" for step] and if you hit return, you get the command to repeat [unless it's a "dangerous" one, though I forget how that's defined, but you've got the online manual so you can look it up :-)] that make this easy...) _Mark_ MIT Student Information Processing Board Cygnus Support ps. Just think, if this were proprietary software, I might need a disclaimer here :-) ------------------------------ From: sdw@meaddata.com (Stephen Williams) Crossposted-To: comp.os.linux.admin Subject: Re: Berkeley Fast Filesystem Date: 17 Nov 1993 18:58:49 GMT I'm afraid that I haven't closely examined the details of ext2 or the others, but I want to point out, while the topic is hot: Interactive Unix boosted performance of the SysV 1K filesystem 30% by just keeping the free block list in core as a bitmap. They flushed or invalidated it on the disk on unmount/crash. This had the effect of keeping a sorted freelist that was easy to allocate the largest contiguous set of blocks. Worked great, except that the first version took a while on large disks to mount/unmount, unless the disk was mostly full... Note that they still kept the safe inode freelist structure technically, just handled it differently internally. You could optimize memory by not having it on readonly mounts and only keeping a limited number of references (say the next N MB's worth of free blocks) in core and scanning the free list if you used those up. sdw -- Stephen D. Williams Local Internet Gateway Co.; SDW Systems 513 496-5223APager LIG dev./sales Internet: sdw@lig.net CIS 76244.210@compuserve.com OO R&D Source Dist. By Horse: 2464 Rosina Dr., Miamisburg, OH 45342-6430 GNU Support ICBM: 39 34N 85 15W I love it when a plan comes together ------------------------------ From: mrhoten@Xenon.Stanford.EDU (Matthew Rhoten) Subject: Re: STRLEN() == 3 ??!?? Date: 18 Nov 93 00:31:52 GMT wiserner@Informatik.TU-Muenchen.DE (Bernd Wiserner) writes: >Your environment SHOULD coredump. It should in no case return 3. >And not strlen should test for this, this is a general issue. >B.Wiserner. POSIX.1 says that one should not rely on what happens when one dereferences NULL. Undefined means, yes, undefined. It could "fork and exec tetris", to quote somebody or other. POSIX.1 also says that one should not rely on things like getting segmentation fault signals when one does things that are errors which might, on some architectures, signal a segmentation violation. Nor is strlen() required to check this stuff for you. I heartily recommend writing wrappers if you want to do this sort of checking in your software. In particular, Linux's memory code doesn't unmap page 0. This will, to my understanding, be changed in the future, by using a different executable format, again to my understanding - don't quote me. -matt -- Matthew Rhoten - his .signature, his opinions. mrhoten@cs.stanford.edu | mrhoten@eskimo.com | mattrh@microsoft.com "I'm not sure I remember HOW to sleep." -Dan Sommerfield ------------------------------ ** 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 ******************************