New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No subject provided #951
Comments
From rmb1@cise.npl.co.ukCreated by rmb1@tempest.cise.npl.co.ukpragma/warnings failed: I tracked this down, after several blind alleys, to the variable containing Patch below: perhaps '(char)' should be '(int)' for consistency. Robin --- regcomp.c 1999/12/15 11:13:22 1.1 Perl Info
|
From [Unknown Contact. See original ticket]Further investigation of the printf function with UVs reveals: #include <stdio.h> gives output: This is gcc-2.95.1 on sun4-solaris2.7 The conclusion is that failure to cast UV/IV before using %d Robin -- |
From [Unknown Contact. See original ticket]At 05:57 PM 12/15/99 +0000, Robin Barker wrote:
Not to be too pedantic here, but... This is illegal code, and it's subject to the whims and vagaries of your How it behaves depends on quite a number of factors. The output I get, for 1 2 2062686916 2062686912 but in a more complex program this sort of thing tends to cause access Not to say the problem's not real, but this program isn't a good Dan ----------------------------------------"it's like this"------------------- |
From [Unknown Contact. See original ticket]
If you want legal code, here's some legal code: #include <stdio.h> On my machine this gives and on your machine gives (I presume) The fact remains that we must detect/fix this gcc bug/feature or Robin -- |
From [Unknown Contact. See original ticket]At 12:04 PM 12/16/99 +0000, Robin Barker wrote:
Yep. And the compiler yells that the types of the arguments don't match the
Yep, we do need to root out those. We really need to go and do some More preprocessor abuse, I'd expect. :( Dan ----------------------------------------"it's like this"------------------- |
From [Unknown Contact. See original ticket]
Well, since we already only compile with ansi C, I don't know if it would printf("%d blah blah blah %d",x,y) could change to printf(Perl_IV_FMT " blah blah blah " Perl_IV_FMT, x, y) where Perl_IV_FMT is whatever the appropriate string might be for formatting I was quite surprised that C committee didn't predefine format strings like Of course, someone still has to find and fix all of 'em :-). |
From [Unknown Contact. See original ticket]At 09:05 AM 12/16/99 -0500, Tom Horsley wrote:
That's what I was figuring we'd do. I was also thinking it'd add another Dan ----------------------------------------"it's like this"------------------- |
From @vanstynIn <14424.61869.887887.427597@cleo.ccur.com>, Tom Horsley writes: For a long time, I've cast all such unknown sizes to long for formatting, Hugo |
From [Unknown Contact. See original ticket]Hugo <hv@crypt.compulink.co.uk> wrote
It's a pity that C doesn't define a type 'longest' for this purpose. :-) Mike Guy |
From [Unknown Contact. See original ticket]In message <E11yfBK-0006mz-00@ursa.cus.cam.ac.uk>
#include <inttypes.h> intmax_t x; Of course you do need a ISO C99 compliant compiler ;-) Tom -- |
From [Unknown Contact. See original ticket]I dno't know if this is of any interest or any use. I investigated the possible type errors further. The attached patch adds code for checking printf formats using -DCHECK_FORMAT: Applying the patch, configuring with -Dccflags="-Wformat -DCHECK_FORMAT", toke.c: In function `S_scan_const': Robin --- XSUB.h 1999/12/17 10:14:41 1.1 --- perl.c 1999/12/17 10:14:41 1.1 #define STATIC static #ifndef pTHXo #endif /* Include guard */ --- pp_sys.c 1999/12/17 10:14:41 1.1 - Perl_warn(aTHX_ "%_", tmpsv); @@ -500,7 +500,7 @@ - DIE(aTHX_ "%_", tmpsv); /* I/O. */ @@ -1639,7 +1639,7 @@ /* output mangled stuff ... */ -- |
From @gsarOn Fri, 17 Dec 1999 13:31:18 GMT, Robin Barker wrote:
Thanks.
That changes semantics. The %_ type prints the contents of the SV
Naturally, they're not the same. Sarathy |
Migrated from rt.perl.org#1896 (status was 'resolved')
Searchable as RT1896$
The text was updated successfully, but these errors were encountered: