Front page | perl.perl5.porters |
Postings from July 2013
[perl #116296] [PATCH] remove PL_patchlevel from and optimize S_minus_v
Thread Previous
|
Thread Next
From:
Tony Cook via RT
Date:
July 19, 2013 01:32
Subject:
[perl #116296] [PATCH] remove PL_patchlevel from and optimize S_minus_v
Message ID:
rt-3.6.HEAD-2552-1374197562-376.116296-15-0@perl.org
On Thu Jul 18 11:57:36 2013, bulk88 wrote:
> On Sun Jul 07 23:53:42 2013, tonyc wrote:
> >
> > Tony
> >
>
> Patch remade, newSVpvn and %d replaced with %zu to hopefully (not using
> GCC) stop type mismatch warning.
>
Thanks for the newSVpvn change, unfortunately the format string error
remains:
CCCMD = cc -DPERL_CORE -c -D_REENTRANT -D_GNU_SOURCE
-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c89 -O2 -Wall -ansi -W
-Wextra -Wdeclaration-after-statement -Wendif-labels -Wc++-compat
-Wwrite-strings
perl.c: In function ‘S_minus_v’:
perl.c:3600:9: warning: format ‘%s’ expects argument of type ‘char *’,
but argument 3 has type ‘long unsigned int’ [-Wformat]
From clang:
perl.c:3555:9: warning: format specifies type 'char *' but the argument
has type
'size_t' (aka 'unsigned long') [-Wformat]
INT2PTR(size_t, LOCAL_PATCH_COUNT),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./perl.h:1630:26: note: expanded from macro 'INT2PTR'
# define INT2PTR(any,d) (any)(d)
^~~~~~~~
Note that ANSI C doesn't guarantee that size_t and pointers are the same
size, though I can only think an obsolete platform (Win16 large model)
where they are different sizes.
About the only way I can see to avoid this type of error would be
something like:
const char copyrights[] =
... #ifdefs for platform messages ...
LOCAL_PATCH_COUNT == 0
? PerlIO_printf(PIO_stdout, larry message "%s", copyrights)
: LOCAL_PATCH_COUNT == 1
? PerlIO_printf(PIO_stdout, larry message "with 1 registered
patch\n%s", copyrights)
: PerlIO_printf(PIO_stdout, larry message "with %d registered
patches\n%s", LOCAL_PATCH_COUNT, copyrights);
The compiler should optimize away all but one branch, but it's
ridiculous code for the purpose (and doesn't belong in perl.)
This updated patch does nothing about the confusing "where's the end of
the printf" issue which I should probably have been more explicit about
in an earlier message.
(I almost posted about %zu too, since that's not C89, but you're right,
perl itself handles the format.)
WRT your response to Nicholas:
> larry wall copy right+gpl string came out to 411 bytes+alignment
> padding (upto 8 more bytes) in my Win32 binary image using a
> disassembler.
The C89 limit is 509 characters, and it's a limit on string literals in
general, not concatenation in particular. C99 is more generous allowing
4096 characters.
So, as you said, we're fine here.
> If CPP token catting doesn't work, I dont think Perl will compile
> because of code like
>
> Perl_croak(aTHX_
> "Can't locate object method \"%"UTF8f
> "\" via package \"%"SVf"\""
> " (perhaps you forgot to load \"%"SVf"\"?)",
>
> ifdefs evaled before string litteral catting,
>
http://stackoverflow.com/questions/1476892/poster-with-the-8-phases-of-translation-in-the-c-language
While you're right about the behaviour the C specification requires,
some compilers are unfortunately buggy.
You're also comparing two different code constructs here, Nicholas said
that:
"literal1"
#ifdef SOMETHING
"literal2"
#endif
may cause a compiler to choke (such a compiler is buggy, string literal
concatenation has nothing to do with the preprocessor.)
Your example contains no preprocessor directives, just macro replacements.
I wonder if we should have a document describing such compiler bugs that
we've bothered working around in the past.
Tony
---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=116296
Thread Previous
|
Thread Next