|
Home > Archive > Unix Programming > February 2005 > Linux vs Solaris?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| puzzlecracker 2005-02-14, 5:54 pm |
| what are the [nontrivial] differences between Linux and Solaris?
| |
| puzzlecracker 2005-02-14, 5:54 pm |
|
Frank A. Uepping wrote:
> puzzlecracker wrote:
>
> Linux is free, Solaris not ;)
>
> /FAU
NONTRIVIAL
| |
| Frank A. Uepping 2005-02-14, 5:54 pm |
| puzzlecracker wrote:
> what are the [nontrivial] differences between Linux and Solaris?
Linux is free, Solaris not ;)
/FAU
| |
|
|
| Rich Teer 2005-02-14, 5:54 pm |
| On Mon, 14 Feb 2005, Frank A. Uepping wrote:
> puzzlecracker wrote:
>
> Linux is free, Solaris not ;)
You're behind the times. Solaris is free too.
--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming"
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
| |
| James Antill 2005-02-16, 5:57 pm |
| On Mon, 14 Feb 2005 19:56:02 +0000, Rich Teer wrote:
> On Mon, 14 Feb 2005, Frank A. Uepping wrote:
>
>
> You're behind the times. Solaris is free too.
I tried not to respond to this thread, as it seemed like obvious trolling
much like the "Which is better FreeBSD or Linux?" questions.
However, trying to diffuse the trolls: while arguing free/non-free isn't
a good statement there are differences in what you might call "openness":
1. opensolaris.org only contains a non-buildable dtrace code dump. Solaris
itself is _supposed_ to be a couple of months away. So the statement it's
not free will be behind the times in a couple of months.
2. Solaris will be the 6th major[1] "openunix", there are advantages to
not being the last to the table.
3. Solaris kernel code can't go into any of the other 5 major "openunix"
kernels, so it's not like people are going to work on FreeBSD/Linux and
OpenSolaris.
4. From the commercial support POV there is one provider for Solaris
support, whereas there are at least two for Linux. I don't see this
changing.
....obviously the above is going to change to some degree (for instance
when opensolaris.org has a full code dump on it), and a lot of what
happens will depend on decisions are the executive level in Sun (IMO) so
it's not really possible to say with 100% confidence what everything will
look like in 5 or 10 years ... but that was always true  .
There are also technical differences, but I don't have space in the
margin to describe them.
[1] Depending on how you count, I counted assuming: Linux,
(Net|Free|Open)BSD, Darwin
--
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/
| |
| Victor Wagner 2005-02-16, 5:57 pm |
| James Antill <james-netnews@and.org> wrote:
> On Mon, 14 Feb 2005 19:56:02 +0000, Rich Teer wrote:
> puzzlecracker wrote: >> >> > what are the [nontrivial]
> differences between Linux and Solaris? >> Linux is free,
> Solaris not ;) > > You're behind the times. Solaris is free
> too.
> I tried not to respond to this thread, as it seemed like
> obvious trolling much like the "Which is better FreeBSD or
> Linux?" questions. However, trying to diffuse the trolls:
It is interesting that NO ONE read question carefully.
Original poster have asked about "What are differences", not "What is
better".
In the programming newsgroup it should be first read as "What are
TECHINICAL differences which I should take into account trying to write
program which runs on both Linux and Solaris"
Really, today there are surprisingly few differences between Linux and
Solaris. They both use same executable file format - ELF (which is as
far as I know, originated on Solaris), both are more or less POSIX
compliant.
I've very little trouble porting our big project from Linux x86 to
Solaris x86. Solaris-Sparc was another matter, because it is different
architecture of processor, and you have to be careful with alignment of
variables. Most x86-originated code doesn't care whether address of
variable with sizeof()=x is multiple of x. On Sparc you'll get SIGBUS if
you violate this rule.
As for operating system differences -
speaking of userland tools such as shell, fileutils etc, I cannot
tolerate Solaris unless it has GNU bash, GNU make and other GNU tools
installed (they are mostly included on Software Companion CD, and if
not, you can get ready to use packages from sunfreeware.com)
Speaking of programming - solaris has STREAMS, Linux has only berkeley
socket interface, solaris has better multithreading, but Linux - more lightweight fork(), and it is feasable to use multiprocess model on Linux
where multithreading is recommended on Solaris.
There is some differences regarding to distribution of functions between
libraries. On Linux there is no libsocket - all the socket related
functions are in libc, when on Solaris you have sometimes to link with
-lsocket explicitely.
These minor problems can be easily solved by reading manual pages.
There are some differences in system pathes - solaris use /usr/openwin
and /usr/dt where Linux use /usr/X11R6. It is quite easy to master too,
--
...you could spend *all day* customizing the title bar. Believe me. I
speak from experience.
-- Matt Welsh
| |
| Nils Weller 2005-02-16, 5:57 pm |
| In article <cv04q4$s82$1@wagner.wagner.home>, Victor Wagner wrote:
> I've very little trouble porting our big project from Linux x86 to
> Solaris x86. Solaris-Sparc was another matter, because it is different
> architecture of processor, and you have to be careful with alignment of
> variables. Most x86-originated code doesn't care whether address of
> variable with sizeof()=x is multiple of x. On Sparc you'll get SIGBUS if
^^^^^^^^^^^^^^^^^^^^^^^^^^
> you violate this rule.
^^^^^^^^^^^^^^^^^^^^^
From an application's perspective, this behavior is not necessarily to
be expected even on architectures that cannot deal with misaligned
memory access. Linux in particular catches such bus errors and tries to
handle the misaligned load/store on behalf of the application, in a
completely transparent manner (well, unless you count the performance
penality you get for that.)
See linux/arch/sparc/kernel/unaligned.c for the SPARC implementation.
(Another system that does this is Tru64 UNIX. Both systems optionally
print an error message to the console when such a fault occurs.)
--
My real email address is ``nils<at>gnulinux<dot>nl''
| |
| Måns Rullgård 2005-02-16, 5:57 pm |
| Nils Weller <me@privacy.net> writes:
> In article <cv04q4$s82$1@wagner.wagner.home>, Victor Wagner wrote:
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
> ^^^^^^^^^^^^^^^^^^^^^
>
> From an application's perspective, this behavior is not necessarily to
> be expected even on architectures that cannot deal with misaligned
> memory access. Linux in particular catches such bus errors and tries to
> handle the misaligned load/store on behalf of the application, in a
> completely transparent manner (well, unless you count the performance
> penality you get for that.)
>
> See linux/arch/sparc/kernel/unaligned.c for the SPARC implementation.
>
> (Another system that does this is Tru64 UNIX. Both systems optionally
> print an error message to the console when such a fault occurs.)
In my opinion, any program that does such accesses is badly broken in
the first place. There is simply no excuse for not doing it right.
--
Måns Rullgård
mru@inprovide.com
| |
| Nils Weller 2005-02-16, 5:57 pm |
| In article <yw1xfyzw48r9.fsf@ford.inprovide.com>, Måns Rullgård wrote:
> Nils Weller <me@privacy.net> writes:
>
>
> In my opinion, any program that does such accesses is badly broken in
> the first place. There is simply no excuse for not doing it right.
>
I agree entirely. But there are so many applications broken in this way
out there that it feels very good to have an operating system that tries
to support your attempts at running them, instead of punishing you for
the goof-ups of someone else. You may never get such an (possibly
otherwise correctly coded) application to work without spending a
considerable amount of time debugging it by yourself, or trying to
convince the maintainer to fix it for you, neither of which ways is
likely to be worth your time, or even guaranteed to succeed.
Perhaps one could say that this feature is great for an ``end user'' of
a program, and bad for the developer (because it may prevent him from
spotting the bug.) But even this negative conclusion on the developer's
side does not seem quite right because the system prints a warning
message telling you about the illegal access, after all!
(I got a lot of misaligned memory access messages when running open
source apps like gcc on Tru64 UNIX, and I just found it cool that these
problems didn't get into my way.)
--
My real email address is ``nils<at>gnulinux<dot>nl''
| |
| Måns Rullgård 2005-02-16, 5:57 pm |
| Nils Weller <me@privacy.net> writes:
>
> I agree entirely. But there are so many applications broken in this way
> out there that it feels very good to have an operating system that tries
> to support your attempts at running them, instead of punishing you for
> the goof-ups of someone else. You may never get such an (possibly
> otherwise correctly coded) application to work without spending a
> considerable amount of time debugging it by yourself, or trying to
> convince the maintainer to fix it for you, neither of which ways is
> likely to be worth your time, or even guaranteed to succeed.
>
> Perhaps one could say that this feature is great for an ``end user'' of
> a program, and bad for the developer (because it may prevent him from
> spotting the bug.) But even this negative conclusion on the developer's
> side does not seem quite right because the system prints a warning
> message telling you about the illegal access, after all!
Your points are valid. However, not many programs have these errors
after all, at least not many worth using.
> (I got a lot of misaligned memory access messages when running open
> source apps like gcc on Tru64 UNIX,
That's odd. Just about the only program I've seen having these
problems on Tru64 was Quake.
--
Måns Rullgård
mru@inprovide.com
| |
| Chuck Dillon 2005-02-17, 5:54 pm |
| Måns Rullgård wrote:
> Nils Weller <me@privacy.net> writes:
>
>
> In my opinion, any program that does such accesses is badly broken in
> the first place. There is simply no excuse for not doing it right.
>
I wouldn't paint such a broad brush. I agree that if one is attempting
to develop for optimal performance and/or for portability one must
account for known hardware based issues/limitations. But I don't think
it's reasonable to consider all software that required neither to be
broken. Especially if the author is not the one who decided it needed
to be ported.
I think it's much more reasonable to argue that systems that require
software to accommodate their addressing limitations to run are broken.
I would think it worth considering, by default, letting the software
run with degraded performance and provide a mechanism to enforce
alignment. Similar to the exception mechanism in floating point.
-- ced
--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.
| |
| Måns Rullgård 2005-02-17, 5:54 pm |
| Chuck Dillon <spam@nimblegen.com> writes:
> Måns Rullgård wrote:
>
> I wouldn't paint such a broad brush. I agree that if one is
> attempting to develop for optimal performance and/or for portability
> one must account for known hardware based issues/limitations. But I
> don't think it's reasonable to consider all software that required
> neither to be broken. Especially if the author is not the one who
> decided it needed to be ported.
The only way these accesses happen is through bad programming style.
I have *never* had to do anything special to avoid unaligned accesses.
When using proper types for your data, you simply won't get any
unaligned pointers to worry about.
There are situations where unaligned data makes sense, but someone who
doesn't know to deal properly with it shouldn't be writing such
programs in the first place.
--
Måns Rullgård
mru@inprovide.com
| |
| Rich Teer 2005-02-17, 5:54 pm |
| On Thu, 17 Feb 2005, Måns Rullgård wrote:
> There are situations where unaligned data makes sense, but someone who
> doesn't know to deal properly with it shouldn't be writing such
> programs in the first place.
I agree with some of Chuck's points, but I'm with you here. This
is basically in the same category of dereferncing NULL pointers.
Doing so is a bug, yet some platforms (e.g., HPUX a few years ago)
would actually not flag as an error by default.
--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming"
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
| |
| Casper H.S. Dik 2005-02-17, 5:54 pm |
| Nils Weller <me@privacy.net> writes:
>From an application's perspective, this behavior is not necessarily to
>be expected even on architectures that cannot deal with misaligned
>memory access. Linux in particular catches such bus errors and tries to
>handle the misaligned load/store on behalf of the application, in a
>completely transparent manner (well, unless you count the performance
>penality you get for that.)
You'd certain violated a C rule or two on the way.
Solaris does allow for misaligned accesses if so specified,
just like:
>See linux/arch/sparc/kernel/unaligned.c for the SPARC implementation.
Which runs about 100x slower than a proper aligned access, which
is ample reason not to enable it by default.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| Nils Weller 2005-02-17, 5:54 pm |
| In article <4214daf9$0$28978$e4fe514c@news.xs4all.nl>, Casper H.S Dik wrote:
> Nils Weller <me@privacy.net> writes:
>
>
> You'd certain violated a C rule or two on the way.
Nobody argued that such applications are correct at all. And though I've
been defending instruction emulation for a bit now, I joined this thread
with the sole intention of pointing out that misaligned memory access on
SPARC does not *invariably* cause your application to receive SIGBUS/
crash.
> Solaris does allow for misaligned accesses if so specified,
> just like:
>
Though I don't use Solaris much, this is interesting to know. Sun's
compiler isn't available to everyone, however, and I can't see anything
equivalent to Sun's -misaligned compiler option in gcc. I suppose it's
not too much to expect from a determined technical user to add ``ta 6''
inline assembly instructions to the misbehaved program by hand, but the
availability of this solution is far from obvious. And a non-technical
user without (or even with) Sun's compiler would probably never get it
to work.
[vbcol=seagreen]
> Which runs about 100x slower than a proper aligned access, which
> is ample reason not to enable it by default.
The instruction emulation code will only affect buggy applications, and
those applications usually leave you no convenient choice but to use it.
As I've already said: Given the choice between running such a program a
little more slowly than possible and having to debug or replace it, I'd
certainly pick the former.
Remember that a (typical) misbehaved application also does other things
besides constructing and accessing misaligned memory addresses. If the
instruction emulation stuff only has to execute every once in a while,
the program may still be quite usable. In any case, running such
programs with emulation turned on is worth a try, and you can still try
to fix it or find an alternative later on should the performance turn
out to be unacceptable (avoid premature optimization! ;-))
(And let me repeat that I don't advocate developing software that relies
on misaligned memory access; That's certainly not what the Linux and
Solaris instruction emulation is intended to be used for, anyway.)
--
My real email address is ``nils<at>gnulinux<dot>nl''
| |
| Andrei Voropaev 2005-02-20, 6:19 pm |
| On 2005-02-17, Rich Teer <rich.teer@rite-group.com> wrote:
> On Thu, 17 Feb 2005, Måns Rullgård wrote:
>
>
> I agree with some of Chuck's points, but I'm with you here. This
> is basically in the same category of dereferncing NULL pointers.
> Doing so is a bug, yet some platforms (e.g., HPUX a few years ago)
> would actually not flag as an error by default.
>
Hm. And why dereferencing NULL pointers should be a bug? In theory I can
mmap chunk of memory at position 0. (I think I can do it also in
practice on linux). Maybe I miss something in your point?
--
Minds, like parachutes, function best when open
| |
| Måns Rullgård 2005-02-20, 6:19 pm |
| Andrei Voropaev <avorop@mail.ru> writes:
> On 2005-02-17, Rich Teer <rich.teer@rite-group.com> wrote:
>
> Hm. And why dereferencing NULL pointers should be a bug?
What had you expected to find at that address? Since NULL is commonly
used to indicate an invalid pointer, it would be rather silly to place
real data there.
> In theory I can mmap chunk of memory at position 0. (I think I can
> do it also in practice on linux). Maybe I miss something in your
> point?
Yes, it's possible to map memory there. I've even done it myself, but
only for debugging purposes.
--
Måns Rullgård
mru@inprovide.com
| |
| Floyd L. Davidson 2005-02-20, 6:19 pm |
| Måns Rullgård <mru@inprovide.com> wrote:
>Andrei Voropaev <avorop@mail.ru> writes:
>
Specifically because the C Standard says so.
[vbcol=seagreen]
>What had you expected to find at that address? Since NULL is commonly
>used to indicate an invalid pointer, it would be rather silly to place
>real data there.
NULL is *guaranteed* *not* to point at any valid object. And it
is not necessarily "located" at address 0.
Specifically, NULL is a macro, and evaluates to a "null pointer
constant". When any "null pointer constant" is converted to a
pointer, e.g., using a cast, "the resulting pointer, called a
null pointer, is guaranteed to compare unequal to a pointer to
any object or function." (C99, 6.2.3.2)
>
>Yes, it's possible to map memory there. I've even done it myself, but
>only for debugging purposes.
However, that is *not* necessarily dereferencing a "NULL
pointer". It is merely dereferencing a pointer to address 0,
which may or may not be valid.
If you do it by dereferencing NULL (or any "null pointer"), it
might well work (on every machine I know of...) but it results
in undefined behavior, which is essentially a bug by definition.
--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com
| |
| Andrei Voropaev 2005-02-20, 6:19 pm |
| On 2005-02-18, Floyd L. Davidson <floyd@barrow.com> wrote:
> Måns Rullgård <mru@inprovide.com> wrote:
[...][vbcol=seagreen]
>
> Specifically because the C Standard says so.
>
>
> NULL is *guaranteed* *not* to point at any valid object. And it
> is not necessarily "located" at address 0.
>
> Specifically, NULL is a macro, and evaluates to a "null pointer
> constant". When any "null pointer constant" is converted to a
> pointer, e.g., using a cast, "the resulting pointer, called a
> null pointer, is guaranteed to compare unequal to a pointer to
> any object or function." (C99, 6.2.3.2)
>
>
> However, that is *not* necessarily dereferencing a "NULL
> pointer". It is merely dereferencing a pointer to address 0,
> which may or may not be valid.
>
> If you do it by dereferencing NULL (or any "null pointer"), it
> might well work (on every machine I know of...) but it results
> in undefined behavior, which is essentially a bug by definition.
Aha. I think I got the point. NULL and pointer == 0x000000000 is not the
same thing (even though they might be equal arithmetically . I guess
my problem here was the thinking that NULL stands for alias for (void *)0.
Further on I should consider NULL only as "invalid pointer"
--
Minds, like parachutes, function best when open
| |
|
|
| Casper H.S. Dik 2005-02-20, 6:19 pm |
| Andrei Voropaev <avorop@mail.ru> writes:
>So, silly or not, it happens sometimes. And I guess it was silly to
>define NULL as (void*)0 in the first place Maybe (void*)-1 would be
>better? Of course it wouldn't be possible to say if(!ptr) ... And of
>course I don't know the whole story.
You're confusing implemenation with the language syntax; for all you
care
void *ptr = 0;
could assign an "all ones" patters to "ptr" and not an all zeros
pattern. And !ptr would still work as it's defined as (ptr != NULL)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| Floyd L. Davidson 2005-02-20, 6:19 pm |
| Andrei Voropaev <avorop@mail.ru> wrote:
>
>Oh yea. But when we hit virtual memory limit for 32-bit application, as a
>quick fix I had to mmap the chunk at this position. It was a hack of
>course. But as everything temporary it is still working in our system
>(The application is old and stupid in design, but it's been working all
>these years and the management is very reluctant in replacing it with
>better program)
>
>So, silly or not, it happens sometimes. And I guess it was silly to
>define NULL as (void*)0 in the first place Maybe (void*)-1 would be
>better? Of course it wouldn't be possible to say if(!ptr) ... And of
>course I don't know the whole story.
The C Standard specifies that the NULL macro "expands to an
implementation-defined null pointer constant;" (Section 7.17).
A "null pointer constant" is defined in Section 6.3.2.3, so
that tells us what the NULL macro can actually be:
"3 An integer constant expression with the value 0, or such
an expression cast to type void *, is called a null
pointer constant.55) If a null pointer constant is
converted to a pointer type, the resulting pointer,
called a null pointer, is guaranteed to compare unequal
to a pointer to any object or function.
4 Conversion of a null pointer to another pointer type
yields a null pointer of that type. Any two null
pointers shall compare equal."
Which is to say that either of the two most commonly used
macro definitions for NULL are correct:
#define NULL ((void *)0)"
#define NULL 0
Note that "((void *)-1)" can never be a valid definition,
because that does not expand to a null pointer constant. Also
be aware that there are distinct null pointers for each data
type (char, int, long, etc.).
So... There are three *different* devices: the NULL macro, the
"null pointer constant", and the "null pointer".
NULL is a macro, a source code device, defined in the standard
headers. The macro NULL expands to a "null pointer constant"
in the preprocessor stage.
"Null pointer constant" is also purely a *source code device*.
A "null pointer constant", when used in a pointer context, is
converted to a "null pointer" object when compiled.
A "null pointer" is an implementation defined object. Each
compiler implementation decides exactly what represents a "null
pointer" for each data type. The C Standard says the
implementation will guarantee that a "null pointer" never
compares equal to the address of any valid object, and will
always compare equal when compared either to 0 or to any other
"null pointer" type.
Note that the requirement to compare equal to 0 does *not* mean
its value is 0; it just means the compiler has to know what it
is, and say they are equal when compared. The actual object
might not only not be a 0, but each type (char, int, long, etc)
could have a different value!
The problem with all of the above is that while the Standard
makes it possible for each type to have a different
representation and value for it's "null pointer", the simple
fact is that the only commonly used representation is a pointer
with all bits cleared (i.e., 0). Hence in almost all cases
treating it as if it is equal to 0 will not cause ill
behavior... until you port it to some machine that doesn't do
it the easy way.
To summarize...
int *x = (void *) 0; /* x contains a null pointer */
int *y = 0; /* y contains a null pointer */
/* neither of the above are valid pointers to location 0 */
int a = 0;
int *b = (void *) a; /* b contains a valid pointer to location 0 */
int *c = a; /* c contains a valid pointer to location 0 */
/* neither of the above are null pointers */
(But in fact all of the above will probably do exactly what you
would expect in every instance, even though half of it would be
"undefined behavior".)
--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com
| |
| Chuck Dillon 2005-02-20, 6:19 pm |
| Måns Rullgård wrote:
> Chuck Dillon <spam@nimblegen.com> writes:
>
>
>
>
> The only way these accesses happen is through bad programming style.
Not if you include usage of mmap'd data, and to some extent shared
memory segments. The particular case that comes to mind is mmap'ing a
file of a standard format in which the format is not inherently aligned
to comply with your system's addressing limitations. Or are you
suggesting that all file formats that don't ensure long word alignment
are broken?
> I have *never* had to do anything special to avoid unaligned accesses.
> When using proper types for your data, you simply won't get any
> unaligned pointers to worry about.
Neight have I except when dealing with mmap'd or shared memory cases.
We benefit from the allocation functions and compilers that know how to
avoid system limitations.
It seems you consider SIGBUS as a debugging aide. I couldn't agree
more that developers need to know how to properly manage data
structures and that it's good for the system to send SIGSEGV if they
mangle memory or mismanage pointers. But SIGBUS is not a reliable way
to report on or catch such problems. SIGBUS is an artificial and IMHO
from the developer's perspective arbitrary limitation that we accept
for the sake of faster execution.
-- ced
>
> There are situations where unaligned data makes sense, but someone who
> doesn't know to deal properly with it shouldn't be writing such
> programs in the first place.
>
--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.
| |
| Måns Rullgård 2005-02-20, 6:19 pm |
| Chuck Dillon <spam@nimblegen.com> writes:
> Måns Rullgård wrote:
>
>
> Not if you include usage of mmap'd data, and to some extent shared
> memory segments. The particular case that comes to mind is mmap'ing a
> file of a standard format in which the format is not inherently
> aligned to comply with your system's addressing limitations. Or are
> you suggesting that all file formats that don't ensure long word
> alignment are broken?
No, those are the valid cases. However, the programmer should know
it, and tell the compiler he is doing unaligned accesses.
>
> Neight have I except when dealing with mmap'd or shared memory
> cases. We benefit from the allocation functions and compilers that
> know how to avoid system limitations.
>
> It seems you consider SIGBUS as a debugging aide. I couldn't agree
> more that developers need to know how to properly manage data
> structures and that it's good for the system to send SIGSEGV if they
> mangle memory or mismanage pointers. But SIGBUS is not a reliable way
> to report on or catch such problems. SIGBUS is an artificial and IMHO
> from the developer's perspective arbitrary limitation that we accept
> for the sake of faster execution.
To SIGBUS or not is debatable, but this doesn't alter the fact that
requiring aligned accesses makes for faster CPUs.
--
Måns Rullgård
mru@inprovide.com
| |
| Dmitry Karasik 2005-02-20, 6:19 pm |
| Hi Floyd!
Floyd> "3 An integer constant expression with the value 0, or such an
Floyd> expression cast to type void *, is called a null pointer
Floyd> constant.55) If a null pointer constant is converted to a pointer
Floyd> type, the resulting pointer, called a null pointer, is guaranteed
Floyd> to compare unequal to a pointer to any object or function.
Floyd> 4 Conversion of a null pointer to another pointer type yields a
Floyd> null pointer of that type. Any two null pointers shall compare
Floyd> equal."
Just out of sheer curiosity, does there exist a system and/or a C compiler
where NULL (yeah, "null pointer constant") is not zero?
/dmitry
| |
| Bjorn Reese 2005-02-20, 6:19 pm |
| Dmitry Karasik wrote:
> Just out of sheer curiosity, does there exist a system and/or a C compiler
> where NULL (yeah, "null pointer constant") is not zero?
I have not looked into the details, but the pointers of the PowerPC AS
processor have a tag bit that identifies them as pointers. If data
overwrites the pointer, e.g. as part of a buffer overflow, the tag bit
is cleared, and the pointer cannot be used as a pointer anymore.
I would assume that the null pointer also has the tag bit set, thus
making the bit pattern of the null pointer consist of at least one
non-zero bit.
--
mail1dotstofanetdotdk
|
|
|
|
|