Bugzilla – Bug 139350
emu-tools-0.9.4-562: two buglets
Last modified: 2006-11-19 12:43:12 UTC
I just tried to compile package emu-tools-0.9.4-562 with the Intel C compiler It said macro.c(98): warning #592: variable "done" is used before its value is set The source code is while(done!=-1) I agree with the compiler. Suggest initialise local variable "done" before first use. I also tried out a non-standard version of the GNU C compiler. It said emu-dspmgr.c:135: warning: array subscript out of range The source code is line[DSP_LINE_NAME_SIZE - 1] = '\0'; but static char line[10]; and #define DSP_LINE_NAME_SIZE 16 Suggest increase size of line array. BTW, I tried to contact the author [ d_bertra@users.sourceforge.net ] but got no reply.
Again, we do not support the use of the Intel C-Compiler.
>Again, we do not support the use of the Intel C-Compiler. I think you missed the point. I used the Intel C compiler to find two clear bugs. I am sure many C compilers could find these bugs. However, the usual GNU C cannot find them. The emu-tools source code is broken in two places. I am merely suggesting fixing the emu-tools source code.
No, I did not miss your point. For the Intel Compiler this is a _warning_, not an error. For the GNU compiler it is a warning too, in version 4.x ... This is irrelevant, since you reported that for 10.0 and there the GNU compiler produces correct code. And the statement remains, we do not support the use of the Intel C Compiler. Supply a patch upstream, if you think it is such a huge bug. For SUSE this will remain RESOLVED LATER, which means we will take care of it at some point, but it is not a critical or major bug for which we will release an immediate update.
>For the GNU compiler it is a warning too, in version 4.x ... I've got the source code of the compiler. I could make it an error if that would help. >And the statement remains, we do not support the use of the Intel C Compiler. Thanks for making that clear. However, I am not asking you to support the Intel compiler. >Supply a patch upstream, if you think it is such a huge bug. Perhpas it would be best to refer you to the start of the bug report, where I write that I tried to contact the author, but got no reply. >For SUSE this will remain RESOLVED LATER, Excellent.
(In reply to comment #4) > >For SUSE this will remain RESOLVED LATER, Still broken some three months later. Can I confirm that this bug will remain unfixed for Suse Linux 10.1 ?
RESOLVED LATER means later, and not 'fixed with next release' or something like that. And yes, 10.1 will not have it fixed, simply because I did not have the time to check the changes in before update-deadline, the bugs are not critical and the usecase for this program is just too restricted.
>10.1 will not have it fixed I've just checked 10.1, and for the record, I can confirm that it is still broken.
I can confirm that this bug still exists in Suse Linux 10.2 Beta 1. Nothing towards a bugfix has happened for nearly a year now. Would it be sensible to give it back to the bug allocator and let someone else have a look at it, hopefully in time for 10.2 final ?
To state this clear here and now: If you think this is a bug in 10.2, then open a bug for 10.2 and stop misusing this 10.0 bug here.