Prev: Don't understand: when('foo' and/or 'bar')
Next: FAQ 9.15 How do I parse a mail header?
From: Ilya Zakharevich on 20 May 2010 10:58
On 2010-05-19, Ben Morrow <ben(a)morrow.me.uk> wrote:
> Can you give an example of things not behaving as expected?

I was presuming that such things happens left and right, so I did not
try to remember the problems people were reporting. But I may try to guess...

And: I do not have Perl with 64-bit IV AND 64-bit NV around, so all
this is just a conjecture: I expect the the following things to break:

rounding by int($n + 0.t);
$x + 0.5 >= $x

etc... (These are just the first things which come to my mind; real
problems are usually less "obvious"...)

>> This thread is one example of the "first category" - if one forgets
>> what happens with `use integer', which is obviously a bug (BTW, is it
>> reported yet?).
>
> Not by me. With a perl with 32bit IVs I get
>
> ~% perl -E'
> my $x = (1<<30); say $x;
> $x <<= 1; say $x;
> $x <<= 1; say $x;'
> 1073741824
> -2147483648
> 0
>
> I presume it's the final '0' you consider a bug, not the negative value?

For bitwise operations, the negative value "behaves the same" as the
positive one, right? (At least it WAS the reason why I designed the
Perl "numeric system" the way it is...) Then I have no problem with
the negative number. And I definitely have no problem with 0.

I was under assumption that the OP's problem was that shifts were
propagating to floats, and the results (above UV_MAX) converted to
UVs were becoming UV_MAX... But maybe I misread what he wrote...

Yours,
Ilya
From: Shmuel Metz on 20 May 2010 20:56
In <286ec7-6f8.ln1(a)osiris.mauzo.dyndns.org>, on 05/19/2010
at 11:44 PM, Ben Morrow <ben(a)morrow.me.uk> said:

>I presume it's the final '0' you consider a bug, not the negative
>value? I'm not sure I agree that's a bug, since perldoc integer says

>| Finally, "use integer;" also has an additional affect on the bitwise
>| operators. Normally, the operands and results are treated as
>| unsigned integers, but with "use integer;" the operands and results
>| are signed. This means, among other things, that ~0 is -1, and -2 &
>| -5 is 6.

I take it that there is no Perl on 1s complement machines?

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap(a)library.lspace.org

From: sln on 21 May 2010 12:24
On Thu, 20 May 2010 13:02:08 +0200, "Peter J. Holzer" <hjp-usenet2(a)hjp.at> wrote:

>On 2010-05-19 23:56, sln(a)netherlands.com <sln(a)netherlands.com> wrote:
>> On Wed, 19 May 2010 23:44:50 +0100, Ben Morrow <ben(a)morrow.me.uk> wrote:
>>
>>>and a C program the does the same operations on a signed 32bit integer
>> ^^ .........^^
>> This is redundant. There is only unsigned and int.
>
>Wrong. "integer" is not the same as "int". The C standard knows five
>standard signed integer types and six standard unsigned integer types.
>And "int" and "unsigned" are just abbreviations of "signed int" and
>"unsigned int", respectively.
>
> hp

Technically there are no "integer types", they are integral types.
"int" is referred to as the machine word (the natural width of the
data registers) which provide for a bit width in the range of
char <= short <= int <= long. All being unsigned.
"signed" is the shortcut here, not unsigned.

"Integers" are defined by the set of whole numbers {..,-2,-1,0,1,2,..}.
I sure would hate to look at C source code that had
"signed" in it, although some compilers have the option to
convert the default to unsigned (/J on MS), except where
"signed" is denoted.

So, we could agree that C program integral types are either
unsigned, or the default, which is signed (the synonym for the default),
and that signed int is redundant (in the default case), and is would be
more specific as a 32-bit long.

-sln
From: Peter J. Holzer on 22 May 2010 05:01
On 2010-05-21 00:56, Shmuel Metz <spamtrap(a)library.lspace.org.invalid> wrote:
> I take it that there is no Perl on 1s complement machines?

This seems very likely.

hp
From: Peter J. Holzer on 22 May 2010 04:57
On 2010-05-21 16:24, sln(a)netherlands.com <sln(a)netherlands.com> wrote:
> On Thu, 20 May 2010 13:02:08 +0200, "Peter J. Holzer" <hjp-usenet2(a)hjp.at> wrote:
>>On 2010-05-19 23:56, sln(a)netherlands.com <sln(a)netherlands.com> wrote:
>>> On Wed, 19 May 2010 23:44:50 +0100, Ben Morrow <ben(a)morrow.me.uk> wrote:
>>>>and a C program the does the same operations on a signed 32bit integer
>>> ^^ .........^^
>>> This is redundant. There is only unsigned and int.
>>
>>Wrong. "integer" is not the same as "int". The C standard knows five
>>standard signed integer types and six standard unsigned integer types.
>>And "int" and "unsigned" are just abbreviations of "signed int" and
>>"unsigned int", respectively.
>
> Technically there are no "integer types", they are integral types.

Please read the standard.

hp
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Don't understand: when('foo' and/or 'bar')
Next: FAQ 9.15 How do I parse a mail header?