Linux-Development-Sys Digest #744, Volume #7 Wed, 5 Apr 00 16:13:23 EDT
Contents:
Re: PCI configuration space fun. (Bryan Hackney)
Re: driver using socket ??? (Grant Edwards)
Re: Free BSD (Alan McLean)
Behaviour of /dev/random in Linux (Pascal JUNOD)
Re: PCI configuration space fun. (Grant Edwards)
Re: PCI configuration space fun. (Bryan Hackney)
Re: To core or not to core - You tell me (Barry Margolin)
Re: Behaviour of /dev/random in Linux (Kaz Kylheku)
Re: Resetting system I/O buffers? ("Peter T. Breuer")
Re: porting WIN32 to UNIX (Linux) (mike burrell)
Re: Time zone botch? (Jim Haynes)
Re: Free BSD (bill davidsen)
Re: FB foolin around ("Syntax")
Re: PCI configuration space fun. (Grant Edwards)
How to debug driver that freezes the system? ("Mr. Oogie Boogie")
Re: To core or not to core - You tell me (Logan Shaw)
Re: PCI configuration space fun. (Bryan Hackney)
Re: PCI configuration space fun. (Grant Edwards)
Re: How to debug driver that freezes the system? (Kaz Kylheku)
Re: To core or not to core - You tell me (Erik Max Francis)
Re: To core or not to core - Part 2 (Erik Max Francis)
----------------------------------------------------------------------------
From: Bryan Hackney <[EMAIL PROTECTED]>
Subject: Re: PCI configuration space fun.
Date: Wed, 05 Apr 2000 11:22:12 -0500
"Daniel J. Feren" wrote:
>
> Has anyone written a user-level (not kernel-level)
> device driver that can write to a PCI bus card's
> configuration space? I'm refering to the unused
[...]
Go the the XF86 source, where this is done. The X server is,
of course, a process that accesses the PCI space.
You can mmap in the entire space presented by the device,
sometime multiple spaces. Don't forget iopl().
--
Bryan Hackney / BHC / [EMAIL PROTECTED]
http://www.FreeClassAds.com/
http://bhconsult.com/
http://bhconsult.com/bh/pgp.key
------------------------------
From: grant@nowhere. (Grant Edwards)
Subject: Re: driver using socket ???
Date: Wed, 05 Apr 2000 16:34:00 GMT
In article <[EMAIL PROTECTED]>, philippe Defert wrote:
>i developpe a character driver using socket
>and when i compile i have no warning and no error
>but when i load the module ,
>the kernel respond :
>./driv.o : unresolved symbol socket
>./driv.o : unresolved symbol getservname
>./driv.o : unresolved symbol getservbyname
>./driv.o : unresolved symbol connect
This question has come up in the past, and the asnwer as far as
I have been able to determine is that you can't use those
functions from driver code. You can write/read to/from an
already open socket (though not using the standard read() and
write() calls), but I don't think it's possible to open a
socket from driver code.
I'd be quite happy if I were wrong, so feel free to correct me
as long as you show me how it's done. ;)
--
Grant Edwards grante Yow! If this is the DATING
at GAME I want to know your
visi.com FAVORITE PLANET! Do I get
th' MICROWAVE MOPED?
------------------------------
From: [EMAIL PROTECTED] (Alan McLean)
Subject: Re: Free BSD
Date: Wed, 05 Apr 2000 16:35:53 GMT
AD <[EMAIL PROTECTED]> wrote:
> Linux is flexible. And, for the p.s.: Linux and BSD are friends:
> look at the history of Linux NET code, for example. Its just like
> a people life, life of OS's: everybody learn to live from others.
Certainly many Linux and *BSD developers are friends or have a
healthy relationship. However, thinking the Linux network stack
is BSD derived seems to be a common misconception. I believe a
port of the 4.4BSD stack did exist at some point, but AFAIK it
was never in the official (Linus') tree.
For more information refer to section 4 of
ftp://metalab.unc.edu/pub/Linux/docs/howto/NET3-4-HOWTO
-amcl
------------------------------
Date: Wed, 05 Apr 2000 18:39:05 +0200
From: Pascal JUNOD <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Behaviour of /dev/random in Linux
Hi !
I have a few problems with /dev/random.
In the documentation, it is written that this device normally blocks a
read until there it has enough entropy to give. In the following
program, my read() returns from time to time a value less than 8 : 1, 4
, 3, ...(not -1). How it is possible ?
I'm using kernel Linux version 2.2.5-22 ([EMAIL PROTECTED])
unsigned long long regs[128];
unsigned int i;
int fd, rt;
unsigned long long buf;
for(i = 0; i < 128; ++i) {
if((fd = open("/dev/random", O_RDONLY)) == -1) {
printf("\nError : unable to open /dev/random...aborting\n");
exit(-1);
}
if((rt = read(fd, &buf, 8)) != 8) {
printf("\nError : unable to get enough entropy...aborting %d\n",
rt);
exit(-1);
}
regs[i] = buf;
printf("\nSeed #%d: %LX", i, buf);
close(fd);
}
A+
Pascal
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Pascal Junod, [EMAIL PROTECTED] *
* Laboratoire de S�curit� et de Cryptographie (LASEC) *
* ++ 41 (0) 21 693 7617, INR 313, EPFL, CH-1015 Lausanne *
* Route d'Yverdon 25, CH-1028 Pr�verenges, Switzerland *
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
From: grant@nowhere. (Grant Edwards)
Subject: Re: PCI configuration space fun.
Date: Wed, 05 Apr 2000 16:39:30 GMT
In article <[EMAIL PROTECTED]>, Bryan Hackney wrote:
>"Daniel J. Feren" wrote:
>>
>> Has anyone written a user-level (not kernel-level)
>> device driver that can write to a PCI bus card's
>> configuration space? I'm refering to the unused
>[...]
>
>Go the the XF86 source, where this is done. The X server is,
>of course, a process that accesses the PCI space.
>
>You can mmap in the entire space presented by the device,
>sometime multiple spaces. Don't forget iopl().
He's talking about the PCI configuration space, not the normal
PCI memory space that you can mmap. A PCI board has three
address spaces: configuration, memory, and I/O. Mmap only
works on the memory address space.
On second thought, I suppose you could map the other two by
installing a page-fault handler that got called on every acess
and translated it into appropriate BIOS calls (for the
configuration space) or I/O instructions (for the I/O space).
Maybe not. The page fault handler is just supposed to set up
the page and return a page pointer (which you could make work
for read operations), but it doesn't have access to the data in
the case of a write operation.
--
Grant Edwards grante Yow! When you get your
at PH.D. will you get able to
visi.com work at BURGER KING?
------------------------------
From: Bryan Hackney <[EMAIL PROTECTED]>
Subject: Re: PCI configuration space fun.
Date: Wed, 05 Apr 2000 11:48:36 -0500
Grant Edwards wrote:
>
[...]
>
> He's talking about the PCI configuration space, not the normal
> PCI memory space that you can mmap. A PCI board has three
> address spaces: configuration, memory, and I/O. Mmap only
> works on the memory address space.
No, mmap works fine on the config space, too.
>
> On second thought, I suppose you could map the other two by
> installing a page-fault handler that got called on every acess
> and translated it into appropriate BIOS calls (for the
> configuration space) or I/O instructions (for the I/O space).
> Maybe not. The page fault handler is just supposed to set up
> the page and return a page pointer (which you could make work
> for read operations), but it doesn't have access to the data in
> the case of a write operation.
No need to go to that trouble, mapping the config space is no
different than mapping the devices memory. I've done it with
an i960 pci co-processor, and with a PLX controller.
[...]
--
Bryan Hackney / BHC / [EMAIL PROTECTED]
http://www.FreeClassAds.com/
http://bhconsult.com/
http://bhconsult.com/bh/pgp.key
------------------------------
From: Barry Margolin <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Wed, 05 Apr 2000 17:05:08 GMT
In article <8cfkg0$ivu$[EMAIL PROTECTED]>,
Harish K Chandraia <[EMAIL PROTECTED]> wrote:
>Isn't there any standard which says how such situations should be
>handled?. Does ANSI address things like this? Thank you all once
>again for u'r responses and time.
Many of the responses have told you what the ANSI C standard says: the
consequences are undefined, so anything can happen as far as it's
concerned.
It would be conceivable for POSIX to specify what Unix-like systems should
do when dereferencing a null pointer, but I don't think it does, either.
So, basically, this is left up to hardware and OS designers to deal with as
they see fit.
--
Barry Margolin, [EMAIL PROTECTED]
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Behaviour of /dev/random in Linux
Reply-To: [EMAIL PROTECTED]
Date: Wed, 05 Apr 2000 17:08:21 GMT
On Wed, 05 Apr 2000 18:39:05 +0200, Pascal JUNOD <[EMAIL PROTECTED]> wrote:
>Hi !
>
>I have a few problems with /dev/random.
>
>In the documentation, it is written that this device normally blocks a
>read until there it has enough entropy to give. In the following
>program, my read() returns from time to time a value less than 8 : 1, 4
>, 3, ...(not -1). How it is possible ?
The read() system call is allowed to return fewer bytes than expected.
Your program is broken because it expects exactly eight.
--
#exclude <windows.h>
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: Resetting system I/O buffers?
Date: 5 Apr 2000 17:06:30 GMT
Robert Cox <[EMAIL PROTECTED]> wrote:
: Is there a (hopefully easy) way to flush the system I/O buffers
: (as shown in "free") so that they are empty? I'd like to time
dd if=/dev/hda of=/dev/null
might get you some of the way!
Peter
------------------------------
From: mike burrell <[EMAIL PROTECTED]>
Subject: Re: porting WIN32 to UNIX (Linux)
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.development,comp.os.ms-windows.programmer.win32,comp.os.ms-windows.programmer.misc,comp.unix.programmer,comp.programming
Date: Wed, 05 Apr 2000 17:21:26 GMT
In comp.unix.programmer Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> Forget it; if you are going to develop for Linux, do a real port. Wine is for
> running binary windows EXE's. It's undesirable compared to having a ``native''
> Linux app.
that is complete garbage. wine is *not* for running binary windows EXEs.
it just so happens that wine ships with an emulator (oddly enough called
wine), but wine is *not* an emulator. wine is an implementation of the
windows API. you create real, native applications with wine, not windows
EXEs. linking against wine is no different from linking against curses and
does not make it any less "native".
--
/"\ m i k e b u r r e l l
\ / ASCII RIBBON CAMPAIGN [EMAIL PROTECTED]
X AGAINST HTML MAIL http://mikpos.dyndns.org
/ \
------------------------------
Subject: Re: Time zone botch?
Reply-To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] (Jim Haynes)
Date: Wed, 05 Apr 2000 17:24:11 GMT
In article <[EMAIL PROTECTED]>,
Villy Kruse <[EMAIL PROTECTED]> wrote:
[solution to the problem]
Thanks. The support system for Linux rarely fails me, and it has
come through again.
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: Free BSD
Date: 5 Apr 2000 17:22:38 GMT
In article <[EMAIL PROTECTED]>,
Alan McLean <[EMAIL PROTECTED]> wrote:
| AD <[EMAIL PROTECTED]> wrote:
| > Linux is flexible. And, for the p.s.: Linux and BSD are friends:
| > look at the history of Linux NET code, for example. Its just like
| > a people life, life of OS's: everybody learn to live from others.
|
| Certainly many Linux and *BSD developers are friends or have a
| healthy relationship. However, thinking the Linux network stack
| is BSD derived seems to be a common misconception. I believe a
| port of the 4.4BSD stack did exist at some point, but AFAIK it
| was never in the official (Linus') tree.
|
| For more information refer to section 4 of
|
| ftp://metalab.unc.edu/pub/Linux/docs/howto/NET3-4-HOWTO
I would certainly buy that a lot of ideas from BSD went into Linux,
but a lot of independent thought did, too. Which is why 1.2, 2.0, 2.2,
and (pre)2.4 all have completely different implementations and kernel
interfaces.
The 2.3 kernel did have some compatibility stuff for 2.0 and 2.2, but
pre3 wouldn't compile it, and the latest Alan Cox patches (yes, even
more unofficial ;-) have it taken out.
I do believe that some of the early network stuff at the application
level was based on BSD code, but not the internals. Then again, I don't
have to search the BSD kernel code trying to separate the bugs from the
features, so I am not all that familiar with BSD internals.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
"Doing interesting things with little computers since 1979"(tm)
The hardest test of maturity is knowing the difference between
resisting temptation and missing a once-in-a-lifetime opportunity.
------------------------------
From: "Syntax" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: FB foolin around
Date: Wed, 05 Apr 2000 17:47:21 GMT
Check out the VGA/SVGA libraries,
header files
/usr/include/vga.h
vgagl.h
or the source to them...
-Lucas
"Stephen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Ok, I have been interested in this "frame buffer" support in the 2.2
> kernels so I decided to see what I can do with it. I set out to
> basically switch to some graphic mode and set a pixel. This is not as
> straight forward as I thought and need a little help.
>
> I used ioctl FBIOGET_VSCREENINFO and it returned info for a mode
> 640x480x4 bits. This is fine for my doodling. However, I am unclear
> about how to sucessfully switch to this mode. I used something like:
> ioctl(tty, KDSETMODE, KD_GRAPHICS);
> but this only puts me in a 640x480x1bit mode. Ok I can put a pixel on
> the screen in this mode but monochrome is not what I'd like. Any ideas
> out there on what I am screwing up.
>
> Also, I have the fbvesa stuff compiled in. I'd love to be able to query
> the card and see what modes it supports and then set one.
>
> Any help is appreciated!!!
>
> Stephen
>
>
------------------------------
From: grant@nowhere. (Grant Edwards)
Subject: Re: PCI configuration space fun.
Date: Wed, 05 Apr 2000 18:30:04 GMT
In article <[EMAIL PROTECTED]>, Bryan Hackney wrote:
>Grant Edwards wrote:
>
>> He's talking about the PCI configuration space, not the normal
>> PCI memory space that you can mmap. A PCI board has three
>> address spaces: configuration, memory, and I/O. Mmap only
>> works on the memory address space.
>
>No, mmap works fine on the config space, too.
[...]
>No need to go to that trouble, mapping the config space is no
>different than mapping the devices memory. I've done it with
>an i960 pci co-processor, and with a PLX controller.
I have obviously misunderstood how the config space works. How
do you get the PCI bus address of the config space for a board?
--
Grant Edwards grante Yow! Four thousand
at different MAGNATES, MOGULS
visi.com & NABOBS are romping in my
gothic solarium!!
------------------------------
From: "Mr. Oogie Boogie" <[EMAIL PROTECTED]>
Subject: How to debug driver that freezes the system?
Date: Wed, 05 Apr 2000 15:04:44 -0400
Howdy,
I'm debugging a PC-card character device driver that I've written and
can't
figure out what is causing the system to freeze. I'm an experienced C
programmer but this is the first Linux programming I've done. The
driver is
nearly completed. This nasty bug is the last problem I've found. The
other
problems I was able to find using printk's but I can't get any of the
printk
output after the system reboots.
The bug locks the system up real good. The power button wont even
reset the
computer. I have to unplug it and remove the batteries (I'm testing it
on a
laptop.) At first I thought it might be a bad pointer but now I'm
leaning
towards a problem with interrupts.
Does anyone have a suggestions how I can track this problem down?
Also, because this is the first driver/linux program I've done it
would be
great if anybody with experience could take a look at it and tell me
if I'm
doing anything wrong. Is there somewhere I could post the source so
anyone can
look at it?
Thanks,
Ralph A. Preston
The MITRE Corporation
202 Burlington Road, MS E015
Bedford, MA 01730-1420
------------------------------
From: [EMAIL PROTECTED] (Logan Shaw)
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: 5 Apr 2000 14:32:31 -0500
In article <8cfkg0$ivu$[EMAIL PROTECTED]>,
Harish K Chandraia <[EMAIL PROTECTED]> wrote:
>On the Sun OS, it always had segmentation fault and there was no core
>file. On a tandem machine running
>NonStop-UX leonard 4.2MP C51IPM74.puma.0414.01:12 S5000 mips, I ended
>up with 0 being printed out always and on the first machine, I always
>ended with a large number.......599785536. Somebody mentioned that I
>might not get the same results on the same machine when I run the
>program but the behaviour of the machines have been consistent.
On those four machines, sure. But not on all machines that have ever
existed. One exception I can think of right off is the Amiga. The
Motorola 68000 models didn't have memory manager hardware, so if a
program wrote to location zero, nothing would stop the value from being
written there, and it'd just stay there.
Worse, some programs had bugs in them where they'd do stuff like this:
if (p->flag) { do_something(); }
rather than this:
if (p != NULL && p->flag) { do_something(); }
And what do you think would happen? That was *fine* as long as
location zero contained a zero, but if it contained a non-zero value,
the flag would suddenly and unexpected be true, and the code would
branch off to some unexpected place.
Worse, the developers of such programs usually didn't test their code
on systems which had non-zero values stored at 0x00000000, so they
didn't know what would happen in that case.
The result is that you could run a program with a subtle bug that would
accidentaly write to 0x00000000, and then later you could run another
program that normally worked, but which would freak out since somebody
had made location 0x00000000 non-zero.
This made for delightfully seemingly non-deterministic behavior: run
program #1, and it works, then run program #2, and then run program #1
again, and suddenly program #1 doesn't work anymore!
One or two handy little utilities sprang up to deal with the problem.
One would simply wake up once a second or so and read 0x00000000. If
it was non-zero, it'd pop up a window and warn the user, then set it
back to zero. It was helpful as a work-around, but really those
programs that benefitted were broken as designed (or, as implemented,
since that may not have been a design decision!).
>It's also true as someone mentioned that things were fine as long as
>I was just accessing ptr->a but as soon as I try to write something
>into ptr->a, then all the platforms behaved in the same manner.....
>segv occured.
Any kind of access to ptr->a is illegal and undefined if ptr isn't
defined or if it's NULL. You might get away with it on reading for
some systems, but that's just luck.
>Isn't there any standard which says how such situations should be
>handled?
Is there a standard that specifies the proper way to run a red light?
No. Instead, there is a standard that says not to run a red light.
It's the same for dereferencing a NULL pointer, whether it's for
reading or writing.
- Logan
------------------------------
From: Bryan Hackney <[EMAIL PROTECTED]>
Subject: Re: PCI configuration space fun.
Date: Wed, 05 Apr 2000 14:34:19 -0500
Grant Edwards wrote:
>
[...]
> I have obviously misunderstood how the config space works. How
> do you get the PCI bus address of the config space for a board?
>
> --
[...]
The following device config space starts at e6000000.
Bus 1, device 0, function 0:
VGA compatible controller: Silicon Integrated Systems Unknown device (rev 146).
Vendor id=1039. Device id=6326.
Medium devsel. Master Capable. Latency=32. Min Gnt=2.
Prefetchable 32 bit memory at 0xe6000000 [0xe6000008].
Non-prefetchable 32 bit memory at 0xe5000000 [0xe5000000].
I/O at 0xd000 [0xd001].
You have to get the numbers from reading the PCI controller:
//x86 code
unsigned PCI::read( const PCITag & tag, unsigned reg ) {
unsigned addr, data = 0;
if ( tag.cfg1 == 0 ) {
return 0xffffffff;
}
switch ( configtype ) {
case 1:
addr = tag.cfg1 | (reg & 0xfc);
out32( MODE1_ADDRESS_REG, addr );
data = in32( MODE1_DATA_REG );
out32( MODE1_ADDRESS_REG, 0);
break;
case 2:
addr = tag.cfg2.port | ( reg & 0xfc );
out8( MODE2_ENABLE_REG, tag.cfg2.enable );
out8( MODE2_FORWARD_REG, tag.cfg2.forward );
data = in32( (unsigned short)addr );
out8( MODE2_ENABLE_REG, 0);
out8( MODE2_FORWARD_REG, 0);
break;
}
return data;
}
--
Bryan Hackney / BHC / [EMAIL PROTECTED]
http://www.FreeClassAds.com/
http://bhconsult.com/
http://bhconsult.com/bh/pgp.key
------------------------------
From: grant@nowhere. (Grant Edwards)
Subject: Re: PCI configuration space fun.
Date: Wed, 05 Apr 2000 19:42:52 GMT
In article <[EMAIL PROTECTED]>, Bryan Hackney wrote:
>Grant Edwards wrote:
>>
>[...]
>> I have obviously misunderstood how the config space works. How
>> do you get the PCI bus address of the config space for a board?
>>
>> --
>[...]
>
>The following device config space starts at e6000000.
No, That's the PCI memory space occupied by the device.
> Bus 1, device 0, function 0:
> VGA compatible controller: Silicon Integrated Systems Unknown device (rev 146).
> Vendor id=1039. Device id=6326.
> Medium devsel. Master Capable. Latency=32. Min Gnt=2.
> Prefetchable 32 bit memory at 0xe6000000 [0xe6000008].
> Non-prefetchable 32 bit memory at 0xe5000000 [0xe5000000].
> I/O at 0xd000 [0xd001].
And the PCI I/O space is at 0xd000.
>You have to get the numbers from reading the PCI controller:
Right. The code below is reading the PCI configuration space,
and I don't think you can mmap() the PCI configuration
registers which are being accessed below.
>//x86 code
>unsigned PCI::read( const PCITag & tag, unsigned reg ) {
>
> unsigned addr, data = 0;
>
> if ( tag.cfg1 == 0 ) {
> return 0xffffffff;
> }
>
> switch ( configtype ) {
> case 1:
> addr = tag.cfg1 | (reg & 0xfc);
> out32( MODE1_ADDRESS_REG, addr );
> data = in32( MODE1_DATA_REG );
> out32( MODE1_ADDRESS_REG, 0);
> break;
[...]
--
Grant Edwards grante Yow! Hand me a pair of
at leather pants and a CASIO
visi.com keyboard -- I'm living
for today!
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: How to debug driver that freezes the system?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 05 Apr 2000 19:54:49 GMT
On Wed, 05 Apr 2000 15:04:44 -0400, Mr. Oogie Boogie <[EMAIL PROTECTED]>
wrote:
>Howdy,
>
>I'm debugging a PC-card character device driver that I've written and
>can't
>figure out what is causing the system to freeze. I'm an experienced C
>programmer but this is the first Linux programming I've done. The
>driver is
>nearly completed. This nasty bug is the last problem I've found. The
>other
>problems I was able to find using printk's but I can't get any of the
>printk
>output after the system reboots.
Take it easy! You probably did something silly like lock a spinlock and
forget to unlock it, or in some other way cause an infinite loop.
The spinlock code can be compiled to chatter debug messages.
I suggest you add debug traces to your driver which can be enabled or disabled
at compile time using the preprocessor. If you place a debug trace into the
infinite loop, it will be obvious: at the time of the hang, your console will
be flooded with the message.
I did that once in a network driver I was working on; I returned some wrong
value from the xmit function and created a loop.
>
>The bug locks the system up real good. The power button wont even
>reset the
>computer. I have to unplug it and remove the batteries (I'm testing it
>on a
>laptop.)
Heh; now you know what it feels like to be some poor bastard running Windows on
the same model laptop. ;)
>doing anything wrong. Is there somewhere I could post the source so
>anyone can
>look at it?
You can mail it right to me.
--
#exclude <windows.h>
------------------------------
From: Erik Max Francis <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Wed, 05 Apr 2000 12:50:16 -0700
Harish K Chandraia wrote:
> It's also true as someone mentioned that things were fine as long as
> I was just accessing ptr->a but as soon as I try to write something
> into ptr->a, then all the platforms behaved in the same manner.....
> segv occured.
Not true. Both invoke undefined behavior, because they both involve
dereferencing the null pointer.
> Isn't there any standard which says how such situations should be
> handled?. Does ANSI address things like this? Thank you all once
> again for u'r responses and time.
Several people including myself have told you what the ANSI C standard
says about this: It invokes undefined behavior. When undefined
behavior is invoked, _anything_ can happen. Anything can actually even
include what you were expecting, but that undefined behavior does not
have to be consistent from invocation to invocation. That is, it can do
what you expect today and what you don't expect tomorrow, or when you
port it to another machine, or when you upgrade your compiler, or when
it's past 10 pm.
Never do something which invokes undefined behavior. Just don't do it.
--
Erik Max Francis | email [EMAIL PROTECTED] | icq 16063900
Alcyone Systems | web http://www.alcyone.com/max/ | q3a Product
San Jose, CA | languages en, eo | icbm 37 20 07 N 121 53 38 W
USA | 968.994 Ms p.L. | 272 days left | &tSftDotIotE
------------------------------
From: Erik Max Francis <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.unix.questions,comp.unix.programmer
Subject: Re: To core or not to core - Part 2
Date: Wed, 05 Apr 2000 12:54:52 -0700
Harish K Chandraia wrote:
> Have any of you experienced this.....you have a program which
> core dumps....and you put in additional printf's and compile with
> DEBUG defined in your Makefile and all of a sudden it stops core
> dumping on you. What could be the reason for something like this to
> happen.
Perhaps the extra I/O involved in the printf makes the problem go away
(perhaps it is very time sensitive). Perhaps the debugging flag
guarantees that uninitialized memory will be initialized to zero.
Probably you are simply invoking undefined behavior and are getting away
with it with the debugging and printf statements but are out of luck
when they're not there.
--
Erik Max Francis | email [EMAIL PROTECTED] | icq 16063900
Alcyone Systems | web http://www.alcyone.com/max/ | q3a Product
San Jose, CA | languages en, eo | icbm 37 20 07 N 121 53 38 W
USA | 968.994 Ms p.L. | 272 days left | &tSftDotIotE
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
