Linux-Development-Sys Digest #782, Volume #7     Mon, 17 Apr 00 18:13:23 EDT

Contents:
  Re: To core or not to core - You tell me (Ron Natalie)
  Linux kernel preemptability (Manoj Patil)
  Re: How do you generate UUID under Linux? (Xavier Leroy)
  Re: How do you generate UUID under Linux? ("James Ricci")
  Re: What's the difference between bzImage and zImage (John Reiser)
  Re: Q: is there a free secure network filesystem for Linux? (Mario Klebsch)
  Re: understand system calls ! (Alan Donovan)
  Re: Locking user space pointers in the kernel. (Alan Donovan)
  Re: How do I make a program run on localhost:200 (Alan Donovan)
  Re: kernel communicate with module (Michael Kelly)
  Re: How do I make a program run on localhost:200 (Eric P. McCoy)
  Re: PIIX4 not 100% native mode (Kevin Buhr)
  linux & NOT knfs (not kernel nfs) (Alexander Sirotkin)
  Re: mawk ("Michael Faurot")
  Re: Network Protocol at Kernel Space (Kaz Kylheku)
  Re: MS caught breaking wind ("aCiD fEiNd")
  Re: To core or not to core - You tell me (Mark McIntyre)
  Re: To core or not to core - You tell me (Mark McIntyre)
  Kernel Driver Module accessing a text file: How to? ("Sean Bose")
  Re: To core or not to core - You tell me (Erik Max Francis)
  Re: To core or not to core - You tell me (Ron Natalie)
  Re: Put the lib into the libc?  (was: Re: Simple but...) (Matthias Kleinmann)
  Re: To core or not to core - You tell me (Erik Max Francis)
  Re: MPROTECT (David)
  Re: To core or not to core - You tell me (Barry Margolin)

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

From: Ron Natalie <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Mon, 17 Apr 2000 10:31:01 -0400



Mark McIntyre wrote:

> 
> >which in and of itself is not a pointer.
> 
> says who?

Says the language, it's an literal of type int.  The null pointer constant
only has meaning when compared/assigned-to a pointer.

> 
> *sigh*. No I don't I mean the bit pattern of the value that NULL
> preprocesses out into when the preprocessor runs through your code.
> You are the one talking about a null pointer. I'm talking about the
> null pointer constant.

Frankly, you don't know the representation of anything in the C language, is
the point.  A integer zero may not be encoded as a bunch of zero bits as far
as the language is concerned.
>

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

From: Manoj Patil <[EMAIL PROTECTED]>
Subject: Linux kernel preemptability
Date: Mon, 17 Apr 2000 20:22:02 +0530

    I have few questions on kernel pre-emptability

1. Is the kernel pre-emptable, if yes, to what level.  (are there any
ifs and buts on this ? )
2. How many levels of interrupts pre-emptability is supported and how is
it implemented. (For example in AIX , there are 12 levels supported and
each interruption is saved in mstsave structure)



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

From: Xavier Leroy <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,it.comp.linux.development
Subject: Re: How do you generate UUID under Linux?
Date: 17 Apr 2000 16:52:14 +0200


"James Ricci" <[EMAIL PROTECTED]> writes:

> We are porting some C++ code from Win32 to Linux. One of the last pieces yet
> to move is the generation of GUID's (or UUID's) from within our program.
> I've not been able to locate a native routine under Linux which can do this.
> We're looking for the code equivalent of UuidCreate under Linux.

UUIDs are just world-wide unique sequences of 16 bytes.  The best way to 
generate them is simply to use 16 random bytes from a high-quality
pseudo-random number generator.  (The chances of two persons
generating the same 16-byte random number are astronomically low.)

Linux has such a PRNG built in the kernel.  Just open the device
/dev/random and read 16 bytes from it.  Voila, a perfectly correct
UUID.

Alternatively, you can also generate UUIDs the Microsoft way,
by using the machine's Ethernet address, time of generation, and
random bytes for padding.  However, it's more complex, not really more
secure against collisions, and the resulting UUIDs reveal your
Ethernet address, which is not necessarily desirable.  (Not to mention
that your computer may not have an Ethernet card.)

- Xavier Leroy

-- 
Valid e-mail address (without the underscores): [EMAIL PROTECTED]
This is a protection against junk mail. Apologies for the inconvenience.
Home page: http://pauillac.inria.fr/~xleroy/

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

From: "James Ricci" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,it.comp.linux.development
Subject: Re: How do you generate UUID under Linux?
Date: Mon, 17 Apr 2000 10:59:08 -0400

Xavier,

Good point. I'll play with /dev/random a bit.

James



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

From: John Reiser <[EMAIL PROTECTED]>
Subject: Re: What's the difference between bzImage and zImage
Date: Mon, 17 Apr 2000 08:53:23 -0700

Only the zImage file itself (/usr/src/linux/arch/i386/boot/zImage) is "leftover
garbage", and should be removed.  Everything else is needed for making bzImage.

> I was just recompiling my kernel (for the first time .. a nail byter).  'make
> zImage'.  I was told there wasn't enough space for a zImage, and to try again with
> a bzImage.  Which I did.  But now I'm not sure if I have to go back and clean up
> after the 'make zImage' attempt.

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

From: [EMAIL PROTECTED] (Mario Klebsch)
Subject: Re: Q: is there a free secure network filesystem for Linux?
Date: Mon, 17 Apr 2000 09:00:48 +0200

David Wragg <[EMAIL PROTECTED]> writes:

>The TI/RPC code released by Sun seems to be pretty complete, with the
>exception of the GSSAPI mechanism for Kerberos, which is dissapointing
>since it is in Solaris 8.

I am sorry, my Solaris Knowledge is a bit outdated. I don't know the
GSSAPI. However, I know, secure NFS was there from the first Solaris 2
days, and it never was called NFS version 4. Secure NFS was even
possible prior toi NFS version 3.

I must admit, I never completely understood secure RPC. I knew enough
to create credentioals and keep NIS+ happy, but I always wondered, how
it was integrated into the kernel.

- What the hell does keylogin do?
- Where does it get the users password (I did not enter my password
  twice upon a normal login)?
- The credentioals are stored by the keyserver. How does the kernels
  NFS get it?

Lots of more questions. However, I was hoping, someone already picked
it up and ported it to Linux.

73, Mario
-- 
Mario Klebsch                                           [EMAIL PROTECTED]

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

From: Alan Donovan <[EMAIL PROTECTED]>
Subject: Re: understand system calls !
Date: Mon, 17 Apr 2000 17:19:19 +0100

"denis.chmielewski" wrote:
> 
> hello everybody,
> 
> I am studying the system call mechanism and I don't understand.
> To explain my problem, let's take the fopen example :

fopen(3) is part of the C library. This is a layer above the system call
interface, which uses open(2). The fxxx routines do buffered IO. The
kernel (system call) routines are direct.

If you wish to understand the system call mechanism, pick a simple
system call: e.g. getuid(). This does nothing besides reading a value
out of the current process' task_struct, but illustrates the minimum
required to "get into the kernel".

alan

-- 
========================================================================
  Alan Donovan     [EMAIL PROTECTED]    http://www.imerge.co.uk
  Imerge Ltd.      +44 1223 875265

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

From: Alan Donovan <[EMAIL PROTECTED]>
Subject: Re: Locking user space pointers in the kernel.
Date: Mon, 17 Apr 2000 17:28:20 +0100

liran wrote:
> 
> Hi,
> In my driver i want to lock the buffer i get from the user
> to avoid the buffer been swaped out
> and then wait until it will be swaped in.
> How do i do that?
> Where can i read about the interface the kernel gives on
> manipulate user space address in kernel space?

It can't be done ordinarily. However Robert Kaiser has written a patch
that provides two calls udma_lock and udma_unlock, that do user address
translation and locking. It can even be installed as a module, if you
are happy to avert your eyes from the hoops it has to jump through to
get ahold of the address of non-extern variables.  It will never be
standard kernel, either.

Available at ftp://ftp.sysgo.de/pub/Linux.

alan


-- 
========================================================================
  Alan Donovan     [EMAIL PROTECTED]    http://www.imerge.co.uk
  Imerge Ltd.      +44 1223 875265

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

From: Alan Donovan <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.questions,comp.unix.programmer,comp.os.linux.development.apps
Subject: Re: How do I make a program run on localhost:200
Date: Mon, 17 Apr 2000 17:31:44 +0100

Peet Grobler wrote:

> Anyways, running Mandrake Linux 7.0 at home. I was thinking, how would you
> make a program run on a specified port?

> E.g. let's say I wrote a special getty program. I want it to sit on port
> 200, waiting for connections. Do I have to write the program to specifically
> open a port, or can I use some script somewhere to get the program's stdin
> to be changed to a port???

If you are writing the app yourself, then you get to fill in the
sockaddr struct yourself, with whatever port you like. Typically one
uses a compiled-in default with an option to override on the command
line or thru an environment variable.

Well-known services (e.g. httpd, ftpd, etc) can look up the port in
/etc/services using getservent and use whatever value they find in
there.

alan



-- 
========================================================================
  Alan Donovan     [EMAIL PROTECTED]    http://www.imerge.co.uk
  Imerge Ltd.      +44 1223 875265

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

From: [EMAIL PROTECTED] (Michael Kelly)
Subject: Re: kernel communicate with module
Date: 17 Apr 2000 17:17:09 GMT

In article <8dcvp9$mc2$[EMAIL PROTECTED]>,
        Yung-Hsiang Lu <[EMAIL PROTECTED]> writes:
> Hi,
> 
> What is the simplest way for kernel and module to communicate?  Can I
> declare a variable in kernel with EXPORT_SYMBOL so that it can be seen
> by modules?  Is there a better way?
> 
> Thank you.
> 

You might take a look at kerneld and see how it does it.
It's been a while since I read about kerneld, so I don't
recall exactly the IPC that it uses.


-- 

Mike
--
"I don't want to belong to any club that would have *me* as a member!"
             -- Groucho Marx


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

Crossposted-To: comp.unix.questions,comp.unix.programmer,comp.os.linux.development.apps
Subject: Re: How do I make a program run on localhost:200
From: [EMAIL PROTECTED] (Eric P. McCoy)
Date: 17 Apr 2000 13:30:15 -0400

"Peet Grobler" <[EMAIL PROTECTED]> writes:

> E.g. let's say I wrote a special getty program. I want it to sit on port
> 200, waiting for connections. Do I have to write the program to specifically
> open a port, or can I use some script somewhere to get the program's stdin
> to be changed to a port???

You could probably use a combination of inetd, telnetd, and your
custom program.  In /etc/inetd.conf, you'd add the entry for the port
you want and set the program as something like

  /usr/sbin/in.telnetd in.telnetd -L YOUR-PROGRAM

This is what I'd fondly refer to as a vicious hack, though.  You
should really be writing your own program, or make sure that the one
you want to use immediately changes to some user other than root.

-- 
Eric McCoy ([EMAIL PROTECTED])

"misfortune, n. The kind of fortune that never misses."
        - Ambrose Bierce, The Devil's Dictionary

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

From: [EMAIL PROTECTED] (Kevin Buhr)
Subject: Re: PIIX4 not 100% native mode
Date: 17 Apr 2000 13:14:00 -0500

Yung-Hsiang Lu <[EMAIL PROTECTED]> writes:
> 
> Does anybody know what this means (in /var/log/dmesg)
> 
> PIIX4: not 100% native mode: will probe irqs later
>
> I am running Linux 2.3.99-pre5 on a Sony VAIO PCG-F450 notebook
> computer (Pentium III).  Does this mean some problems?  How to fix it?

No, there's no problem.  All it means is that the IDE controller built
in to the PIIX4 chipset on your motherboard was set up (probably by
the BIOS) to use the legacy IDE interrupts 14 and 15 instead of the
PCI-mapped interrupts used by 100% native PCI devices.

The BIOS set it up this way for compatibility reasons.  Some operating
systems may assume that these standard interrupt assignments are in use.
Linux couldn't care less which interrupt your controller wants to use,
and will probe to find out.

None of this should have any adverse effect on performance.

Kevin <[EMAIL PROTECTED]>

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

From: Alexander Sirotkin <[EMAIL PROTECTED]>
Crossposted-To: 
comp.os.linux.networking,comp.os.linux.setup,comp.os.linux.misc,comp.protocols.nfs
Subject: linux & NOT knfs (not kernel nfs)
Date: 17 Apr 2000 18:29:11 GMT

Hi.

I need to add nsf client functionality (namely make it recognize
nfs filesystem) to some mission critical linux server (on which
I can't recompile the kernel and reboot). Just adding nfs.o 
and lockd.o modules didn't help - they relay on "do_lockdctl"
which is compiled into kernel itself only when nfs module is 
selected.

So I recalled that some time ago we used not kernel NFS - any1
knows where I can download it ? 

Or is there better solution ?


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

From: "Michael Faurot" <[EMAIL PROTECTED]>
Subject: Re: mawk
Date: 17 Apr 2000 18:57:06 GMT

Hook <[EMAIL PROTECTED]> wrote:
: Can anyone tell me were can I find mawk for redhat 6.0, I need it for the
: hylafax program.

You should be able to find a copy here:

        http://rufus.w3.org/linux/RPM/

-- 
==============================================================================
 Michael | mfaurot  | It doesn't matter whether you win or lose -- until
 Faurot  | atww.net | you lose.

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

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Network Protocol at Kernel Space
Reply-To: [EMAIL PROTECTED]
Date: Mon, 17 Apr 2000 19:14:49 GMT

On Mon, 17 Apr 2000 08:52:17 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>Hello,
>
>I would like to implement a network protocol in kernel
>space. I know about the packet(7) but this is for user
>space only. Could you please help me.

You find out how the protocol interface works and then you implement your own
version of it by providing all the necessary virtual functions. 

Applications can then create sockets, specifying your protocol family
in the place of the usual AF_INET.

-- 
#exclude <windows.h>

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

From: "aCiD fEiNd" <[EMAIL PROTECTED]>
Crossposted-To: 
comp.os.linux.advocacy,comp.os.ms-windows.advocacy,comp.os.ms-windows.nt.advocacy,comp.os.linux.networking,comp.os.linux.security,comp.os.ms-windows.networking.tcp-ip,alt.conspiracy.area51
Subject: Re: MS caught breaking wind
Date: Mon, 17 Apr 2000 20:10:52 +0100
Reply-To: "aCiD fEiNd" <[EMAIL PROTECTED]>

he he he he he



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

From: Mark McIntyre <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Mon, 17 Apr 2000 22:04:31 +0100
Reply-To: [EMAIL PROTECTED]

On Mon, 17 Apr 2000 10:31:01 -0400, Ron Natalie <[EMAIL PROTECTED]>
wrote:

>
>
>Mark McIntyre wrote:
>
>> 
>> >which in and of itself is not a pointer.
>> 
>> says who?
>
>Says the language, it's an literal of type int.  The null pointer constant
>only has meaning when compared/assigned-to a pointer.

I've forgotten the context, we've snipped so much but... if you mean
zero is a literal of type int hten ok. If you mean NULL is a literal
of type int then nope.

>> 
>> *sigh*. No I don't I mean the bit pattern of the value that NULL
>> preprocesses out into when the preprocessor runs through your code.
>> You are the one talking about a null pointer. I'm talking about the
>> null pointer constant.
>
>Frankly, you don't know the representation of anything in the C language, is
>the point.  A integer zero may not be encoded as a bunch of zero bits as far
>as the language is concerned.

Which is sort of pretty much my point...

Mark McIntyre

C- FAQ: http://www.eskimo.com/~scs/C-faq/top.html

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

From: Mark McIntyre <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Mon, 17 Apr 2000 22:09:16 +0100
Reply-To: [EMAIL PROTECTED]

On Sun, 16 Apr 2000 18:30:39 -0700, Erik Max Francis <[EMAIL PROTECTED]>
wrote:

>Mark McIntyre wrote:
>
>> What, in the _C_ standard, a definition of how processors work? Ho
>> hum.
>
>We are talking about what the C standard says about the matter, which is
>all that is of any concern when it comes to null pointers _in C_.

And the C standard says _what_ exactly about how processors work?

>
>> >Suppose we have a machine on which the void* null pointer is
>> >represented by the bit pattern 0xf0f0, the int* null pointer by
>> >0x1010, and the double* null pointer by 0x2020.  This program
>> >could be translated to simply store the bit pattern 0x1010 in x
>> >and 0x2020 in y.  Which of these is the representation of the
>> >null pointer constant?
>> 
>> eh?
>> 
>> None of them because by definition NULL is 0 or (void*)0.
>
>I suggest you read the C standard -- or at least the comp.lang.c FAQ --
>before you contribute to this subject any further.

Thanks. I haven't done that for oh, at least ten minutes. 

By the way, maybe you'd like to read n869 ss 6.3.2.3 para 3, and 7.17
before /you/ contribute any more. . 
Mark McIntyre

C- FAQ: http://www.eskimo.com/~scs/C-faq/top.html

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

From: "Sean Bose" <[EMAIL PROTECTED]>
Subject: Kernel Driver Module accessing a text file: How to?
Date: Mon, 17 Apr 2000 17:34:35 -0400

Hi
 I am trying to read and if possible write a text file from a Kernel
Driver module.
  It'll be great if someone can advise me on this.

thanks
  Sean
_________________________
Sean Bose
[EMAIL PROTECTED]




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

From: Erik Max Francis <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Mon, 17 Apr 2000 14:21:08 -0700

Mark McIntyre wrote:

> I've forgotten the context, we've snipped so much but... if you mean
> zero is a literal of type int hten ok. If you mean NULL is a literal
> of type int then nope.

Have you been reading this thread?  NULL (the macro) most certainly can
be defined as 0.

    #define NULL 0

is a strictly-conforming definition of NULL.

-- 
   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 | 970.161 Ms p.L. | 258 days left | &tSftDotIotE
 __
/  \ Whoever contends with the great sheds his own blood.
\__/ Sa'di

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

From: Ron Natalie <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Mon, 17 Apr 2000 17:22:24 -0400



Mark McIntyre wrote:
> 
> On Mon, 17 Apr 2000 10:31:01 -0400, Ron Natalie <[EMAIL PROTECTED]>
> wrote:
> 
> >
> >
> >Mark McIntyre wrote:
> >
> >>
> >> >which in and of itself is not a pointer.
> >>
> >> says who?
> >
> >Says the language, it's an literal of type int.  The null pointer constant
> >only has meaning when compared/assigned-to a pointer.
> 
> I've forgotten the context, we've snipped so much but... if you mean
> zero is a literal of type int hten ok. If you mean NULL is a literal
> of type int then nope.

The line you snipped off said "0"

And in C++ NULL can not have the void* cast in it.

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

From: Matthias Kleinmann <[EMAIL PROTECTED]>
Crossposted-To: 
uk.comp.os.linux,uklinux.help.newbies,comp.os.linux.development,comp.os.linux.questions,comp.os.linux.development.apps
Subject: Re: Put the lib into the libc?  (was: Re: Simple but...)
Date: Mon, 17 Apr 2000 23:24:16 +0200


> > Ok this is special and not too realistic, but maybe a general reason for
> > small libs.
>
> Hmm, running processes will be unaffected.  They already have the old
> lib mmap'ed in, and whatever happens on the fs won't change that.
> It's only when a new process is started that the new lib will be used.
[...]

I think you are right (man 8 ld.so). I think this is the way you do it:
 
1) Install the new lib (e.g in /usr/lib) without overwriting the old
one.
   This does not change anything on your system.

2) Run ldconfig (AFAIK you need a recent (not older then 2 years or so)
version if you do not want to stop the hole system) 
   This adds a new entry in /etc/ld.so.cache . The old lib is still in
the shared memory and keeps there until there is no program left that
uses the old lib. Any restarted program _may_ use the new lib (what
about version conflicts?)

If this is correct, indeed there is not a reel need for a seperated libm
(except the point Rich mentioned), since you can 'hot-plug' any new lib
- even the libc. If you have the source code of the program, there is
even less trouble since you may link the new lib statically.

[maybe we should reduce crossposting to comp.os.linux.development.* ...]



Matthias

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

From: Erik Max Francis <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Mon, 17 Apr 2000 14:32:52 -0700

Mark McIntyre wrote:

> Erik Max Francis wrote:
> 
> > Mark McIntyre wrote:
> >
> > > What, in the _C_ standard, a definition of how processors work? Ho
> > > hum.
> >
> > We are talking about what the C standard says about the matter,
> > which is all that is of any concern when it comes to null pointers
> > _in C_.
> 
> And the C standard says _what_ exactly about how processors work?

You're the one who brought up the internals of processors and registers,
which is irrelevant to what the C standard has to say about null
pointers.

> Thanks. I haven't done that for oh, at least ten minutes.

Maybe you should read it, then?

> By the way, maybe you'd like to read n869 ss 6.3.2.3 para 3, and 7.17
> before /you/ contribute any more. .

I'm quite familiar with the Standard.  The problem you are having is
that you are mixing up the characters you type to get a null pointer
constant with the actual internal representation of a null pointer.

-- 
   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 | 970.161 Ms p.L. | 258 days left | &tSftDotIotE
 __
/  \ Whoever contends with the great sheds his own blood.
\__/ Sa'di

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

From: David <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: MPROTECT
Date: Mon, 17 Apr 2000 23:57:45 +0200

"Arthur H. Gold" wrote:
> 
> David wrote:
> >
> > I can unmap code and data  pages, but if I change their access
> > permisions I enter into defunct state.
> That can certainly happen in a case where you can't get to code you'd
> need to run. It would throw a SIGSEGV, look for handler code to deal
> with the SIGSEGV, throw another one...and ultimately blow out the stack.
> >
> > strace no give me information. Simply say nothing. More, mprotect
> > function does not appear as a system call (like wait or fork).
> This sounds strange. You'll have to tell us more in order to get help (I
> don't think there's a clairvoyant among us).
> >
> > Any Idea?
> >
> > thaks in advance,
> > DTM
> 
> HTH,
> --ag
> 
> --
> Artie Gold, Austin, TX  (finger the cs.utexas.edu account for more info)
> mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED]
> --
> A: Look for a lawyer who speaks Aramaic...about trademark infringement.
EXACTLY, you are right, 
but I use sigaltstack to make stack sure.
AND i am sure that sigsegv function is not unmapped.

I dont know (I can't check it) if my stack blow out.

Any more idea ?

P.D.: I going to post strace output, to verify that some functions
doesnt appear.

thanks,
DTM

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

From: Barry Margolin <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Mon, 17 Apr 2000 21:52:15 GMT

In article <[EMAIL PROTECTED]>,
Mark McIntyre  <[EMAIL PROTECTED]> wrote:
>On Sun, 16 Apr 2000 08:31:36 -0400, Michael Rubenstein
><[EMAIL PROTECTED]> wrote:
>>Suppose we have a machine on which the void* null pointer is
>>represented by the bit pattern 0xf0f0, the int* null pointer by
>>0x1010, and the double* null pointer by 0x2020.  This program
>>could be translated to simply store the bit pattern 0x1010 in x
>>and 0x2020 in y.  Which of these is the representation of the
>>null pointer constant?
>
>eh? 
>
>None of them because by definition NULL is 0 or (void*)0. 

That's its representation in source code, not memory or processor
registers.  The C standard places no restrictions on the hardware
representation of null pointers.

-- 
Barry Margolin, [EMAIL PROTECTED]
Genuity, 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.

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


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

Reply via email to