Bug 139350

Summary:	emu-tools-0.9.4-562: two buglets
Product:	[openSUSE] SUSE LINUX 10.0	Reporter:	David Binderman <dcb314>
Component:	Basesystem	Assignee:	Daniel Rahn <drahn>
Status:	RESOLVED WONTFIX	QA Contact:	E-mail List <qa-bugs>
Severity:	Minor
Priority:	P5 - None
Version:	unspecified
Target Milestone:	---
Hardware:	All
OS:	SUSE Other
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description David Binderman 2005-12-15 13:15:58 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.

Comment 1 Daniel Rahn 2005-12-15 13:44:19 UTC

Again, we do not support the use of the Intel C-Compiler.

Comment 2 David Binderman 2005-12-15 18:32:46 UTC

>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.

Comment 3 Daniel Rahn 2005-12-15 22:04:24 UTC

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.

Comment 4 David Binderman 2005-12-16 09:05:06 UTC

>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.

Comment 5 David Binderman 2006-03-16 12:47:06 UTC

(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 ?

Comment 6 Daniel Rahn 2006-03-16 12:53:31 UTC

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.

Comment 7 David Binderman 2006-05-15 20:24:25 UTC

>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.

Comment 8 David Binderman 2006-10-31 13:14:06 UTC

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 ?

Comment 9 Daniel Rahn 2006-11-19 12:43:12 UTC

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.