Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #5712 > unrolled thread

ORCA/C type compatibility errors

Back to article view | Back to comp.sys.apple2.programmer

Contents

  ORCA/C type compatibility errors Paul MacMillan <paul.s.macmillan@gmail.com> - 2020-10-30 11:49 -0700
    Re: ORCA/C type compatibility errors awanderin <awanderin@gmail.com> - 2020-10-31 02:33 -0600
    Re: ORCA/C type compatibility errors "thef...@gmail.com" <thefadden@gmail.com> - 2020-10-31 08:30 -0700
      Re: ORCA/C type compatibility errors Paul MacMillan <paul.s.macmillan@gmail.com> - 2020-10-31 10:49 -0700
        Re: ORCA/C type compatibility errors Paul MacMillan <paul.s.macmillan@gmail.com> - 2020-10-31 10:57 -0700
          Re: ORCA/C type compatibility errors Paul MacMillan <paul.s.macmillan@gmail.com> - 2020-10-31 17:03 -0700
            Re: ORCA/C type compatibility errors kelvin@pro-kegs.uucp (Kelvin Sherlock) - 2020-11-01 19:58 -0500
              Re: ORCA/C type compatibility errors Paul MacMillan <paul.s.macmillan@gmail.com> - 2020-11-01 15:15 -0800
                Re: ORCA/C type compatibility errors Chris Vavruska <vavruska@gmail.com> - 2020-11-06 12:00 -0800

#5712 — ORCA/C type compatibility errors

In ORCA/C I get a compiler error when I try the following (which appears in Apple's and other's books)

   int toolTable[] = { 
      // <etc> 
   };
   LoadTools(toolTable);


But this works 

   LoadTools((char*)toolTable);

I didn't think an explicit cast would be needed -- it should make that cast for me right?  It seems that the APW C compiler would allow that. At worst, a compiler warning instead of an error? (for example gcc flags it as a warning)

Thanks

[toc] | [next] | [standalone]

#5713

Paul MacMillan <paul.s.macmillan@gmail.com> writes:

> In ORCA/C I get a compiler error when I try the following (which appears in Apple's and other's books)
>
>    int toolTable[] = { 
>       // <etc> 
>    };
>    LoadTools(toolTable);
>
>
> But this works 
>
>    LoadTools((char*)toolTable);
>
> I didn't think an explicit cast would be needed -- it should make that cast for me right?  It seems that the APW C compiler would allow that. At worst, a compiler warning instead of an error? (for example gcc flags it as a warning)


I tried this with Orca/C 2.0.1:

------------------------------
#include <toollib.h>

int toolTable[] = {
    1,
    4, 0x201
};

int main(int ac, char **av) {
    LoadTools(toolTable);
    return 0;
}
------------------------------

It compiles fine without errors.  Even if I don't use the header
<toollib.h> it still compiles error-free.

What compiler error is it giving you?

-- 
--
Jerry    awanderin at gmail dot com

[toc] | [prev] | [next] | [standalone]

#5714

On Friday, October 30, 2020 at 11:49:32 AM UTC-7, paul.s.m...@gmail.com wrote:
> In ORCA/C I get a compiler error when I try the following (which appears in Apple's and other's books) 
[...]
> But this works 
> 
> LoadTools((char*)toolTable); 

What is the error message?  What version of Orca/C are you using?

Note that the function _is_ declared to be a char*, so the cast is necessary to avoid a warning.  (It's a warning in C, but would be an error in C++.)  Looking at the headers on the Opus ][ CD in ByteWorks:ORCA:Libraries:ORCACDefs:

types.h:
  typedef char *ptr, *Ptr, *pointer, *Pointer;
locator.h:
  extern pascal void LoadTools(Pointer) inline(0x0E01,dispatcher);

"Pointer" should really be (void*), but it's possible Orca/C was written before that became part of the ANSI C standard.

@awanderin: ToolLib is something else, you want the Tool Locator declarations.

[toc] | [prev] | [next] | [standalone]

#5715

I am using ORCA/C 2.2.0 B4, the error says "Type conflict."  

[toc] | [prev] | [next] | [standalone]

#5716

On Saturday, October 31, 2020 at 10:49:04 AM UTC-7, Paul MacMillan wrote:
> I am using ORCA/C 2.2.0 B4, the error says "Type conflict."


And FWIW the ORCA 2.1 from Opus yields the same result (Type Conflict error vs. the expected Warning).

[toc] | [prev] | [next] | [standalone]

#5717

On Saturday, October 31, 2020 at 10:57:43 AM UTC-7, Paul MacMillan wrote:
> On Saturday, October 31, 2020 at 10:49:04 AM UTC-7, Paul MacMillan wrote:
> > I am using ORCA/C 2.2.0 B4, the error says "Type conflict."
> 
> 
> And FWIW the ORCA 2.1 from Opus yields the same result (Type Conflict error vs. the expected Warning).

I think changing the typedef in types.h of Pointer to void* is the way to go.  The error goes away. But I still think this is a compiler bug, as one would like to get warning when pointer types are recast (but not an error).

-Paul

[toc] | [prev] | [next] | [standalone]

#5718

ORCA/C's tool headers defer to APW C's headers and the toolbox manuals even
in some cases where they probably shouldn't.

APW C was K&R C so there are no function prototypes or void *s.

Under C89 (which includes ORCA/C), automatic pointer conversion (aside from
void *) isn't allowed.  The accompanying rationale even includes this text:

"It is invalid to convert a pointer to an object of any type to a pointer
to an object of a different type without an explicit cast."

The C99 rationale also includes the same text but the standard (6.3.2.3/7)
seems to allow the conversion.

-------
ProLine: kelvin@pro-kegs

[toc] | [prev] | [next] | [standalone]

#5719

Thanks Kelvin, makes sense, I guess what it comes down to for me is that ORCA/C doesn't try to distinguish between "warnings" and "errors" which is fine, better safe than sorry. 

For example, gcc on my Mac with -ansi and -c89 flags gives this a "warning."

[toc] | [prev] | [next] | [standalone]

#5720

Some people believe that warnings are just errors waiting to be uncovered.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web