Subject: Linux-Development Digest #220
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sat, 24 Sep 94 12:13:05 EDT

Linux-Development Digest #220, Volume #2         Sat, 24 Sep 94 12:13:05 EDT

Contents:
  Re: Status of Mac Linux & PPC Linux? (msouth on BIX)
  Re: Linux on Pentium P90 PCI---which motherboard? (Gus P Ikonomopoulos)
  Pascal for Linux?? (williams)
  Re: AX25 & KISS Amateur Radio Protocols in Linux?? (Josh Templin)
  The ELF/PIC performance measurement. (H.J. Lu)
  Re: A badly missed feature in gcc (Matt Day)
  Re: Linux v1.0 SMAIL problem (Bill Wiest)
  Re: File locking--gurus please read. :) (Matthias Urlichs)
  Re: queue_glue: no memory for gluing queue in 1.1.50 (Matthias Urlichs)
  Re: General Linux Development (Matthias Urlichs)
  Re: memory leakage in 1.1.51 ? (FIX) (Richard L. Goerwitz)
  Re: Alpha Linux (Andrew Bulhak)
  Try this IPX bridging code ... (Vinod G Kulkarni)
  Re: 1+ Gig SCSI Drives (Harald Milz)
  Re: Alpha Linux (Andrew Bulhak)
  Re: Alpha Linux (Andrew Bulhak)
  Re: Alpha Linux (Andrew Bulhak)
  Re: Alpha Linux (Andrew Bulhak)

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

From: [email-masked] (msouth on BIX)
Crossposted-To: comp.os.linux.help
Subject: Re: Status of Mac Linux & PPC Linux?
Date: 20 Sep 94 05:23:42 GMT

(get info about mac hardware)

Two problems:  1)  Apple documentation is intended for programmers
writing for the Mac OS, or manufacturers adding additional hardware.
2)  There are a *lot* of variations.  Unlike the PC world,
standardization is in OS software, not hardware.

Example:  Hardware reference manual for IIsi says, in effect,
that 'the ADB ports are different from original Mac II, and
any software that talks to it directly probabally won't work.'  Not
explained is _how_ it's different.

======================================================
Mike South

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

From: [email-masked] (Gus P Ikonomopoulos)
Crossposted-To: comp.os.linux.misc
Subject: Re: Linux on Pentium P90 PCI---which motherboard?
Date: 24 Sep 1994 03:25:31 GMT

[email-masked] (Vaughan R. Pratt) writes:

>If Linux runs on your Pentium P90 PCI, or you know of a working such,
>I'd appreciate knowing what motherboard did the trick.
>-- 
>Vaughan Pratt                  http://boole.stanford.edu/boole.html

        I have linux running on an AMI Atlas VIP motherboard with a 90MHz
Pentium.  I also have an ATI Graphics Pro Turbo (Mach64), NE2000 (Novell-
Mycrodyne), and a Sound Blaster 16 ASP.  It works great.

        I also have an Adaptec 2940 (Fast SCSI-2) controller card with
a Fast SCSI-2 hard drive.  Linux does NOT recognize it.  I have borrowed
my friends IDE hard drive temporarily.  I am hoping a driver will be out
soon.

Gus
[email-masked]

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

From: [email-masked] (williams)
Subject: Pascal for Linux??
Date: 20 Sep 1994 05:58:57 GMT

   I was wondering if anyone knows of a Pascal compiler that is available
for Linux.. Please give me a pointer. Thanks!
                --Zach

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

From: [email-masked] (Josh Templin)
Subject: Re: AX25 & KISS Amateur Radio Protocols in Linux??
Date: 23 Sep 1994 21:32:22 GMT

Vassili Leonov ([email-masked]) wrote:
: :     portion of the spectrum utilised.   I shudder to ask your opinion of
: :     CW.   
: Well - at least I managed to pass 13 wpm test - ulike you...

        That is a VERY low blow.  Everyone worked hard for their license, 
and I would NEVER criticize someone on the level of their ticket.  A 
ticket is an honor..at any level and NO ONE deserves to be put down!

: :     Not to mention that I've never seen a project run by any government
: :     that could be managed more efficiently and cost-effectively than
: :     one in a competitive private sector!   
: What about GNU and Linux for that matter? I would not say it's run by
: the Government - but not by the private sector either.

        Then who is it run by?  (Some guy named Earl? -- j/k)
        Linus still holds the copyleft...he's in the private sector, right?

: :     WRONG!  A lot of traffic that you enjoy goes through commercial
: :     providers at some point or another.  Face it, were it not for
: And if it would go by free channels - it would be cheaper. That's it.

        But who's going to buy the equipment?  Who's going to run it?  
Take care of it? It's difficult for me to justify working all day keeping 
up a network for free...I couldn't pay my bills that way!  And that why I 
believe our local network changes so often..if something breaks down, 
it's too bad until the person can spare enough cash to get it fixed!
(One of our local backbone forwarders [KB9AMY.#NOWI.WI.USA.NA] went down 
to lightning a few months ago.  Things still aren't right with that 
section of the network...)  You would not see this problem in commercial 
systems...they have to be stable, or no one would use them.

: :             a) your can figure out how to do it for no cost.
: If allowed I would pay my share. A few $K would be OK. But then
: I'm FREE. And nobody can STEP ON me one day. Makes a BIG difference.

        What are you going to do when you have to upgrade?  You can't 
really expect a lifetime of usage from a few $k...nothing lasts forever!

: :             b) you don't steal bandwidth from Amateur Radio... we
: :                already lost 11 meters to "public use" and look what
: :                that got us!  There are already enough well-funded
: Amazing GREED! Tune to 10 meters - in regular days - how many
: channels are used there (2MHz of spectrum)?. You're lucky if 2-3 of them.
: Then  tune CB (11m - 0.65MHZ spectrum). 

        Oh please!  You can't make that comparison!  There are so many 
other factors...(not in any order)

        #1:     Cost of equipment
                11m stuff can be bought for 50 bucks!  Where are you 
                going to find a new commercial ham radio for $50?

        #2:     Band condx
                11m is designed for LOCAL use...and that's pretty constant.
                But when we hams want to communmunicate around the world 
                on 10m we have to deal with band conditions, sun spots, 
                and a myrid of other factors!

        #3:     Liscensing requirement of AR
                The need for a ticket does not allow someone to walk into 
                a radio store, buy equipment, and get on the air.
 
 : Most channels are used. So - that WAS very fare.  Use it or 
LOSE IT!

        True, but be reasonable!  

: :     What's your call sign, Vassili???
: You can find it in the callbook...
I don't have one...otherwise I'd try looking it up...

Josh

--
= jtemplin is Josh Templin (KB9ENE)                    [email-masked] =
= "Microsoft is not a role model.  They're not even human.  Some of the      =
=  things they do would cause a person to get hurt, expelled, arrested, or   =
=  possibly deported.  To put it another way: don't try DOS at home."  -JT   =

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

From: [email-masked] (H.J. Lu)
Subject: The ELF/PIC performance measurement.
Date: 22 Sep 1994 21:52:27 GMT

I did an ELF/PIC performance measurement with gcc on a 486DX2/66 with
16MB RAM and no external cache.

1. Compiler A is gcc 2.6.0-940917 configured as i486-linuxelf and
   linked with the ELF/PIC version of the Linux C 4.6.10. The assembler
   is linked with the ELF/PIC version of the Linux C 4.6.10 as well as
   the ELF/PIC version of libbfd.

2. Compiler B is gcc 2.6.0-940917 configured as i486-linux and linked
   with the a.out/DLL version of the Linux C 4.6.10. The assembler
   is linked with the a.out/DLL version of the Linux C 4.6.10 only.

Compiler A and Compiler B use the same linker which is linked with the
ELF/PIC version of the Linux C 4.6.10 as well as the ELF/PIC version
of libbfd.

While compiling c-torture 1.29.1 which contains 634 testing cases,
simultaneously, the timing for compiler A is:

4631.12user 5497.17system 5:33:35elapsed 50%CPU(0avgtext+0avgdata0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps

The timing for compiler B is:

4740.34user 4963.42system 5:28:24elapsed 49%CPU(0avgtext+0avgdata0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps

Compiler A is less than 5% slower than compiler B. If that can hold for
other cases, which may well be true, I think we are in very good shape
with ELF/PIC.

H.J.
09/22/94

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

From: [email-masked] (Matt Day)
Subject: Re: A badly missed feature in gcc
Date: Sat, 24 Sep 1994 13:17:08 GMT

In article <[email-masked]> [email-masked] (H. Peter Anvin) writes:
>Followup to:  <[email-masked]>
>By author:    [email-masked] (H. Peter Anvin)
>In newsgroup: comp.os.linux.development
>> 
>> Append to the line immediately following it:
>> 
>> %{!ansi:-lang-c++ %{c:-U__cplusplus}}
>                    ^^^^^^^^^^^^^^^^^^
>
>Actually this turns out to be both redundant and incorrect.  The best,
>thus, I have managed to come up with is:
>
>%{!ansi:-lang-c++}
>
>This should work as long as there are no files in the C++ include
>directories that conflict with any in the C include directories.  I
>haven't still figured out how to get it to properly pass the
>-nostdinc++ flag if you are not compiling a C++ program.  Nothing I
>have tried has worked properly, so it is probably best to leave it
>out.

If it's just // style comments you want, use the -lang-c-c++-comments
option to cpp, specified in the specs file like above.  That turns on
// handling only.

A while ago, I mentioned to the gcc2 list about the need for an
all-purpose way to pass arguments to the various compiler pass programs
from the gcc command line, but I don't believe such a feature can be
expected in 2.6.  :-(  So for now, we have to edit the specs file.

Matt Day <[email-masked]>

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

From: [email-masked] (Bill Wiest)
Crossposted-To: comp.os.linux.admin,comp.os.linux.misc,comp.os.linux.p
Subject: Re: Linux v1.0 SMAIL problem
Date: Tue, 20 Sep 94 01:16:01 EDT
Reply-To: [email-masked] (Bill Wiest)

[email-masked] (root) writes:

> Phil Homewood ([email-masked]) wrote:
> : Mihail S. Iotov ([email-masked]) wrote:
> 
> : : The easiest way out is to install uucp, then smail will call uuname to
> : : find out that the mail is not going to one of your uucp_neighbours and 
> 
> 
> : An even better solution still os go and get sendmail 8.6. 
> : Why have everything forward off through a smart host when it can get
> : to its destination directly anyway? (OK, I know smail can be
> : configured... but it's a pain to get it to send out un-munged headers
> : and such anyway...)
> 
> Any anyone direct me to sendmail 8.6 ?
> 
> Thanks.
> 
> 
I believe you can find at ftp.cs.berkeley.edu:/ucb/sendmail

--Bill Wiest

+-----------------------------------+-----------------------------------+
| Internet    : [email-masked] | "You don't understand a thing     |
| CompuServe  : 70662,3311          | until you know its causes."       |
|                                   |             -- Aristotle          |
+-----------------------------------+-----------------------------------+

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

From: [email-masked] (Matthias Urlichs)
Subject: Re: File locking--gurus please read. :)
Date: 20 Sep 1994 05:37:44 +0200

In comp.os.linux.development, article <[email-masked]>,
  [email-masked] (Willis Boyce) writes:
> 
> Unfortunately, the Linux 1.1.8 that I am running apparently doesn't 
> support deadlock detection.  Indeed, there is even a comment in flock.c 
> to that effect.  Anybody who has ever used a heavily-loaded DBMS 
> knows that deadlock detection is not something that can be done without; 
> therefore, I would like to add it.
> 
So upgrade to 1.1.51; it's in there.

-- 
You will meet your perfect mate today.  Congratulations!  It's yourself.
-- 
Matthias Urlichs        \ XLink-POP Nürnberg  | EMail: [email-masked]
Schleiermacherstraße 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42
          PGP: 1B 89 E2 1C 43 EA 80 44  15 D2 29 CF C6 C7 E0 DE 
      Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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

From: [email-masked] (Matthias Urlichs)
Subject: Re: queue_glue: no memory for gluing queue in 1.1.50
Date: 20 Sep 1994 05:51:27 +0200

In comp.os.linux.development, article <[email-masked]>,
  [email-masked] (Alan Cox) writes:
> In article <[email-masked]> [email-masked] (Amrik Thethi) writes:
> >One thing you could try is to mount the NFS directories with an 'rsize'
> >of 1024 or 4096 ( anything less than a mem page ). This may make life
> >easier for the IP fragment assembly code, and thereby prevent the 
> >problem. No guarentees tho'
> 
> That is by far the best way of doing it - but has a speed cost thanks to the
> SunOS I/O  & VM subsystems.

That's a problem when writing. On the other hand, the big-packet problem
shows up only when reading, so rsize=2048 and wsize=8192 should get us the
best of both worlds. Sort of.

-- 
Isn't this my STOP?!
                -- Zippy the Pinhead
-- 
Matthias Urlichs        \ XLink-POP Nürnberg  | EMail: [email-masked]
Schleiermacherstraße 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42
          PGP: 1B 89 E2 1C 43 EA 80 44  15 D2 29 CF C6 C7 E0 DE 
      Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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

From: [email-masked] (Matthias Urlichs)
Subject: Re: General Linux Development
Date: 20 Sep 1994 06:13:32 +0200

In comp.os.linux.development, article <[email-masked]>,
  [email-masked] writes:
> 
> Any other specific improvements you had in mind, while we are at it...
> 
Don't forget to replace the SIGALRM handling. (Right now the kernel
decrements the counters when it walks the process queue every timer tick.)

I already have (somewhat ugly) patches which do this (part of porting the
BSD scheduler to Linux). The run queues are done with standard queues; I
just wrote another routine which adds a new element at the end instead of
at the beginning so that the scheduler will do round-robin within a
priority class. New priorities are calculated every two seconds or so.

Email if interested -- no need to invent the wheel twice...

-- 
One trouble with being efficient is that it makes everybody hate you so. 
                -- Bob Edwards 
-- 
Matthias Urlichs        \ XLink-POP Nürnberg  | EMail: [email-masked]
Schleiermacherstraße 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42
          PGP: 1B 89 E2 1C 43 EA 80 44  15 D2 29 CF C6 C7 E0 DE 
      Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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

From: [email-masked] (Richard L. Goerwitz)
Subject: Re: memory leakage in 1.1.51 ? (FIX)
Reply-To: [email-masked]
Date: Fri, 23 Sep 1994 17:29:52 GMT

Guenther Thomsen writes, re the apparent memory leak, and its basis
in a new swapping strategy:
>
>Ok, not a bug, but for an 'old' linuxer somewhat strange.
>
>PS: It may be a FAQ, or it will be. I have to say, that I didn't read
>the recent ones ;-)

My question is whether pages swapped out, but left resident in the
swap space, are marked as such, so that they can be cleaned out if
more virtual memory is needed.  What I'm talking about is a kind of
compromise between the old and new systems....

-- 

   -Richard L. Goerwitz              [email-masked]
   [email-masked]          rutgers!oddjob!ellis!goer

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

From: [email-masked] (Andrew Bulhak)
Subject: Re: Alpha Linux
Date: 20 Sep 1994 06:50:07 GMT

Anton Ertl ([email-masked]) wrote:
: In article <[email-masked]>, [email-masked] (Douglas Ambrisko) writes:
: |> The biggest task with the
: |> Alpha is making everything 64 bit clean and this will apply to the EISA
: |> drivers.

: Only if Linux on the Alpha will be a 64-bit-OS. If it will be, I hope
: that they do not repeat the OSF/1 idiocy of having only 32-bit ints.

ints should be 32-bit, longs 64-bit and shorts 16-bit.

If both ints and longs were made 64-bit, one would have no access to
32-bit or 16-bit objects (depending on the size of a short). That would
break a lot of applications and cause headaches when dealing with file
formats.

I think that the OSF/1 solution (64-bit longs, 32-bit ints and 16-bit
shorts) is the best one; it seems to be intuitively logical (longs
should be long and may be longer than ints) and doesn't break much
(programs which depend on ints being 32-bit will still run).

--
Andrew Bulhak <[email-masked]>  Celebrate PRODOS 1.1.1 DAY 18-Sep-94

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

From: [email-masked] (Vinod G Kulkarni)
Subject: Try this IPX bridging code ...
Date: Fri, 23 Sep 1994 04:32:40 GMT

I have uploaded IPX bridging code to sunsite (Incoming). This is 
pre-pre-alpha, but is precursor for fulfledged development of IPX 
bridging/routing on linux. At this stage, it *may* work for you.
And it is not all that efficient as of now. We mainly want feedbacks and
design ideas for efficiency. 

Here is the README:
================================
This is first  attempt to get IPX bridging and routing working
for linux.

This is pre-pre-alpha. This implementation is just to trigger off 
the full fledged development. 

ASSUMPTIONS:
  1. Bridges between only two interfaces : eth0 and eth1. (Hardcoded)
  2. The MTUs of both interfaces should remain equal.

TODO:

IPX bridging:

1. Intelligent bridging
2. Get most functionality into the kernel to minimise overheads 
   (in the style of routing)

IPX routing: 

We are trying to port Mark Bush's <[email-masked]>
IPXrouted.tar.gz   to linux. This package is IPX routed implementation
for SUNs. It is available in ftp.comlab.ox.ac.uk archives.

It handles IPX packets all by itself, without requiring any kernel support
from the sun system (i.e. it reads all packets from /dev/nit interface).
Hence, this package cannot make use of IPX sockets which are currently
in the kernel. We will try to eventually adapt this package to make
use of IPX sockets which are currently in the kernel.

Note
=====
We are  still learning... All kinds of suggestions  are welcome.
Are we doing some silly mistakes in network programming?
And allow us to take our own time! 

And anyone there who is interested?

======================
Amitay Isaac, project engr., Dept. of Aero Engg. , IIT Bombay INDIA.
[email-masked]

Vinod G Kulkarni, research scholar, Dept of CSE, IIT Bombay, INDIA.
[email-masked]

-- 
--Vinod.G.Kulkarni.              ,---------------------------------------
Research scholar,                |"People often find it easier to be result
Dept. of CSE, IIT Bombay,        | of  the  past than the cause of the -
INDIA.  ([email-masked])|___________________________- future.___

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

From: [email-masked] (Harald Milz)
Subject: Re: 1+ Gig SCSI Drives
Reply-To: [email-masked]
Date: Fri, 23 Sep 1994 17:11:56 GMT

In comp.os.linux.development, Marc Singer ([email-masked]) wrote:

> I, too, have been wondering about this.  I believe that there are at
> least two problems with >1G support.  First, the standard IBM
> partition scheme limits the number of heads to 255 and the number of
> cylinders to 1024.  The math comes out such that drives larger than 1G
> cannot be supported without hardware/firmware assist, e.g. Adaptec's
> 255 head mapping trick.  Since Linux uses the IBM style partition
> tables, there is nothing simple that can be done.

I don't really know which problems you folks have. I have been 
operating a DEC DSP3160S (1.6 G) with a Adaptec 1542B since 0.99.9
and never had any problems. No Extended Translation, nothing. Remember:
All DOS-specific extensions as Extended Translation have to be switched OFF.

The one and only problem you may encounter is that you cannot boot a 
file which resides above the 1 G limit because this is handled by the
BIOS which cannot access > 1023 cyls. Just keep your /vmlinuz'es below
and you should have no problems. 

> I once read a rumor about a new filesystem standard.  I believe that
> ALL unices are limited to 2G partition sizes due to the 32 bit file
> pointer accepted by the standard OS entry points.  Perhaps there is a
> movement afoot to go to 64 bit pointers as did Microsoft with Windows
> NT.

Linus introduced 64 bit pointers recently. 

-- 
Never be led astray onto the path of virtue.
-- 
Harald Milz ([email-masked])      WWW: http://www.ix.de/editors/hm.html
iX Multiuser Multitasking Magazine      phone +49 (511) 53 52-377
Helstorfer Str. 7, D-30625 Hannover     fax   +49 (511) 53 52-378
Opinions stated herein are my own, not necessarily my employer's.

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

From: [email-masked] (Andrew Bulhak)
Subject: Re: Alpha Linux
Date: 20 Sep 1994 06:54:41 GMT

Andrew Ukrainec ([email-masked]) wrote:
: In article <[email-masked]>,
: Albert D. Cahalan <[email-masked]> wrote:
: >   >|> Alpha is making everything 64 bit clean and this will apply to the EISA
: >   >|> drivers.
: >
: >   >Only if Linux on the Alpha will be a 64-bit-OS. 
: >
: >   I sure hope it will be. Who wants a 32 bit OS on an Alpha?
: >
: >   >If it will be, I hope
: >   >that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
: >
: >   Then you have to drop either the 16 bit or the 32 bit int type. Both
: >   options may make some people unhappy. The 32 bit int is a reasonable
: >   compromise. It also breaks all those programs which assume that a
: >   pointer and an int are just the same thing, which is a good thing IMHO.
: >
: >Why drop one? 
: >16 bits = short int
: >32 bits = int
: >64 bits = long

: Another observation: at least according to the K&R C specification, short
: int, int, and long int are not defined to be any specific bit length, and
: can all be equal to same bit length, as a matter of fact.  The programmer
: who writes expecting short int = 16 bits should know that the code will not
: necessarily be portable.

: Therefore, there shouldn't be a problem defining

: short int = 32 bits
: int       = 64 bits
: long int  = 64 bits

: or all of them = 64 bits.  This makes more sense to me than int = 32 bits.

Obviously you do not need to read files in binary formats much, or at
least not binary formats designed for older platforms. 16-bit quantities
are invaluable when dealing with file formats designed for MS-DOS
applications.

--
Andrew Bulhak            [email-masked]
Remember the good old days, when "spam" on the Net referred to processed meat?

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

From: [email-masked] (Andrew Bulhak)
Subject: Re: Alpha Linux
Date: 20 Sep 1994 07:03:20 GMT

David Holland ([email-masked]) wrote:
: [email-masked]'s message of 06 Sep 1994 16:38:15 GMT said:

:  > Why drop one? 
:  > 16 bits = short int
:  > 32 bits = int
:  > 64 bits = long

: Over in the next thread people were talking about Unicode; why not

: 16 bits = char
: 32 bits = short
: 64 bits = int, long

8 bits = char
16 bits = wchar_t, short
32 bits = int
64 bits = long

: Of course that would break a lot of things, but such is the price of
: progress :-)

Why break that which is not broken, especially for such a trivial
reason? Unicode and other 16-bit encodings already have wchar_t, and
they are not going to replace ASCII in the near future.

--
Andrew Bulhak            [email-masked]
BRAKE WHATEVER IS NOT BROKEN AND CHANGE IT  !

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

From: [email-masked] (Andrew Bulhak)
Subject: Re: Alpha Linux
Date: 20 Sep 1994 07:08:52 GMT

Bill Hay ([email-masked]) wrote:
: Albert D. Cahalan ([email-masked]) wrote:

: > Why drop one? 
: > 16 bits = short int
: > 32 bits = int
: > 64 bits = long

: Because an int should be the natural wordsize of the processor and should
: therefore be 64 bits.

What is "natural"? An Alpha can handle 32-bit quantities just as
"naturally" as 64-bit quantities, so it all comes down to convenience.
And dropping one size, thus making it unavailable to programmers, is
very inconvenient.

Let's not fool ourselves. Some people say that that is a Good Thing as
it breaks poorly written applications and teaches Good Programming. This
is tantamount to asserting that self-flagellation is character-building.
In other words, it has more to do with masochism than with making a
usable system. Programming environments should not be about obstacles
for the sake of obstacles.

Just my $0.02;

--
Andrew Bulhak            [email-masked]
Remember the good old days, when "spam" on the Net referred to processed meat?

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

From: [email-masked] (Andrew Bulhak)
Subject: Re: Alpha Linux
Date: 20 Sep 1994 07:12:39 GMT

Anton Ertl ([email-masked]) wrote:

: I have debugged enough programs (one:-) that worked perfectly well on
: decent OSs on an Atari ST to know why I dislike
: sizeof(int)!=sizeof(void *). Just writing "3" instead of "3L" cost at
: least 5 hours of debugging time of two people (one of them an
: experienced Atari user).

Since the converse ( "sizeof(int)==sizeof(void *)" ) is not specified in
the C specification, it should not be assumed. It is a pretty safe
assumption, however, that a long can hold both a pointer and an int.

--
Andrew Bulhak            [email-masked]
Remember the good old days, when "spam" on the Net referred to processed meat?

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

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

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

    Internet: [email-masked]

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