[perl #42359] [PATCH] Assorted cleanups - part III (Intel C++)

0 views
Skip to first unread message

Steve Peters

unread,
Apr 8, 2007, 7:08:06 PM4/8/07
to bugs-bi...@rt.perl.org
# New Ticket Created by Steve Peters
# Please include the string: [perl #42359]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42359 >


The attached patch includes several cleanups needed to silence warnings
when compiling Parrot with Intel C++.

The cleanups fall mainly into two catagories.

1) Changing strstart in STRING from a void * to a char *. This also includes
some fixes where the pointer is treated as an unsigned char *.

2) Enum values should be treated as ints, not as the enum type. So, there are
multiple variable and parameter redeclarations from an enumerated type to
an int.

Steve Peters
st...@fisharerojo.org

intel_cleanups.out

Chromatic

unread,
Apr 10, 2007, 2:00:23 AM4/10/07
to perl6-i...@perl.org, parrotbug...@parrotcode.org
On Sunday 08 April 2007 18:07, Steve Peters via RT wrote:

> On Sun Apr 08 16:08:05 2007, stmpeters wrote:
> > The attached patch includes several cleanups needed to silence
> > warnings
> > when compiling Parrot with Intel C++.
>

> It helps to attach the right patch....

I get several warnings. I've cleaned up this batch:

src/pmc/eval.pmc: In function ‘Parrot_Eval_get_string’:
src/pmc/eval.pmc:255: warning: passing argument 3 of ‘PackFile_pack’ from
incompatible pointer type
src/pmc/eval.pmc: In function ‘Parrot_Eval_thaw’:
src/pmc/eval.pmc:312: warning: passing argument 3 of ‘PackFile_unpack’ from
incompatible pointer type

src/pmc_freeze.c: In function ‘run_thaw’:
src/pmc_freeze.c:1435: warning: comparison of distinct pointer types lacks a
cast

src/pmc/string.pmc: In function ‘Parrot_String_nci_trans’:
src/pmc/string.pmc:853: warning: array subscript has type ‘char’

... but my attempt to fix these causes more test failures in t/op/string_cs.t:

src/encodings/fixed_8.c
src/encodings/fixed_8.c: In function ‘get_byte’:
src/encodings/fixed_8.c:49: warning: pointer targets in initialization differ
in
signedness
src/encodings/fixed_8.c: In function ‘set_byte’:
src/encodings/fixed_8.c:67: warning: pointer targets in assignment differ in
sig
nedness
src/encodings/ucs2.c
src/encodings/utf16.c
src/encodings/utf16.c: In function ‘get_byte’:
src/encodings/utf16.c:170: warning: pointer targets in initialization differ
in
signedness
src/encodings/utf16.c: In function ‘set_byte’:
src/encodings/utf16.c:188: warning: pointer targets in assignment differ in
sign
edness
src/encodings/utf8.c
src/encodings/utf8.c: In function ‘to_encoding’:
src/encodings/utf8.c:334: warning: pointer targets in assignment differ in
signe
dness
src/encodings/utf8.c:357: warning: pointer targets in assignment differ in
signe
dness
src/encodings/utf8.c: In function ‘get_byte’:
src/encodings/utf8.c:400: warning: pointer targets in initialization differ
in s
ignedness
src/encodings/utf8.c: In function ‘set_byte’:
src/encodings/utf8.c:418: warning: pointer targets in assignment differ in
signe
dness

The test results are:

not ok 5 - downcase
# Failed test (t/op/string_cs.t at line 72)
# got: 'aeiou_��
# '
# expected: 'aeiou_��
# '
ok 6 - upcase
not ok 7 - titlecase
# Failed test (t/op/string_cs.t at line 90)
# got: 'Zaeiou_��
# '
# expected: 'Zaeiou_��
# '

As seen through less, they are:
# Failed test (t/op/string_cs.t at line 72)
# got: 'aeiou_<C4><D6><DC>
# '
# expected: 'aeiou_<E4><F6><FC>
# '
# Failed test (t/op/string_cs.t at line 90)
# got: 'Zaeiou_<C4><D6><DC>
# '
# expected: 'Zaeiou_<E4><F6><FC>

... so the encoded characters get 32 added to them somehow, somewhere.

I've attached your patch with a few changes on my end.

-- c


intel_cleanup_2.patch

Steve Peters via RT

unread,
Apr 10, 2007, 2:19:06 PM4/10/07
to perl6-i...@perl.org

These are likely caused by the varying definition of what a
STRING->strstart is. Sometimes its a char *. Sometimes its an unsigned
char *. The pointer itself is a void *. Its a big mess. Obviously,
this all needs more work, and probably a bit more thought on my part.
I'll probably break apart this patch to get the enum fixes in and deal
with the larger STRING issue separately.

Steve

Jerry Gay

unread,
Apr 10, 2007, 2:45:25 PM4/10/07
to parrotbug...@parrotcode.org, perl6-i...@perl.org
On 4/10/07, Steve Peters via RT <parrotbug...@parrotcode.org> wrote:
> I'll probably break apart this patch to get the enum fixes in and deal
> with the larger STRING issue separately.
>
cohesive, loosely coupled patches are always preferred.
~jerry
Reply all
Reply to author
Forward
0 new messages