Re: [cc65] More on the prototype bug

> 
> 
> On Fri, Mar 31, 2006 at 01:55:32PM -0500, Andrew J. Kroll wrote:
> > I turned on the important debugging and captured the following data.
> >
> > Left : 00AE B4A8 9010 8000 8000 8000 006D 0121
> > Right: 00AE B738 9010 8000 8000 8000 006D 0121
> >              ^^
> > Note these bits here cause the error message to apear.
> >
> > What are the meaning of those bits?
> 
> 0x00AE means "function". The next five numbers are an encoded pointer to the
> function descriptor (which explains why they are different)[1]. 0x006D means
> "pointer to" and 0x0121 means "unsigned char". So both numbers translate to
> 
>         "function returning pointer to unsigned char"
> 
> The parameter list is encoded in the function descriptor.
> 
> > I've tried to go thru the include files in the source for difinitions,
> > but they don't seem to be meaningful when I decode them.
> 
> The necessary bits are in datatype.h at the beginning.
> 
> > Here's the testcase again, incase anyone else wishes to see what is going
> > on. Sometimes it helps to have an extra set of eyes on the bug.
> 
> Why do you insist on using K&R functions together with non K&R prototypes?
> Yes, it's definitely a bug in cc65. But K&R style C has been marked as
> obsolete in the C standard from 1999. It should be avoided when writing new
> code. Your code won't be compatible with K&R anyway, since K&R compilers don't
> understand prototypes, so I cannot see a reason for mixing the two styles.

The code in the project actually uses a set of wrapper macros to protoize the
prototypes for K&R compilers, such as BCC, so that the code may be compiled
under ELKS... As I stated before, if it were not for BCC, I would have stuck
to ANSI type function declarations. See the previous posting for the website
link.

I would like to also make another point. 
I realize that K&R style went the way of the Dodo bird with C99 spec, however 
your compiler has a C89 switch... :-) 
Therefore to be C89 compatable, you'd need to support the style reguardless.
However I know you realize this now anyway.
The unfortunate part is that since there's no way to guarentee a varidac
macro on older K&R compilers, I can't wrap the declarations with a macro,
well, I possibly could, but I'm sure it would be fantasticly ugly, and make
the source code incredibly difficult to read. :-(
 
> [1] Note: This was non portable and has therefore changed in the latest
> snapshot. So if you try this with the snapshot, the output will be different.
> 

Thank you again for your fast reply.
Yours,
-- 
Andrew J. Kroll
Software and Hardware Engineer and Consultant
Grafixoft http://dr.ea.ms/HW/
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.