https://bugzilla.novell.com/show_bug.cgi?id=248719 mhorvath@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team- |jmatejek@novell.com |screening@forge.provo.novell| |.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=248719 dcb314@hotmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- Comment #2 from dcb314@hotmail.com 2007-02-27 13:38 MST ------- (In reply to comment #1)

this is by design, the "invalid" access is always inside a memory page with valid objects, so it never causes a segfault.

please reopen if it in fact does cause problems.

From the valgrind report, it looks to me like memory is read after it has been freed.

I think I am correct to say that it is a C FAQ to read or write memory after it has been freed. See http://c-faq.com/malloc/useafterfree.html There are other ways for a program to fail than a segfault. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=248719 dcb314@hotmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- Comment #4 from dcb314@hotmail.com 2007-02-28 09:59 MST ------- (In reply to comment #3)

I wonder how it even occured to you to run a build script through valgrind.

I've pretty much done compile time for Suse Linux, so it was time to move onto runtime. I

but without providing an actual bug, it is quite hard to fix it and not break other things.

I disagree - the code is broken because it fails to conform to ISO C. K&R 2, section 7.8.5 page 167 in my copy. The fix does look difficult, however. I don't understand how providing "an actual bug" is a pre-condition on getting this fixed. You make it sound like code is only broken when it crashes. I'm sure that is not true.

Anyway, as I stated before, this behavior is intended and functional. See this link for thorough discussion of the subject: http://mail.python.org/pipermail/python-dev/2006-November/069892.html

Thanks for the link. I read it - it confirms what I suspected. If I understand correctly, the code is broken, according to the international standards. Is it possible to close this bug report with "fix too hard" ? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=248719 ------- Comment #6 from jmatejek@novell.com 2007-03-01 07:27 MST ------- (In reply to comment #4)

I disagree - the code is broken because it fails to conform to ISO C. K&R 2, section 7.8.5 page 167 in my copy.

I'll have to argue with this. K&R is absolutely irrelevant in this case, Python is written in ANSI C, and it's perfectly valid ANSI C. What you're referring to is the fact that the code relies on "undefined" behavior. But as stated in the mentioned thread*, this is guaranteed to work by the POSIX norm, and, more importantly, design of current hardware. * http://mail.python.org/pipermail/python-dev/2006-November/069897.html

I don't understand how providing "an actual bug" is a pre-condition on getting this fixed.

That is very simple, really. Something that looks as a bug on first sight might just as well be a clever (if hackish) design, and fixing the "obvious bug" in code can have disastrous consequences. Providing an actual bug, i.e. deviation from program's expected behavior, is a simple proof that a problem really exists.

You make it sound like code is only broken when it crashes. I'm sure that is not true.

The code is broken when it fails to do what it's supposed to do. And that is not the case. Of course we might argue about "beauty" and "elegance" and "proper programming techniques", but that is not the point here.

Thanks for the link. I read it - it confirms what I suspected. If I understand correctly, the code is broken, according to the international standards.

To my best knowledge, there are no standards on what an ANSI C program should do, as long as it's written in proper ANSI C (which it apparently is). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=248719 ------- Comment #8 from dcb314@hotmail.com 2007-03-01 10:08 MST ------- (In reply to comment #6)

(In reply to comment #4)

...

I disagree - the code is broken because it fails to conform to ISO C. K&R 2, section 7.8.5 page 167 in my copy.

I'll have to argue with this. K&R is absolutely irrelevant in this case, Python is written in ANSI C, and it's perfectly valid ANSI C.

I agree K&R 1 is irrelevant, that's why I said K&R 2. You can't have it both ways. Either 1. It is valid ISO C 2. It relies on undefined features, and so it isn't ISO C. One or the other, not both. You can't have your cake and eat it.

What you're referring to is the fact that the code relies on "undefined" behavior.

I agree - undefined code doesn't conform to the standards.

* http://mail.python.org/pipermail/python-dev/2006-November/069897.html

I am happy for this bug to be closed as WONTFIX, as long as we both know that there is some undefined code in there which the Python folks won't be fixing anytime soon.

The code is broken when it fails to do what it's supposed to do.

There are lots of other failure modes.

To my best knowledge, there are no standards on what an ANSI C program should do, as long as it's written in proper ANSI C (which it apparently is).

I don't understand this. ISO C defines a standard. Programs written to conform to the standard will behave as the standard specifies. To say that ISO C doesn't define a standard is false. BTW, ANSI C is merely the USA version of the standard. For example, BSI C is the UK version, and DIN C is the German version. I forget the French version. ISO C is the international version. Not all of us live in the USA. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.