🚀 go-pugleaf

ARM 8.2.5 states that "Functions cannot return arrays or functions,
although they can return pointers and references to such things."

Both g++ and Lucid compilers will generate errors and refuse to compile
programs that try to define or use functions returning references to
arrays.  Here's an example so you can test your favorite compiler:

typedef int jmp_buf [9];

class foo
{
public:
  jmp_buf my_buf;

  jmp_buf &get_my_buf ()    // Lucid CC doesn't like this
    { return (my_buf); }
};

void
use_my_buf (jmp_buf)
{
  // do_something ();
}

int
main ()
{
  foo bar;

  use_my_buf (bar.get_my_buf ());  // g++ and cfront (sort of) don't like this
  use_my_buf (bar.my_buf);         // therefore we're forced to use this
}


Here's what the different compilers produce:

GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.

ccbug.cc: In function `int  main ()':
ccbug.cc:23: incompatible types in argument passing


Lucid SPARC C/C++ Compiler, Version 2.1.3Beta [24-Dec-91]
_________________________________________________
E, ccbug.cc(9,52) Cannot convert type "int*" to return type "int[9]&"
                                                           v
9       inline __typedef41 foo::get_my_buf( ){return(my_buf) ; }
          ccbug.cc ... 1 Error.


Sun CC++ SC1.0 C++ 2.1 1Mar1991

"ccbug.cc", line 21: warning:  bar used but not set
"ccbug.cc", line 23: warning: & before array or function: ignored

cfront actually compiles this, but only by luck.  It still generates
code which assumes that it can pass an array by reference just by
returning a pointer to it.

It looks like all these compilers blissfully assume that a reference can
just be considered a hidden pointer.  They are sadly mistaken!

--
Dave Brennan                                      HaL Computer Systems
brennan@hal.com                                         (512) 794-2855

Visit the Emacs Lisp Archive: archive.cis.ohio-state.edu:pub/gnu/emacs