[comp.lang.c++] cfront 2.* mishandles "if

shankar@hpclscu.HP.COM (Shankar Unni) (06/06/90)

Looks like cfront has a hard time dealing with function pointers in
conditional expressions. For instance:

   extern int foo();
   main()
   {
       if (foo) {
          /* ... */
       }
   }
   
   "foo.c", line 4: function != zero

Similar messages are put out when the function is used in other conditional
contexts.

The workaround seems to be to specify

   if (&foo) {
   }

From my reading of section 4.6 of the 2.0 (and 2.1) reference manuals
("Pointer conversions"),  the expression "foo" should get a type of
"pointer to function" (since I am neither calling it, nor applying an "&"
operator to it).

Is this a cfront bug, or am I missing something? Cfront even seems to be
going out of its way to put out this message...

-----
Shankar Unni                                   E-Mail: 
Hewlett-Packard California Language Lab.     Internet: shankar@hpda.hp.com
Phone : (408) 447-5797                           UUCP: ...!hplabs!hpda!shankar

shankar@hpclscu.HP.COM (Shankar Unni) (06/07/90)

>    extern int foo();
>    main()
>    {
>        if (foo) {
>           /* ... */
>        }
>    }
>    
>    "foo.c", line 4: function != zero

I've already received a couple of solicitous messages asking me whether I
didn't *really* mean:

  extern int (*foo)();

And the answer is: NO. I mean what I said. Yes, that check is a constant
compile-time check that *must* evaluate to non-zero by definition (if the
function is defined somewhere).

And I am not feeble-minded: this is not something that I did by accident,
nor is it something with a deep inner secret: it is merely a fragment
typical of the Plum Hall ANSI C test suite.

The worst thing is that cfront gives a HARD error (non-zero exit status),
not just a warning (which I could live with - Plum Hall is pretty forgiving
of warnings).

So back to the language lawyers and the cfront folks in AT&T: what gives?
-----
Shankar Unni.