From: SourceForge.net <no...@so...> - 2005-04-12 18:43:30
|
Bugs item #737001, was opened at 2003-05-13 13:53 Message generated for change (Settings changed) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=737001&group_id=599 >Category: Run Time Library >Group: fixed >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bernhard Held (bernhardheld) Assigned to: Nobody/Anonymous (nobody) Summary: Not explictely initialized static variables are undefined Initial Comment: zeropad_storage_idata.c struct x { short a; char b[10]; }; struct x idata teststruct[3] = { { 10, { 1, 2, 3, 4, 5} }, { 20, { 11 } }, { 30, { 6, 7, 8} } }; teststruct[0].b[5]...b[9] ... are not initialized to 0. bug-227710.c struct { unsigned char index; } s; s.index isn't initialized to 0. ---------------------------------------------------------------------- Comment By: Raphael Neider (tecodev) Date: 2005-03-22 14:31 Message: Logged In: YES user_id=1115835 PIC16 is ok for zeropad_storage_idata.c (with idata removed) and also fine for bug-227710.c if linked against crt0iz.o. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2005-03-21 17:09 Message: Logged In: YES user_id=888171 This is checked in regression test zeropad.c with no exceptions for SDCC. Since this does not generate errors, either all ports are ok or the simulator has initialized everything to 0 instead of random data. And how are both pic ports doing? ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2004-01-08 21:39 Message: Logged In: YES user_id=589052 thanks for applying, this bug is fixed for the mcs51 port. (others are not yet OK. I'm removing myself as maintainer) The feature request #482693 is related. ---------------------------------------------------------------------- Comment By: Erik Petrich (epetrich) Date: 2003-12-16 06:05 Message: Logged In: YES user_id=635249 The patch has been applied and is visible in src/mcs51/main.c 1.77 ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-12-15 14:49 Message: Logged In: YES user_id=589052 Hi Maarten, thank you for having a close look. I attach a patch which does as you proposed. Given my recent checkins to the startup code, chances are that this is not flawless either:( Unfortunately I can't do check-ins until Friday this week. Maybe someone else does? Frieder ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2003-12-15 11:59 Message: Logged In: YES user_id=888171 Hello Frieder, I've been looking at your fix, but I'm afraid this hasn't been tested completely either. You assume R0 is zero which is not guaranteed if JZ 00005$ is taken. I suggest swapping the use of R0 and R1. P.S. You're not mentioned as the assigned to developer for this bug. Hope I have helped, Maarten Brock ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-12-14 14:00 Message: Logged In: YES user_id=589052 for the mcs51 this is fixed with src/mcs51/main.c (cvs 1.76) ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2003-11-13 22:22 Message: Logged In: YES user_id=589052 started fixing this for the mcs51. Set the environment variable SDCC_GENRAMCLEAR to generate code to clear XSEG and idata memory. (This clears XSEG, DSEG, BSEG, OSEG, SSEG) Frieder ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=737001&group_id=599 |