|
Bugzilla – Full Text Bug Listing |
| Summary: | printf problems | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | David Binderman <dcb314> |
| Component: | Other | Assignee: | Stefan Dirsch <sndirsch> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Minor | ||
| Priority: | P2 - High | ||
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | SuSE Linux 10.0 | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | Patch which addresses all issues mentioned in Comment #1 | ||
Hendrik: Please decide what to do here. Normally I'd say icc is not supported in this fashion, but you might want to change this. This macro expands correctly with gcc, we already have checks for making our packages fail with these errors. And I wont fix it for icc.
>This macro expands correctly with gcc
I would be grateful if you could explain to me how.
BTW, do you use the -Wall flag on compilation ?
Yes, we use even more than that. Most of our packages support the RPM_OPT_FLAGS inclusing freesci: CFLAGS="$RPM_OPT_FLAGS -fno-strict-aliasing" This means that not only do we have -Wall, we also have the fortify patches in our gcc, and flags within RPM_OPT_FLAGS to use it. On top of that a script that checks for bad warnings in the output, so the package wont even build with such bad warnings. (In reply to comment #6) > This means that not only do we have -Wall Good. I've looked a little deeper into this bug report, and it still looks like a straight forward problem with printf parameter mismatches. It does seem however, that the two versions of GNU C compiler I used didn't find the faults, even with -Wall flag added. I checked my log files of the compilations. It might be worth while constructing a bug report for GNU C. This appears to me to be yet another occasion where Intel C can find bugs where GNU C cannot. In case 1, where is the integer for the %d, and in case 2, where is the integer for the %04x ? (In reply to comment #7) > In case 1, where is the integer for the %d, and in case 2, where > is the integer for the %04x ? I can confirm that this bug still exists in version 0.3.4c-11 Fixed. (In reply to comment #9) > Fixed. I tried the version from Suse Linux 10.1 and the bug appears to be not fixed in that version. Is the fixed version perhaps later than the version that went into Suse Linux 10.1 ? reassign to new maintainer Created attachment 83934 [details] Patch which addresses all issues mentioned in Comment #1 Just for the record. In 10.1 only the first issue has been fixed - for whatever reasons. fixed for 10.2. I also updated it to release 0.3.5. - GP32 port and WinCE port (Walter van Niftrik and Ismail Khatib,respectively) - A game selection screen (by Hugues Valois) - Per-resource shading, to allow manual fine-tuning of SCI game graphics - Background image drawing optimisations - Many, many bugfixes (and maybe a couple of new bugs to spice things up). |
I just tried to compile package freesci-0.3.4c-5 with the Intel C compiler It said 1. said.y(444): warning #267: the format string requires additional arguments The source code is sciprintf("Error: Found %d top branches\n"); Suggest add trailing parameter. 2. sci_view_1.c(208): warning #267: the format string requires additional arguments The source code is GFXERROR("View %04x:(%d) supposed to be at illegal offset 0x%04x\n", id, i); Three % specifiers, only two trailing parameters. Suggest code rework.