6 Feb
2002
6 Feb
'02
12:34 a.m.
Hello, all:
I have discovered an interesting anomaly while finishing up the 2.2
version of the Altair32 Emulator (to be released this weekend, by the way).
Maybe it's my lack of understanding of C or the service pack I applied to
MSVC :-)
Between version 2.0 and 2.1, BASIC 3.2 was broken -- it was hanging
in a loop in the console input code waiting for the right status bits to be
set by my port emulator code. While I was setting the right bits, the
internal emulator variable wasn't reflecting the assignment.
In the sio00h routine in the sio.c module, I declare a local-scope
variable of type int that's not initialized...
int sio00h (params...){
int nSioStatus ;
... stuff
}
When in the MSVC debugger, the undeclared variable has the value
0xcccccccc. OK.
In the body of the routine, the variable can be set to three values
using #defines from the header. For some reason, the variable is not being
set to the #define value. As you trace execution, the variable to be
returned by the routine remains 0xcccccccc after assignment:
nSioStatus = SIO_WDB ; //#defines to 0x80
So, I initialized the variable to 0 and for good measure, returned
the int as:
return (nSioStatus & 0xff) ;
In one of the top calling routines, it gets truncated to a BYTE-size
(so to speak) anyway.
So I figured that maybe there was a scoping problem but the
nSioStatus variable is not used in any other module, nor is it declared
extern or module global. The #define appears in multiple headers but are all
defined to be the same value.
Now, BASIC 3.2 it works but I can't really figure out why.
Any thoughts??
Rich
5 Feb
5 Feb
6:08 p.m.
On Wed, 6 Feb 2002, Cini, Richard wrote:
In the body of the routine, the variable can be set
to three values
using #defines from the header. For some reason, the variable is not being
set to the #define value. As you trace execution, the variable to be
returned by the routine remains 0xcccccccc after assignment:
nSioStatus = SIO_WDB ; //#defines to 0x80
So you're saying if you added a printf("%x", nSioStatus) right here (after
the assignment) you'd see 0xcccccccc?
So, I initialized the variable to 0 and for good
measure, returned
the int as:
return (nSioStatus & 0xff) ;
In one of the top calling routines, it gets truncated to a BYTE-size
(so to speak) anyway.
Maybe because you are returning effectively a byte? Try type-casting the
returned value:
return ((int)(nSioStatus & 0xff));
I don't know if that actually addresses your main problem directly.
I also like Bryan's suggestion to check for out-of-bounds writes on a
malloc'd memory buffer. That sort of thing causes really weird shit to
happen.
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
1:11 a.m.
And thusly Cini, Richard spake:
Hello, all:
I have discovered an interesting anomaly while finishing up the 2.2
version of the Altair32 Emulator (to be released this weekend, by the way).
Maybe it's my lack of understanding of C or the service pack I applied to
MSVC :-)
Between version 2.0 and 2.1, BASIC 3.2 was broken -- it was hanging
in a loop in the console input code waiting for the right status bits to be
set by my port emulator code. While I was setting the right bits, the
internal emulator variable wasn't reflecting the assignment.
In the sio00h routine in the sio.c module, I declare a local-scope
variable of type int that's not initialized...
int sio00h (params...){
int nSioStatus ;
... stuff
}
When in the MSVC debugger, the undeclared variable has the value
0xcccccccc. OK.
In the body of the routine, the variable can be set to three values
using #defines from the header. For some reason, the variable is not being
set to the #define value. As you trace execution, the variable to be
returned by the routine remains 0xcccccccc after assignment:
nSioStatus = SIO_WDB ; //#defines to 0x80
So, I initialized the variable to 0 and for good measure, returned
the int as:
return (nSioStatus & 0xff) ;
In one of the top calling routines, it gets truncated to a BYTE-size
(so to speak) anyway.
If you only want a byte sized data type, why not use a char type for the
variable and return value.
Have you tried using fprintf (stderr, ...); to print out the value of
nSioStatus right after it is initialized?
Another thing that comes to mind: Do you use any blocks of malloc'd memory?
Maybe you are going outside the allocated range?
So I figured that maybe there was a scoping problem but the
nSioStatus variable is not used in any other module, nor is it declared
extern or module global. The #define appears in multiple headers but are all
defined to be the same value.
You could also try fprintf'ing the #define value in the sio00h function.
Now, BASIC 3.2 it works but I can't really figure out why.
Any thoughts??
This is all I can come up without having more code to look at...
Cheers,
Bryan
10:47 a.m.
It was thus said that the Great Bryan Pope once stated:
Because a C compiler is free to treat an unspecified char declaration as
signed or unsigned (i.e. in the declaration ``char c;'' c can either be a
signed quantity or unsigned quantity). You need specify explicitely if you
want signed or unsigned characters (okay, some compilers let you set the
default signness of chars, but not all).
To be safe, you probably want something like:
#include <limits.h>
#if (UCHAR_MAX == 255U)
typedef unsigned char u8;
#else
# error No integral type is 8 bits on this platform
#endif
#if (UINT_MAX == 65535U)
typedef unsigned short u16;
#elif (USHRT_MAX == 65535U)
typedef unsigned int u16;
#elif (UCHAR_MAX == 65535U)
typedef unsigned char u16;
#else
# error No integral type is 16 bits on this platform
#endif
#if (ULONG_MAX == 4294967295UL)
typedef unsigned long u32;
#elif (UINT_MAX == 4294967295UL)
typedef unsigned int u32;
#elif (USHRT_MAX == 4294967295UL)
typedef unsigned short u32;
#elif (UCHAR_MAX == 4294967295UL)
typedef unsigned char u32;
#else
# error No integral type is 32 bites on this platform
#endif
This code should generate types of the appropriate bit sizes for most of
the general use systems in use today, and yet alert you to any problems or
assumptions that you might have when porting to a new system. A word is
*NOT* a 16 bit quantity (well, except for 16 bit systems), despite what
Microsoft says.
-spc (Has had to deal with portability issues)
In one of the top calling routines, it gets
truncated to a BYTE-size
(so to speak) anyway.
If you only want a byte sized data type, why not use a char type for the
variable and return value. 
1:20 a.m.
At 09:34 AM 2/6/2002 -0500, Cini, Richard wrote:
The #define appears in multiple headers but are all
defined to be the same value.
Run away! Make one #define and perhaps one header.
Be sure you are initializing the local variable in
code that is always executed, or better yet combine
the declaration and its initialization:
int sio00h (params...){
int nSioStatus = SIO_WDB ;
... stuff
}
- John
4:16 a.m.
Are you shure MSVC is not optimizing away your asignment?
If the variable is not used in a rather near scope, MSVC does this
sometimes too agressively.
ms
On Wed, 2002-02-06 at 15:34, Cini, Richard wrote:
Hello, all:
I have discovered an interesting anomaly while finishing up the 2.2
version of the Altair32 Emulator (to be released this weekend, by the way).
Maybe it's my lack of understanding of C or the service pack I applied to
MSVC :-)
Between version 2.0 and 2.1, BASIC 3.2 was broken -- it was hanging
in a loop in the console input code waiting for the right status bits to be
set by my port emulator code. While I was setting the right bits, the
internal emulator variable wasn't reflecting the assignment.
In the sio00h routine in the sio.c module, I declare a local-scope
variable of type int that's not initialized...
int sio00h (params...){
int nSioStatus ;
... stuff
}
When in the MSVC debugger, the undeclared variable has the value
0xcccccccc. OK.
In the body of the routine, the variable can be set to three values
using #defines from the header. For some reason, the variable is not being
set to the #define value. As you trace execution, the variable to be
returned by the routine remains 0xcccccccc after assignment:
nSioStatus = SIO_WDB ; //#defines to 0x80
So, I initialized the variable to 0 and for good measure, returned
the int as:
return (nSioStatus & 0xff) ;
In one of the top calling routines, it gets truncated to a BYTE-size
(so to speak) anyway.
So I figured that maybe there was a scoping problem but the
nSioStatus variable is not used in any other module, nor is it declared
extern or module global. The #define appears in multiple headers but are all
defined to be the same value.
Now, BASIC 3.2 it works but I can't really figure out why.
Any thoughts??
Rich
--
Michael Schneider email: ms(a)vaxcluster.de
Germany http://www.vaxcluster.de
People disagree with me. I just ignore them.
(Linus Torvalds)
10:56 a.m.
It was thus said that the Great Cini, Richard once stated:
When in the MSVC debugger, the undeclared variable has the value
0xcccccccc. OK.
Which is a good value for an x86 based platform. If executed, it maps to
INT 3 (if I remember correctly---it's the break point opcode), plus it is
distinctive to see (in a hex dump) and it's either going to be a very large
unsigned value, or a fair sized negative value and most likely an invalid
address if treated as a pointer, so it's sure to cause all sorts of
interesting problems and results if used.
In my wrappers for malloc()/free(), if I'm running in debug mode, I will
fill the allocated memory with such a pattern (and add extra space before
and after, so that free() can check to see if this padding has been changed.
That alone has caught quite a few problems). The actual pattern I use
depends upon the system and so far, here is what I have:
#ifdef MIPS
# define PADDING 0xB1
# define NULLP 0xB1B1B1B1
#elif defined I386
# define PADDING 0xCC
# define NULLP 0xCCCCCCCC
#elif defined MC68K
# define PADDING 0xA1
# define NULLP 0xA1A1A1A1
#elif defined RS6000
# define PADDING 0xB1
# define NULLP 0xB1B1B1B1
#else
# error Please define system
#endif
The MIPS I think it's an undefined opcode, and the MC68K will treat that
as an A-line trap. I will definitely need to add Alpha patterns since I now
have access to such a system.
-spc (I've picked up a few tricks along the way)
3:12 p.m.
At 07:56 PM 2/6/02 -0500, you wrote:
It was thus said that the Great Cini, Richard once
stated:
My favorite bogus fill value/return code (because it is obvious, not
because it traps if executed) is 0xDEADBEEF.
And to make it on topic, I've been using that value for more than 10 years.
-----
Jim Battle == frustum(a)pacbell.net
When in the MSVC debugger, the undeclared variable has the value
0xcccccccc. OK.
...
#ifdef MIPS
# define PADDING 0xB1
# define NULLP 0xB1B1B1B1
#elif defined I386
# define PADDING 0xCC
# define NULLP 0xCCCCCCCC
#elif defined MC68K
# define PADDING 0xA1
# define NULLP 0xA1A1A1A1
#elif defined RS6000
# define PADDING 0xB1
# define NULLP 0xB1B1B1B1
#else
# error Please define system
#endif 
7 Feb
7 Feb
1:19 a.m.
On Wed, 6 Feb 2002, Tothwolf wrote:
I've heard the 0xDEADBEEF pretty commonly to initialize empty memory.
The NeXT black hardware binaries used 0xFEEDFACE as their magic number,
and I think the fat binaries (or maybe it was the Intel?) used 0xCAFEBABE.
-brian.
On Wed, 6 Feb 2002, Jim Battle wrote:
My favorite
bogus fill value/return code (because it is obvious, not
because it traps if executed) is 0xDEADBEEF.
One I've often used is 0xDEADF00D, same meaning I suppose :) 
2:13 a.m.
Brian Chase wrote:
The NeXT black hardware binaries used 0xFEEDFACE as
their magic number,
and I think the fat binaries (or maybe it was the Intel?) used 0xCAFEBABE.
That explains the quality of the latest software ... the programers
don't have their mind on debuging.
On I side note from all the apple posts , the Mac software seems to have
more revisions than windows. Did you apple people pay a arm and leg for
software upgrades like with the M product?
--
Ben Franchuk - Dawn * 12/24 bit cpu *
www.jetnet.ab.ca/users/bfranchuk/index.html
6:06 a.m.
On I side note from all the apple posts , the Mac
software seems to have
more revisions than windows. Did you apple people pay a arm and leg for
software upgrades like with the M product?
Nope...most of the time, for minor revisions anyway, the
upgrades are free, even for the OS. The way I see revisions on Mac
software is that they are faster to take care of bugs and problems
found in previous versions by the users. ATI seems to be the curent
major exception with their inability to release drivers that actually
work, regardless of how many times they revise them.
Jeff
--
Home of the TRS-80 Model 2000 FAQ File
http://www.cchaven.com
http://www.geocities.com/siliconvalley/lakes/6757
1:57 a.m.
--- Tothwolf <tothwolf(a)concentric.net> wrote:
On Wed, 6 Feb 2002, Jim Battle wrote:
0xFEEDFACE 0xDEADBEEF
-ethan
__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com
My favorite bogus fill value/return code (because
it is obvious, not
because it traps if executed) is 0xDEADBEEF.
One I've often used is 0xDEADF00D, same meaning I suppose :) 
2:45 a.m.
--- Tothwolf <tothwolf(a)concentric.net> wrote:
I use 0xDEADBEEF and 0xBEEFCAFE all the time. I once ran across 0xDEADBABE,
and promptly replaced that, lest a customer decide to browse the source.
Just a little too morbid. Another personal favorite is 0xe5e5e5e5 (which,
as the truly geek will remember, 0xe5 indicated a deleted file in the CP/M
directory entry).
On Wed, 6 Feb 2002, Jim Battle wrote:
0xFEEDFACE 0xDEADBEEF
-ethan My favorite bogus fill value/return code (because
it is obvious, not
because it traps if executed) is 0xDEADBEEF.
One I've often used is 0xDEADF00D, same meaning I suppose :)
8136
days inactive
8137
days old
14 comments
14 participants
participants (14)
-
bfranchuk＠jetnet.ab.ca -
bpope＠wordstock.com -
erd_6502＠yahoo.com -
foo＠siconic.com -
frustum＠pacbell.net -
jcwren＠jcwren.com -
jfoust＠threedee.com -
jhellige＠earthlink.net -
ms＠silke.rt.schwaben.de -
RCini＠congressfinancial.com -
spc＠conman.org -
tothwolf＠concentric.net -
vaxzilla＠jarai.org -
wh.sudbrink＠verizon.net