• ORCA/C type compatibility errors

    From Paul MacMillan@21:1/5 to All on Fri Oct 30 11:49:30 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From awanderin@21:1/5 to Paul MacMillan on Sat Oct 31 02:33:38 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From thefadden@gmail.com@21:1/5 to paul.s.m...@gmail.com on Sat Oct 31 08:30:46 2020
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul MacMillan@21:1/5 to Paul MacMillan on Sat Oct 31 10:57:42 2020
    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).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul MacMillan@21:1/5 to All on Sat Oct 31 10:49:03 2020
    I am using ORCA/C 2.2.0 B4, the error says "Type conflict."

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul MacMillan@21:1/5 to Paul MacMillan on Sat Oct 31 17:03:11 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kelvin Sherlock@21:1/5 to All on Sun Nov 1 19:58:45 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul MacMillan@21:1/5 to All on Sun Nov 1 15:15:00 2020
    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."

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Vavruska@21:1/5 to All on Fri Nov 6 12:00:27 2020
    Some people believe that warnings are just errors waiting to be uncovered.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)