[31792] in Perl-Users-Digest
Perl-Users Digest, Issue: 3055 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jul 31 18:09:24 2010
Date: Sat, 31 Jul 2010 15:09:07 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 31 Jul 2010 Volume: 11 Number: 3055
Today's topics:
Re: Can this be done (by a noob :)) <ben@morrow.me.uk>
Re: Can this be done (by a noob :)) <m@rtij.nl.invlalid>
Re: Can this be done (by a noob :)) <hjp-usenet2@hjp.at>
Re: Can this be done (by a noob :)) <tadmc@seesig.invalid>
Re: Can this be done (by a noob :)) <jurgenex@hotmail.com>
Re: Can this be done (by a noob :)) <jurgenex@hotmail.com>
Re: Can this be done (by a noob :)) <jurgenex@hotmail.com>
Re: Can this be done (by a noob :)) <sherm.pendley@gmail.com>
Re: Can this be done (by a noob :)) <ben@morrow.me.uk>
Re: Can this be done (by a noob :)) <ben@morrow.me.uk>
Re: Can this be done (by a noob :)) <jurgenex@hotmail.com>
Re: Can this be done (by a noob :)) <jurgenex@hotmail.com>
Re: Can this be done (by a noob :)) <ben@morrow.me.uk>
Re: How can I tell if a perl interpreter was built for <hjp-usenet2@hjp.at>
Re: How can I tell if a perl interpreter was built for <sherm.pendley@gmail.com>
Re: If Perl is compiled on a 32-bit system, and the sys <hjp-usenet2@hjp.at>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 31 Jul 2010 19:16:56 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Can this be done (by a noob :))
Message-Id: <ot5ei7-elm2.ln1@osiris.mauzo.dyndns.org>
Quoth Jürgen Exner <jurgenex@hotmail.com>:
> "Thomas Andersson" <thomas@tifozi.net> wrote:
> >Jürgen Exner wrote:
>
> >The loop has been rewritten and workds as intended now, using last to exit
> >on the two possible conditions. Now look like this:
> >
> >while (1) {
>
> Ouch, this hurts! Usually this line indicates a deamon which is never
> supposed to terminate.
Not necessarily. (It might be more idomatic to spell it for(;;), but
that's beside the point.)
> > my $page = get "$pbase?page=$pcnt&pid=$pid";
> > last if $page =~/No sorties/;
> > # Store grabbed webpage into the file
> > append_file( "c:/scr/$pid.txt", $page ) ;
> > last if $page =~/"sid=$lproc"/;
> > # Update page number and grab next.
> > $pcnt++;
> >};
>
> Why not move the loop condition into the loop condition?
>
> my $page = get "$pbase?page=$pcnt&pid=$pid";
> while ((!$page =~/No sorties/) and (!$page =~/"sid=$lproc"/)) {
> append_file( "c:/scr/$pid.txt", $page );
> $pcnt++;
> $page = get "$pbase?page=$pcnt&pid=$pid";}
> }
Yuck, you've just done the 'get' twice. DRY is *far* more important than
'structured programming', unless you're going to attempt to prove the
program's correctness.
> Yes, I know the condition could be formulated better, but I transformed
> it as little as possible to demonstrate how the exit() cond can
> trivially be moved into the while() cond.
Not without duplication of code.
Ben
------------------------------
Date: Sat, 31 Jul 2010 20:27:58 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Can this be done (by a noob :))
Message-Id: <ei6ei7-slo.ln1@news.rtij.nl>
On Sat, 31 Jul 2010 09:35:27 -0700, sln wrote:
> Beware that if $page is generated html, using a regex on it as in
>
> $page !~ /No sorties/i
> $page =~ /$sid_rx/
>
> can be done, but only after it is parsed.
Why? Are you afraid the same text occurs inside a tag?
> It can be parsed with regex's
However, that is a bad isea generally.
HTH,
M4
------------------------------
Date: Sat, 31 Jul 2010 21:19:20 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Can this be done (by a noob :))
Message-Id: <slrni58tpp.rvk.hjp-usenet2@hrunkner.hjp.at>
On 2010-07-31 16:42, Jürgen Exner <jurgenex@hotmail.com> wrote:
> "Thomas Andersson" <thomas@tifozi.net> wrote:
>>The loop has been rewritten and workds as intended now, using last to exit
>>on the two possible conditions. Now look like this:
>>
>>while (1) {
>
> Ouch, this hurts! Usually this line indicates a deamon which is never
> supposed to terminate.
Maybe. Personally I never use while (1), I prefer for (;;) instead.
But neither implies that the loop is really infinite: It may (and often
is) be left with last or return.
>> my $page = get "$pbase?page=$pcnt&pid=$pid";
>> last if $page =~/No sorties/;
>> # Store grabbed webpage into the file
>> append_file( "c:/scr/$pid.txt", $page ) ;
>> last if $page =~/"sid=$lproc"/;
>> # Update page number and grab next.
>> $pcnt++;
>>};
>
> Why not move the loop condition into the loop condition?
>
> my $page = get "$pbase?page=$pcnt&pid=$pid";
> while ((!$page =~/No sorties/) and (!$page =~/"sid=$lproc"/)) {
> append_file( "c:/scr/$pid.txt", $page );
> $pcnt++;
> $page = get "$pbase?page=$pcnt&pid=$pid";}
> }
>
> Yes, I know the condition could be formulated better, but I transformed
> it as little as possible to demonstrate how the exit() cond can
> trivially be moved into the while() cond.
You also demonstrated how easy it is to inadvertently change the logic
in the process. Thomas' code exited *after* saving the page containing
sid=$lproc, yours exits *before* saving it. I don't know which one is
correct, but they are definitely not the same.
I also strongly disagree that it is a good thing to transform a loop of
the form
for (;;) {
get data;
last unless condition;
process data;
}
into
get data;
while (condition) {
process data;
get data;
}
It duplicates the "get data" part which makes it easy to introduce bugs
by only changing one of the parts. Perl has "next" and "last" for a
reason. Use them.
In many cases both the duplication and the use of "last" can be avoided
by using a function call:
sub get_data {
get data;
return condition;
}
while (get_data()) {
process data;
}
But that doesn't always work. Among the nice properties of last and next
is that they can be easily cascaded:
while (get_data()) {
next unless condition1;
process data;
next unless condition2;
process data some more;
next unless condition3;
a little more and we are done;
}
> BTW: space characters are very cheap, I just saw a them on sale at
> Costco. Fell free to use as many as you like to make your code more
> readable.
Full ACK.
hp
------------------------------
Date: Sat, 31 Jul 2010 14:31:07 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Can this be done (by a noob :))
Message-Id: <slrni58ubk.od0.tadmc@tadbox.sbcglobal.net>
Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth "Thomas Andersson" <thomas@tifozi.net>:
>> > Also: get into the habit, now, of keeping you filehandles in proper
>> > variables. It will make life easier later.
>> >
>> > open my $FILE, ">", "..." or ...;
>> But if I createa variable of the filehandler like this,
^
^
> Yes, you are misunderstanding. If you create $FILE like that, it will
> contain a filehandle.
Note that these are called a "filehandle", without an "r".
You should probably avoid using the word "handler" unless you
are talking about handlers. That is, the term has a particular
meaning to programmers:
http://en.wikipedia.org/wiki/Event_handler
http://en.wikipedia.org/wiki/Signal_handler
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Sat, 31 Jul 2010 12:32:35 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Can this be done (by a noob :))
Message-Id: <svt856p72rnbn8p6rkbdu823kt966gpo9j@4ax.com>
Sherm Pendley <sherm.pendley@gmail.com> wrote:
>Jürgen Exner <jurgenex@hotmail.com> writes:
>
>> If this is the end condition for the loop then it would help even more
>> if your put it in the condition for the loop.
>>
>> while (........ and ($page ne $endstring)) {
>
>It's a judgement call. Sometimes, especially if there are several con-
>ditions, it can make more sense to use last:
>
> while(foo && bar && baz)
>
> while(1) {
> last unless foo;
> last unless bar;
> last unless baz;
> ...
> }
>
>Which form to use is best judged on a case-by-case basis, with the
>goal being readability.
I would almost agree. But when _I_ see a while() loop, then I am looking
at the while() condition to determine, under which condition the loop is
being executed and also to determine which post condition will hold true
after the loop has terminated.
Personally I am very much in favour of having one entry and one exit
from a loop rather than searching for an unknown number of exit points
scattered somewhere deep down in the who-knows-how-long loop body. It
just makes reasoning about the loop a lot easier.
But it's certainly a matter of style, at least as long as you don't try
to do any formal program verification. Each additional exit point adds
another proof requirement.
jue
------------------------------
Date: Sat, 31 Jul 2010 12:36:15 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Can this be done (by a noob :))
Message-Id: <sju8565qbhrjiu4mfenfc6e6si7g9s3rlp@4ax.com>
Martijn Lievaart <m@rtij.nl.invlalid> wrote:
>On Sat, 31 Jul 2010 09:35:27 -0700, sln wrote:
>> Beware that if $page is generated html, using a regex on it as in
[...]
>> It can be parsed with regex's
>
>However, that is a bad isea generally.
Or more to the point: parsing HTML, which is _context-free_, using true
_regular_ expressions is impossible.
And even using the much more powerful enhanced REs from Perl is nothing
a sane mind would attempt.
jue
------------------------------
Date: Sat, 31 Jul 2010 12:42:06 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Can this be done (by a noob :))
Message-Id: <dsu856pn6suso3retegjb3bo0tm5i7199c@4ax.com>
Ben Morrow <ben@morrow.me.uk> wrote:
>> Why not move the loop condition into the loop condition?
>>
>> my $page = get "$pbase?page=$pcnt&pid=$pid";
>> while ((!$page =~/No sorties/) and (!$page =~/"sid=$lproc"/)) {
>> append_file( "c:/scr/$pid.txt", $page );
>> $pcnt++;
>> $page = get "$pbase?page=$pcnt&pid=$pid";}
>> }
>
>Yuck, you've just done the 'get' twice. DRY is *far* more important than
>'structured programming', unless you're going to attempt to prove the
>program's correctness.
>
>> Yes, I know the condition could be formulated better, but I transformed
>> it as little as possible to demonstrate how the exit() cond can
>> trivially be moved into the while() cond.
>
>Not without duplication of code.
Well, fine, then just move the get() call into the condition itself:
while (($page = get "$pbase?page=$pcnt&pid=$pid")
and (!$page =~/No sorties/)
and (!$page =~/"sid=$lproc"/)) {
Personally I don't particularly like this approach because the get()
doesn't contribute to the condition and exists only for its side effect,
but there is no code duplication any more.
jue
------------------------------
Date: Sat, 31 Jul 2010 15:47:37 -0400
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: Can this be done (by a noob :))
Message-Id: <m239uzigbq.fsf@sherm.shermpendley.com>
Jürgen Exner <jurgenex@hotmail.com> writes:
> Sherm Pendley <sherm.pendley@gmail.com> wrote:
>>
>> while(1) {
>> last unless foo;
>> last unless bar;
>> last unless baz;
>> ...
>> }
>>
>>Which form to use is best judged on a case-by-case basis, with the
>>goal being readability.
>
> I would almost agree. But when _I_ see a while() loop, then I am looking
> at the while() condition to determine, under which condition the loop is
> being executed and also to determine which post condition will hold true
> after the loop has terminated.
> Personally I am very much in favour of having one entry and one exit
> from a loop rather than searching for an unknown number of exit points
> scattered somewhere deep down in the who-knows-how-long loop body.
I think we agree more than not - note that I grouped the conditionals
at the top of the loop body, with the ellipses representing additional
code appearing after them. I wouldn't scatter them throughout the loop
body, unless I had a *very* good reason for doing so.
sherm--
--
Sherm Pendley <www.shermpendley.com>
<www.camelbones.org>
Cocoa Developer
------------------------------
Date: Sat, 31 Jul 2010 20:58:21 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Can this be done (by a noob :))
Message-Id: <trbei7-icn2.ln1@osiris.mauzo.dyndns.org>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> On 2010-07-31 16:42, Jürgen Exner <jurgenex@hotmail.com> wrote:
> > "Thomas Andersson" <thomas@tifozi.net> wrote:
> >>The loop has been rewritten and workds as intended now, using last to exit
> >>on the two possible conditions. Now look like this:
> >>
> >>while (1) {
> >
> > Ouch, this hurts! Usually this line indicates a deamon which is never
> > supposed to terminate.
>
> Maybe. Personally I never use while (1), I prefer for (;;) instead.
> But neither implies that the loop is really infinite: It may (and often
> is) be left with last or return.
Actually it will *always* be left in some way, if only due to the heat
death of the Universe... :)
To me while (1) and for (;;) imply 'I don't yet know when or why this
loop will terminate'. Since this is often the case, they are useful
constructions. (It may (or may not) be worth noting that Perl 6 has a
dedicated flow-control keyword, 'loop { ... }', for infinite loops.)
Ben
------------------------------
Date: Sat, 31 Jul 2010 21:05:36 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Can this be done (by a noob :))
Message-Id: <g9cei7-icn2.ln1@osiris.mauzo.dyndns.org>
Quoth Jürgen Exner <jurgenex@hotmail.com>:
>
> I would almost agree. But when _I_ see a while() loop, then I am looking
> at the while() condition to determine, under which condition the loop is
> being executed and also to determine which post condition will hold true
> after the loop has terminated.
> Personally I am very much in favour of having one entry and one exit
> from a loop rather than searching for an unknown number of exit points
> scattered somewhere deep down in the who-knows-how-long loop body. It
> just makes reasoning about the loop a lot easier.
To my mind a who-knows-how-long loop body (by which I mean anything more
than about a screenful) is a mistake in and of itself. Most of the code
should be moved into functions, so that seeing when the loop might
finish is easy. And, of course, said functions should (almost) *never*
use the fact you can call 'last' to exit a loop somewhere further up the
call stack.
> But it's certainly a matter of style, at least as long as you don't try
> to do any formal program verification. Each additional exit point adds
> another proof requirement.
I don't know much about proving programs, but do additional exit points
really make it any harder than stuffing everything into the conditional?
Either way, you end up having to deal with the complexity of the
algorithm somewhere.
Ben
------------------------------
Date: Sat, 31 Jul 2010 13:22:46 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Can this be done (by a noob :))
Message-Id: <uf1956t5amevd3mqcaievjphn7r2s06nst@4ax.com>
Sherm Pendley <sherm.pendley@gmail.com> wrote:
>I think we agree more than not - note that I grouped the conditionals
>at the top of the loop body, with the ellipses representing additional
>code appearing after them. I wouldn't scatter them throughout the loop
>body, unless I had a *very* good reason for doing so.
:-)
jue
------------------------------
Date: Sat, 31 Jul 2010 13:34:55 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Can this be done (by a noob :))
Message-Id: <oj1956ld8i0bkbdd50sod25usgnlqa2s5o@4ax.com>
Ben Morrow <ben@morrow.me.uk> wrote:
>I don't know much about proving programs, but do additional exit points
>really make it any harder than stuffing everything into the conditional?
>Either way, you end up having to deal with the complexity of the
>algorithm somewhere.
Well, depends. If it's just a top-level series of
last if (C1);
last if (C2);
last ....
then no, not really. You just collect all of them and you know that
after the loop at least one of them is true, i.e.
C1 or C2 or C3 or ...
The tricky and rather tedious part are those assertions derived from the
rest of the code that was executed until each last() call somewhere deep
down a deeply nested loop with many conditionals. Those have to be
collected, too, or'ed too, and then simplified. And that's a pain in the
lower rear.
jue
------------------------------
Date: Sat, 31 Jul 2010 22:34:12 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Can this be done (by a noob :))
Message-Id: <kfhei7-4vn2.ln1@osiris.mauzo.dyndns.org>
Quoth Jürgen Exner <jurgenex@hotmail.com>:
> Ben Morrow <ben@morrow.me.uk> wrote:
> >I don't know much about proving programs, but do additional exit points
> >really make it any harder than stuffing everything into the conditional?
> >Either way, you end up having to deal with the complexity of the
> >algorithm somewhere.
>
> Well, depends. If it's just a top-level series of
> last if (C1);
> last if (C2);
> last ....
> then no, not really. You just collect all of them and you know that
> after the loop at least one of them is true, i.e.
> C1 or C2 or C3 or ...
>
> The tricky and rather tedious part are those assertions derived from the
> rest of the code that was executed until each last() call somewhere deep
> down a deeply nested loop with many conditionals. Those have to be
> collected, too, or'ed too, and then simplified. And that's a pain in the
> lower rear.
Yes, I can see that. But is it any *less* painful if those conditionals
are lifted up into the loop condition (especially if they have
side-effects)? It seems to me you're just requiring that the code author
make their code less comprehensible for the benefit of some hypothetical
(probably non-existent) code prover, which isn't a win.
Of course, under some circumstances the algorithm can be simplified into
one which *can* be easily expressed in terms of while-without-last, and
in others an alternative algorithm which can be would work just as well.
I would agree with you that in that case it should be. In the OP's case,
however, I don't see any way of simplifying the basic
while (1) {
<setup>
last if <condition depending on setup>;
<actions>
}
structure that isn't harder to understand and more error-prone. The
Pascal-ish replacement of
my $continue_looping = 1;
while ($continue_looping) {
my $page = get ...;
$continue_looping = 0 unless $page;
write_file ...;
}
just hides the control flow behind a variable, which means you can't
even search for 'last' to find possible exit points.
Ben
------------------------------
Date: Sat, 31 Jul 2010 20:37:14 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: How can I tell if a perl interpreter was built for 32 or 64 bits?
Message-Id: <slrni58raq.rvk.hjp-usenet2@hrunkner.hjp.at>
On 2010-07-29 21:42, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>> On 2010-07-29 18:43, Sherm Pendley <sherm.pendley@gmail.com> wrote:
>> > David Filmer <usenet@davidfilmer.com> writes:
>> >> How can I tell if a perl interpreter was built at 32 or 64 bits?
>>
>> That depends on what you mean by "built at X bits".
>>
>> IV size? pointer size? Register size of the architecture?
>> I'm guessing the latter.
>
> 'Register size of the architecture' is an ambiguous term. An x86-64
> machine running in compatibility mode (which is how 32bit programs are
> run under a 64bit OS) has 16bit, 32bit and 64bit registers available,
According to http://support.amd.com/us/Embedded_TechDocs/24593.pdf (S.
1.3 Operating Modes, p. 11) this is not true. In compatibility mode the
GPRs are limited to 32 bit. But that's not the point.
> but the default address size is still 32 bits.
I would define a "32 bit program" or a "program built at/for 32 bits" as
an executable which was built to run at an architecture with 32 bit
registers (for example 686). It may run on an architecture where larger
registers are available but that't not the target architecture.
Of course there may be architectures with different register sizes (in
fact the x86 architecture is a good example because it has always had 80
bit FP registers (on an optional coprocessor until the 486), and in
this case "register size" is ambiguous.
> The normal meaning of this question is 'what size are my pointers', to
> which the answer is perl -V:ptrsize.
On the (2)86 a pointer could be (and frequently was) 32 bit. On a 386 a
pointer could be 48 bit (although I don't know any OS which ever
implemented it). I'd hesitate to call a program using far pointers on a
286 a 32-bit program and on a 386 a 48-bit program. To me the 286 was a
16-bit architecture and the 386 a 32 bit architecture, and I would call
programs built for the 286 16-bit programs and for the 386 32-bit
programs. (there is another ambiguity here: On the 386, a program was
able to access the 32-bit registers in real or 16-bit protected mode,
and there were programs which did this. They may even have used only
near (16-bit) pointers - were the 16-bit or 32-bit programs? But I'm
digressing)
[about the (lack of) relevance of use64bitint and iv_size]
>> use64bitall might be more conclusive (at least you need both 64 bit ints
>> and 64 bit pointers to get it, which almost certainly means a 64bit
>> architecture).
>
> It's possible at least on some architectures to choose whether to
> use64bitall or not (otherwise the option wouldn't exist).
I meant that use64bitall=define is an indication that the architecture
supports 64 bit pointers, and therefore is almost certainly a 64 bit
architecture (but not necessarily: It could be segmented or
capability-based). I didn't mean to imply that use64bitall=undef means a
32 bit architecture.
hp
------------------------------
Date: Sat, 31 Jul 2010 14:59:36 -0400
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: How can I tell if a perl interpreter was built for 32 or 64 bits?
Message-Id: <m239uzo4tj.fsf@sherm.shermpendley.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
> I would define a "32 bit program" or a "program built at/for 32 bits" as
> an executable which was built to run at an architecture with 32 bit
> registers (for example 686). It may run on an architecture where larger
> registers are available
... and, to get back to the OP's question, running it on such an arch
won't magically make it take advantage of those larger registers. It
would have to be rebuilt in order to do so.
sherm--
--
Sherm Pendley <www.shermpendley.com>
<www.camelbones.org>
Cocoa Developer
------------------------------
Date: Sat, 31 Jul 2010 21:45:42 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: If Perl is compiled on a 32-bit system, and the system is upgraded to 64-bit...
Message-Id: <slrni58vb7.rvk.hjp-usenet2@hrunkner.hjp.at>
On 2010-07-30 03:27, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> On 2010-07-29, Sherm Pendley <sherm.pendley@gmail.com> wrote:
>>> It's not the case here, but it's not generally true (as you imply) that
>>> just because pointers are N-bit you are limited to 2^N memory. You can
>>> definitely address more than the pointer size will allow in a segmented
>>> memory model, just not necessarily all at once.
>
> ... Then your pointers are wider than 32bit. Some bits of them may
> just be inferred from context.
>
> E.g., Generally speaking, on "well-designed" 32-bit architecture, one
> would be able to address 8GB of memory (4GB of data, and 4GB of
> code).
And we could split off the stack into a different segment, too and then
address 12 GB of memory. But while such a separation has security
advantages, it doesn't seem worthwhile for space reasons: The stack is
usually tiny, and the code also much, much smaller than 4GB - so in
effect you can only address 4 GB + some small amount. It was different
on 16-bit systems: Whether code and data had to share 64kB or each could
be up to 64kB made a real difference (and sometimes I really wanted a
separate stack, but I didn't have that).
> Unfortunately, too many people fell under JfN spell of "code
> is data"; the most pronounced problems of the computing of today come
> from this incest. [*]
I agree with that but I think that per-page protections (rw/nx bits) are
a better solution to the problem than separate address spaces.
>> You can even access it all at once, if your pointer data structures
>> contain both a segment identifier and an address.
>
> If the combined size is 32bit, then you cannot access more than 4GB.
>
>> Theory and history aside though, I don't think perl uses far pointers,
>> even on a system that supports them. Nor can I think of any such system
>> that's still in use.
>
> 32bit Linux uses far (read: 32bit) pointers. ;-)
I see the smiley but I'd like to clarify for our young readers that
32bit Linux uses near pointers. On the 386, a far pointer would be 48
bits.
> Basically, AFAIU, on
> most architectures of today paging takes the role of segments.
Yup.
> [*] AFAIK, Solaris (tries to?) separate code from data AMAP. On
> Solaris/i386, are they in different segments?
I don't think so. Sun likes Java. Java uses JIT compilers. JIT compilers
and separated address spaces for code and data don't mesh well.
hp
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3055
***************************************
