Subject: Linux-Development Digest #792
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:     Sat, 4 Jun 94 12:13:07 EDT

Linux-Development Digest #792, Volume #1          Sat, 4 Jun 94 12:13:07 EDT

Contents:
  Looking for mprotect() (David J. Hughes)
  Re: Need: MSDOS & ISO9660 filesystem source (Rene COUGNENC)
  Function key patch for X/linux (Gary Houston)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Bjorn Ekwall)
  Re: Frustrated with new kernels (Elaine Walton)
  Using 2 ethernet cards with DOSEMU (Andrew Anderson)
  Re: Frustrated with new k (Elaine Walton)
  Re: Busmouse on IRQ 2 works only with driver on IRQ 9 (H. Peter Anvin)
  Re: ps: SIZE < RSS??? (David Luyer)
  Re: Three-button mouse, again? (Yasu Hiro YAMAZAKI)
  Need: MSDOS & ISO9660 filesystem source (Cliff C Heyer)
  Process size limit (David Fox)
  Re: Relocatable Code Quandry (Michael K. Johnson)
  rudimentary tiff viewer code sought, reads directories (Alex Shrom)
  Re: Frustrated with new k (Steve Pershing)
  Re: Linux and realtime? (Nigel Gamble)
  Re: linux bug or HP bug? (with solution) (Nigel Gamble)
  Re: Legality of casting floats to shorts (Bruce Evans)

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

From: bambi@kirk.Bond.edu.au (David J. Hughes)
Subject: Looking for mprotect()
Date: 4 Jun 1994 17:46:32 +1000

Has anyone developed a working mprotect()?  As of the latest kernel,
it's still an empty function flagged as being unimplemented.  I need it
for a debugging library I use for tracking memory problems in my code.
I decided to offer Linux as a supported platform for my work and need
the debugging library to ease the porting process.

I'd prefer to find someone who's done this rather than start from scratch.
If there's been no work on it yet then I'll probably have to put one
together myself.


Thanks,


   ___                                  David J. Hughes    bambi@Bond.edu.au
  /   \                /  /    /        
 /  __/ __   __   ____/  /    / __            Senior Network Programmer
/    \ /  \ /  \ /   /  /    / /  \  /     Information Technology Services
\____/ \__//   / \__/   \___/ /   / /   Qld. 4229  AUSTRALIA  (+61 75 951450)

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

From: rene@renux.frmug.fr.net (Rene COUGNENC)
Subject: Re: Need: MSDOS & ISO9660 filesystem source
Date: 3 Jun 1994 00:40:21 GMT
Reply-To: cougnenc@hsc.fr.net (Rene COUGNENC)

Ce brave Cliff C Heyer ecrit:

> I have linux on many(!) floppy disks and have not
> loaded it yet. I think (?) you can mount MSDOS 
> partitions with it? Can this also be done with
> ISO9660? Is the source code within my disks of
> linux?

Yes.

And you might have a look at the articles on the comp.os.linux.* groups
before posting in the kernel development group... For example read the
message, posted daily (?), called "*** READ THIS BEFORE POSTING ***" :-)
--
 linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux 

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

Crossposted-To: comp.windows.x.i386unix
From: ghouston@actrix.gen.nz (Gary Houston)
Subject: Function key patch for X/linux
Date: Sat, 4 Jun 1994 08:02:48 GMT

The linux default console keymap sets up F1-F10 and F11-F20 (shifted).
This can be modified with the loadkeys utility to give F1-F12 and
F13-F24.  However under XFree86 2.1/2.1.1 the keysyms F21-F24 will never
be generated.  The following patch appears to fix the problem.

diff -c mit/server/ddx/x386/common/xf86_KbdLnx.c~ mit/server/ddx/x386
/common/xf86_KbdLnx.c 
*** mit/server/ddx/x386/common/xf86_KbdLnx.c~   Sat Jun  4 15:00:20 1994
--- mit/server/ddx/x386/common/xf86_KbdLnx.c    Sat Jun  4 14:21:20 1994
***************
*** 402,407 ****
--- 402,409 ----
        case KT_FN:
        if (kval <= 19)
          *k = XK_F1 + kval;
+       else if (kval >= 30 && kval <= 33)
+         *k = XK_F1 + kval - 10;
        else switch (kbe.kb_value)
        {
        case K_FIND:

The next patch gives the extra function keys some default string bindings
(which can also be done using X resources).

diff -c mit/clients/xterm/input.c~ mit/clients/xterm/input.c
*** mit/clients/xterm/input.c~  Thu Jun  2 23:59:05 1994
--- mit/clients/xterm/input.c   Sat Jun  4 14:41:28 1994
***************
*** 231,236 ****
--- 231,240 ----
                case XK_F18:    return(32);
                case XK_F19:    return(33);
                case XK_F20:    return(34);
+               case XK_F21:    return(35);
+               case XK_F22:    return(36);
+               case XK_F23:    return(37);
+               case XK_F24:    return(38);
  
                case XK_Find :  return(1);
                case XK_Insert: return(2);


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

From: bj0rn@blox.se (Bjorn Ekwall)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: 4 Jun 94 13:09:28 GMT

Kevin Lentin (kevinl@bruce.cs.monash.edu.au) wrote:
...
 > I find this a bit weird. It would be real strange to be developping a kernel
 > with a version lower than the stable one. To be developping 1.1.x while
 > 1.2.x is out is wrong. And what happens when 1.1.x is declared stable? Make
 > it 1.4.0 and then the next kernel after 1.4.0 is  1.4.1 for the stable ones
 > and 1.3.0 for a new feature. It would cause far more confusion than there
 > is now.

It's not that strange... nor wrong!  If one sees the version number as
an indication for how useful the release would be for users in general,
this new scheme would be perfectly logical, IMHO.
The developers won't be confused, I promise! I mean, what's so magic about
a number?  We are talking about two different types of releases, that just
by coincidence happen to be numbered sequentailly...

 > And further, if people are resourceful enough to find all the different
 > kernels and post to news asking questions then they certainly should have
 > the resources to get the answer to the question very easily.

In a perfect world... we would all be Linus... :-)

 > -- 
 > [==================================================================]
 > [ Kevin Lentin                   |___/~\__/~\___/~~~~\__/~\__/~\_| ]
 > [ kevinl@bruce.cs.monash.edu.au  |___/~\/~\_____/~\______/~\/~\__| ]
 > [ Macintrash: 'Just say NO!'     |___/~\__/~\___/~~~~\____/~~\___| ]
 > [==================================================================]

Bjorn Ekwall == bj0rn@blox.se

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

From: ewalton@magnus.acs.ohio-state.edu (Elaine Walton)
Subject: Re: Frustrated with new kernels
Date: 2 Jun 1994 23:21:41 GMT

I appreciate your dissertation, and I agree that there are certain things
which unreasonable to expect from a free system.  However, I would like to
know the external dependencies if any--a very good programming practice.
Also, one typically expects that when he/she downloads a package that is
supposed to work on an existing system (with no external dependencies
mentioned) will work.  While I have worked on millions of lines of code
of other people's code in my career, I typically have the tools to get
things going--documentation.  Now, I realize that this is not possible
with Linux.  Still, do you think that it would be so hard to compile a
package before gzip'ing it?
-Sean

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

From: andersoa@news.db.erau.edu (Andrew Anderson)
Crossposted-To: comp.os.linux.admin
Subject: Using 2 ethernet cards with DOSEMU
Date: 2 Jun 1994 23:28:03 GMT

I'm trying to configure a linux box to act as a telnet responder for a 
Novell server.  I'm running Slackware 1.0.8 and DOSEMU 0.50pl1.  I can 
get one dos session to work just fine, but if I try to run 2 dos sessions,
I get a security breach on the Novell side, since netx can't handle 2 
sessions from the same ethernet address.  So I installed another ethernet 
card, and I'm trying to get DOSEMU to work with a device other than eth0.  

I already found the references to eth0 in the dosemu source code, but 
after re-compiling, it still refuses to use anything other than eth0.  
I know both cards are operational under plain linux, so it has something 
to do with the way DOSEMU is accessing them.  Can anyone yield some 
insight into what's happening here?  Or at least give me a few more 
ideas to try?

Thanks, 
Andrew

--
|===========================================================================|
|              Andrew Anderson (andersoa@erau.db.erau.edu)                  |
|===========================================================================|
|  Far better it is to dare mighty things, to win glorious triumphs, even   |
|  though checkered by failure, than to take rank with those poor spirits   |
|  who neither enjoy much nor suffer much, because they live in the grey    |
|  twilight that knows not victory nor defeat. -- Theodore Roosevelt        |
|===========================================================================|
|  There is no system problem that can't be solved by deleting files and    |
|  removing users. -- B.O.F.H.                                              |
|===========================================================================|

--
|===========================================================================|
|              Andrew Anderson (andersoa@erau.db.erau.edu)                  |
|===========================================================================|
|  Far better it is to dare mighty things, to win glorious triumphs, even   |
|  though checkered by failure, than to take rank with those poor spirits   |
|  who neither enjoy much nor suffer much, because they live in the grey    |
|  twilight that knows not victory nor defeat. -- Theodore Roosevelt        |
|===========================================================================|
|  There is no system problem that can't be solved by deleting files and    |
|  removing users. -- B.O.F.H.                                              |
|===========================================================================|

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

From: ewalton@magnus.acs.ohio-state.edu (Elaine Walton)
Subject: Re: Frustrated with new k
Date: 2 Jun 1994 23:37:53 GMT

>The developers have no obligation to meet anyone else's demands,
>although they often do so because they are such sterling folk. These
>are the conditions under which Linux has thrived: don't spoil them.
>
> Steve

I never asked for something perfect, and I doubt that others are requiring
the same thing.  In fact, I am just trying to see what the bleeding edge
has.  I am and always will be a researcher--in other words, I expect a
certain amount of unpredictability.

What I wanted was someone considerate enough to compile a package BEFORE
gzip'ing it into a package.  I know that these altruistic developers are
doing this on their own time--and I am truly grateful.  However, if they
want other developers--like myself, I suggest that a minimum set of
requirements be met before making it public.  Compilability comes to mind.
I mean, how am I supposed to test the work if I can't run it.

Two messages ago on this thread, I complained in frustration.  The first
to censure me said something truly helpful: "where's the detail?".  Yes,
this is very important, but I supplied that detail TWO WEEKS AGO.  Where
was he then???

Someone posted a message saying that the answer to my problem is to set
DDIOCSDBG to 0x9000 in sbpcd.c.  Cool.  I can do that.  Then he says that
a better solution is to use patch14?  I think I mentioned that I did that.

I am sorry for the diction here.  I just want to help and am very
frustrated because I can't.

-Sean

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

From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin)
Subject: Re: Busmouse on IRQ 2 works only with driver on IRQ 9
Reply-To: hpa@nwu.edu (H. Peter Anvin)
Date: Thu, 2 Jun 1994 23:30:12 GMT

Followup to:  <klaus.472.2DED8D29@mail.sz.etc.tu-bs.de>
By author:    klaus@mail.sz.etc.tu-bs.de (Klaus Troja)
In newsgroup: comp.os.linux.development
>
> Hi there!
> 
> I have got an ATI Bus Mous on a Graphics Vantage. The driver sources for bus 
> mice are set for IRQ 5. I changed them to IRQ 2 without success.
> You have to set it to IRQ 9 in the driver to get the mouse working.
> Because of  
> the cascaded two Interrupt Controllers IRQ 2 on the first refers to IRQ 9 on 
> the second controller which is asked first.
> 

The hardware line IRQ 2 is wired to IRQ 9 since IRQ 2 is occupied.
However, under MS-LOSS the BIOS hides this by invoking the IRQ 2
handler when IRQ 9 is received.  Not so under Linux, although many of
the drivers seem to check for that.

        /hpa
-- 
INTERNET: hpa@nwu.edu               FINGER/TALK: hpa@ahab.eecs.nwu.edu
IBM MAIL: I0050052 at IBMMAIL       HAM RADIO:   N9ITP or SM4TKN
FIDONET:  1:115/511 or 1:115/512    STORMNET:    181:294/101
#include <stdquote.h>

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

From: luyer@tartarus.uwa.edu.au (David Luyer)
Subject: Re: ps: SIZE < RSS???
Date: 4 Jun 1994 13:39:20 GMT

David Fox (fox@graphics.cs.nyu.edu) wrote:
: David Fox writes:

: ] The man page for ps says that 
: ] 
: ]        SIZE virtual image size, size of text+data+stack
: ] 
: ]        RSS  resident set size, kilobytes of program in memory.
: ] 
: ] It would seem that SIZE would always be >= RSS, yet
: ] 
: ] USER       PID %CPU %MEM SIZE  RSS TTY STAT START   TIME COMMAND
: ] root        21  0.0  0.3   12   52  ?  S   Jun  2   0:02 update (bdflush)
: ] fox      14680  2.2  2.3  197  348 pp4 S    14:11   0:01 make -k
: ] fox      14787  0.2  1.5  102  228 pp4 S    14:11   0:00 gcc -c text.C -g -DX
: ] 
: ] How is this possible?

: Oops, I forgot about the heap.  I have cancelled the original
: article.
: --
: David Fox                                             xoF divaD
: NYU Media Research Lab                           baL hcraeseR aideM UYN

Yes, someone please reply to this.  I know that it happens on SunOS
and ULTRIX too, and it is seems to me totally illogical `,-^>
--
........................................................................

"Apples have been a problem ever since Eden."

"Electrons are tiny little particles you can only see if you have been
 drinking."

luyer@lethe.uwa.edu.au

.............................................................David Luyer

>>>>>>>>>>>> This message made from 100% recycled electrons <<<<<<<<<<<<

........................................................................

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

From: hiro@ice3.ori.u-tokyo.ac.jp (Yasu Hiro YAMAZAKI)
Subject: Re: Three-button mouse, again?
Date: 2 Jun 1994 23:51:46 GMT

Hi Linuxers,

> Thank you to all who wrote about the dual-protocol mouse configuration for
> X.

Have you ever tried specifying "cleardtr" option in you Xconfig ?
It might solve the problem.

--
================================== Yasu Hiro Yamazaki   _______      _/\_
   /  /                   hiro@ice3.ori.u-tokyo.ac.jp  |   _   | _/\_>  <_/\_
  __ /  /  , \ , \   hiro@rainbow.physics.utoronto.ca  |  (_)  | >          <
_/ _/ _/ _/_<  __/ Dept. of Physics, Univ. of Toronto  |_______| `----||----'

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

From: cliffhanger@cup.portal.com (Cliff C Heyer)
Subject: Need: MSDOS & ISO9660 filesystem source
Date: Thu,  2 Jun 94 16:23:09 PDT

I have linux on many(!) floppy disks and have not
loaded it yet. I think (?) you can mount MSDOS 
partitions with it? Can this also be done with
ISO9660? Is the source code within my disks of
linux?

Cliff

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

From: fox@graphics.cs.nyu.edu (David Fox)
Subject: Process size limit
Date: 04 Jun 1994 12:57:43 GMT

The program below attempts to calloc as much memory as possible.
I find it can only allocate about 8 Meg no matter how much swap
space is installed on my machine, and I have 16 Meg of RAM.
Is this a Linux limit?  Under SunOS it went on merrily allocating
until it died a horrible swap death.  I'm asking because the
netpbm programs allocate and write into huge blocks of memory
expecting the virtual memory system to cope, but for medium/large
images it can't.

#include <stdio.h>
#include <stdlib.h>

main()
{
  int chunk = 1000000;
  int n = 0;
  void *p = 0;
  while (chunk) {
    p = calloc(1, chunk);
    if (p)
      fprintf(stderr, "%d byte chunk #%d: %x\n", chunk, ++n, p);
    else
      chunk /= 2;
  }
  system("ps aux");
}
--
David Fox                                               xoF divaD
NYU Media Research Lab                     baL hcraeseR aideM UYN

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

From: johnsonm@merengue.oit.unc.edu (Michael K. Johnson)
Subject: Re: Relocatable Code Quandry
Date: 04 Jun 1994 14:24:02 GMT


In article <MJS.94Jun3153135@jackson.neurology.wisc.edu> mjs@jackson.neurology.wisc.edu (Michael Schmelzer) writes:

   While trying to build InterViews, I came upon an
   interesting paradox: To build shared libraries, you
   need to generate position independent code, and
   although GCC can emit position independent code,
   the Gnu assembler can't handle it. (The gcc info file
   even admits as much!)

   What's going on? Aren't shared libraries a keystone of Linux?
   I see .sa files all over the place. 
   And isn't PIC a prerequisite to build a shared library?
   If yes and yes, then how was the PIC assembled?

There are special tools for building Linux shared libraries available
at tsx-11.mit.edu:/pub/linux/packages/GCC/src/tools-2.11.tar.gz
Those tools come with good documentation.

These tools re-write assembly code to allow shared libraries with the
minimum of overhead between gcc and gas.  The shared libraries are
loaded at fixed addresses, and the entry points are fixed even between
library versions.  They aren't PIC, but have enough indirection to
work as shared libraries.  PIC code is significantly slower than fixed
code (at least according to the benchmarks I've seen, and it makes
sense that it would be slower), so although the Linux shared libraries
aren't as easy to build as other shared libraries, they are probably
significantly faster.

michaelkjohnson

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

From: alex@anat3d1.anatomy.upenn.edu (Alex Shrom)
Subject: rudimentary tiff viewer code sought, reads directories
Date: 4 Jun 1994 15:06:37 GMT

I'm looking for a tiff viewer that works under X for linux and can
read tiff directories, display them, etc. Could anyone point me to a
good source with appropriate libraries? I may have found one, but I
can't find the XawVen.so.2.0 lib anywhere on sunsite. Any ideas,
suggestions appreciated.



-- 

Alex 'Shroom (alex@anat3d1.anatomy.upenn.edu)

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

From: sp@questor.org (Steve Pershing)
Subject: Re: Frustrated with new k
Date: Thu, 02 Jun 94 18:44:53 PDT

janne@avocado.pc.helsinki.fi (Janne Sinkkonen) writes:

=> as I'm able to. Now we have 1.1.17 in all three machines because it
=> has better SLIP support & better buffer caching. It is stable enough.

That may be true at your site, but here any of the kernels after 1.0.9
cause great grief with my SCSI HDrive (on an adaptec 1542A).  As soon
as I try to gunzip a file or anything else, the whole system locks up
and I have to do a *manual* e2fsck --this is up to and including 1.1.18.

So for now, I am happy with 1.0.9.
======  FREE ACCESS TO E=MAIL & NEWS via ZyXEL=1496+ Voice/Data/FAX  ======
THE QUESTOR PROJECT    -o-   Steve Pershing, SysAdm    -o-   sp@questor.org
Post Office Box 961, Pt. Roberts, WA 98281 USA  Voice Fone: +1 604 687 4777
Info about QUESTOR at:  mail-server@questor.org    FAX Fone:       687 5679
===== Info on Environment Science, Medicine, AIDS, NativeNet & more.  =====



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

From: nigel@gate.net (Nigel Gamble)
Subject: Re: Linux and realtime?
Date: Sat, 4 Jun 1994 14:59:35 GMT
Reply-To: nigel@gate.net (Nigel Gamble)

In <1994Jun2.213359.2193@alw.nih.gov> art@lsr.nei.nih.gov (Art Hays) writes:
>I would like to correspond with anyone who is using or enhancing 
>Linux for realtime.  My area of need is for a user routine to 
>attach to an interrupt, and have a guaranteed latency.  I modified a 
>pdp11 kernel to do this, and am interested in whether
>anyone has attempted this for Linux.

Attaching a user routine to an interrupt is a relatively easy problem,
and could, no doubt, be done in Linux without much difficulty.  It is
the requirement for guaranteed latency that is the hard problem.  Here
is a copy of a posting I made a while ago when Linux and real-time
was being discussed, about the problems of guaranteeing latencies in
UNIX operating systems:

>Newsgroups: comp.os.linux
>Path: gamble!nigel
>From: nigel@gamble.uucp (Nigel Gamble)
>Subject: Re: real time
>References: <1993Jan3.054159.11008@umr.edu>
>Organization: Nigel Gamble, Consultant
>Date: Sun, 3 Jan 1993 11:45:51 GMT
>Message-ID: <C0A0oG.Iy@gamble.uucp>

In <1993Jan3.054159.11008@umr.edu> quandt@cs.umr.edu (Brian Quandt) writes:
>What can anyone say about linux and real time support?  Same
>question applies to 386bsd.  I tend to believe that this concept
>would not be possible.  The reason being is that this (I believe)
>is a fundamental design change in how the kernal works.

Linux, in common with other traditional UN*X implementations will not
support real time applications.  Real time UN*X does need a fundamental
design change in the kernel, usually referred to as a `fully preemptible'
or `fully semaphored' kernel.  There are two main issues to consider:
interrupt handling and process context switching.

Real time processes tend to be interrupt driven; they spend most of
their time asleep, but when the external device they are controlling
sends an interrupt, it is essential that they can be woken up to
deal with the device within the designed time constraints of the
system, e.g. `within 100 microseconds'.  When the interrupt occurs,
the computer may be in the interrupt routine of some other device
with interrupts disabled.  The interrupt routine cannot even begin
to execute until interrupts are enabled again.  This has to be taken
into consideration in the design of every device driver in the system.
It is usual to have a design rule for interrupt handlers specifying the
maximum time that they are allowed to run with interrupts disabled.
This will typically be of the order of 100 microseconds.  If just one
device breaks this rule, you have not got a real time system.

When the interrupt routine gets to run, it needs to wake up the user
process and schedule it to run *now*.  The context of the currently
executing process (if of lower priority) is saved and the new process
is given the CPU.  So a context switch is forced, even if the current
process is executing in the kernel.  In Linux all that the interrupt routine
can do to wake up the new process is to mark it as runnable.  If the
currently running process is executing a system call in the kernel, the
new process must wait until the current process either completes the system
call, or voluntarily calls sleep() or shedule().  Otherwise kernel data
structures may be corrupted, since this is the way that they are protected
in a traditional kernel design.

A real time fully preemptible kernel design allows multiple processes
to be executing in kernel mode simultaneously.  On a uniprocessor this
means logically simultaneously, but on a multiprocessor system this
means *actually* simultaneously.  (It is interesting that the design
needed for a good real time system also gives you the basis for a good
multiprocessor system).  This is acheived by protecting the critical
regions of kernel code with kernel semaphores.  The critical regions
must be kept as short as possible; this is another design parameter.
Now the wake_up() call (which is implemented as a semaphore signal
operation) can actually cause a context switch to the new process
without waiting for the current process to decide to call sleep()
or schedule().  This, again, should typically take not more than
100 microseconds.

Assuming that the design rules are followed by the kernel *and all of
the device drivers*, you can predict the worst case time from the
initial interrupt through the interrupt handler, through the context
switch, to the first user level instruction of the new (assuming highest
priority) process, typically 300 microseconds.  If this worst case time
is good enough for your application, you have a real time system.

Cheers,
Nigel
--
Nigel Gamble                                    nigel@gate.net
Boca Raton, FL, USA.

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

From: nigel@gate.net (Nigel Gamble)
Subject: Re: linux bug or HP bug? (with solution)
Date: Sat, 4 Jun 1994 15:21:50 GMT
Reply-To: nigel@gate.net (Nigel Gamble)

In <2snbej$q76@sun0.urz.uni-heidelberg.de> fc4@aixfile1.urz.uni-heidelberg.de (Peter Parzer) writes:
>I had the problem that the lp driver would not recognize if my
>HP LaserJet 4p was power off. I solved this problem, at least for
>the polled version of the driver. The key of the problem was that
>the printer returned as state 0x87 when power off (state means
>the result of LP_S(minor)). The linux lp driver takes this as OK
>and assumes that the char was printed. I dont know if this is a bug
>in the lp driver or if this is a problem with HP since I have no
>idea about the official specifications of line printers.

>Another curious thing is that my HP deskjet 550c somtimes returns
>0x87 and sometimes returns 0x4f (line-off) when power-off.

There isn't a general solution to this problem since, as you have
noticed, the status is undefined when the printer is powered off.
I suggest that you keep the printer powered on whenever anyone is
likely to be printing.

Cheers,
Nigel
--
Nigel Gamble                                    nigel@gate.net
Boca Raton, FL, USA.

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

From: bde@kralizec.zeta.org.au (Bruce Evans)
Subject: Re: Legality of casting floats to shorts
Date: 5 Jun 1994 01:41:40 +1000

In article <FOX.94Jun3150453@first.cs.nyu.edu>,
David Fox <fox@graphics.cs.nyu.edu> wrote:
>The gdb command
>
> print (short)-1.49605799e+34
>
>or 
>
> print (short)3e9
>
>which casts a large negative float to a short, gives the message
>"Erronious Arithmetic Operation" or something very similar.  Of

(short)3e9 overflows, so the result of it is not defined by the
C standard.  gdb should attempt to produce exactly the same result
as would evaluating the statement in the program.  On i386/i387
systems, the result depends on the current i387 exception mask
and perhaps on the current i387 rounding mode and precision.

>that a program that executes it is incorrect.  However, this is an
>operation which is giving me floating point exceptions in programs
>which run fine on SPARCs and SGIs.  I suppose this a property of the
>i486 and there is no way to change the behavior, right?  Oddly,

Wrong.  It is a property of the linux library that certain i387
exceptions are unmasked by default unless you compile with certain
nonstandard CFLAGS.

>"print (short)1e9" executes without error, I guess because 1e9
>fits in an int.

gdb must not be trying very hard to produce the same result as the
program.  It seems to be doing (short)(int)3e9.  An overflow occurs
when the int is converted to a short.  The result is implementation
defined.  Very few systems trap on integer overflow.  Linux on the
i386 certainly doesn't.  I haven't seen the fine print where it
defines what it does :-).
-- 
Bruce Evans  bde@kralizec.zeta.org.au

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


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