1
0
mirror of https://github.com/golang/go synced 2024-11-25 00:57:59 -07:00

doc: Update gccgo information for recent changes.

R=r
CC=golang-dev
https://golang.org/cl/1941052
This commit is contained in:
Ian Lance Taylor 2010-08-23 17:50:30 -07:00
parent 668f05aaf1
commit 659966a988
2 changed files with 15 additions and 19 deletions

View File

@ -224,12 +224,9 @@ gccgo -o main main.o mypackage.o # Explicitly links with mypackage.o
<p>
Some Go features are not yet implemented in <code>gccgo</code>. As of
2009-11-06, the following are not implemented:
2010-08-23, the following are not implemented:
<ul>
<li>Garbage collection is not implemented. There is no way to free memory.
Thus long running programs are not supported.
<li>goroutines are implemented as NPTL threads. If you can not use
the gold linker as described above, they are created with a fixed
stack size, and the number of goroutines that may be created at
@ -263,14 +260,13 @@ Pointers in Go are pointers in C. A Go <code>struct</code> is the same as C
<code>struct</code> with the same fields and types.
<p>
The Go <code>string</code> type is a pointer to a structure.
The current definition is
(this is <b style="color: red;">expected to change</b>):
The Go <code>string</code> type is currently defined as a two-element
structure (this is <b style="color: red;">subject to change</b>):
<pre>
struct __go_string {
size_t __length;
unsigned char __data[];
const unsigned char *__data;
int __length;
};
</pre>
@ -310,9 +306,10 @@ when the functions have equivalent types.
<p>
Go <code>interface</code>, <code>channel</code>, and <code>map</code>
types have no corresponding C type (they roughly correspond to pointers
to structs in C, but the structs are deliberately undocumented). C
<code>enum</code> types correspond to some Go type, but precisely
types have no corresponding C type (<code>interface</code> is a
two-element struct and <code>channel</code> and <code>map</code> are
pointers to structs in C, but the structs are deliberately undocumented). C
<code>enum</code> types correspond to some integer type, but precisely
which one is difficult to predict in general; use a cast. C <code>union</code>
types have no corresponding Go type. C <code>struct</code> types containing
bitfields have no corresponding Go type. C++ <code>class</code> types have
@ -359,12 +356,15 @@ i := c_open(&amp;name[0], os.O_RDONLY, 0);
<p>
The name of Go functions accessed from C is subject to change. At present
the name of a Go function that does not have a receiver is
<code>package.Functionname</code>. To call it from C you must set the
name using a <code>gcc</code> extension similar to the <code>gccgo</code>
<code>prefix.package.Functionname</code>. The prefix is set by
the <code>-fgo-prefix</code> option used when the package is compiled;
if the option is not used, the default is simply <code>go</code>.
To call the function from C you must set the name using
a <code>gcc</code> extension similar to the <code>gccgo</code>
extension.
<pre>
extern int go_function(int) __asm__ ("mypackage.Function");
extern int go_function(int) __asm__ ("myprefix.mypackage.Function");
</pre>
<h3 id="Automatic_generation_of_Go_declarations_from_C_source_code">

View File

@ -5150,8 +5150,4 @@ The following minimal alignment properties are guaranteed:
<li><span class="alert">Implementation does not honor the restriction on goto statements and targets (no intervening declarations).</span></li>
<li><span class="alert">Method expressions are partially implemented.</span></li>
<li><span class="alert">Gccgo: allows only one init() function per source file.</span></li>
<li><span class="alert">Gccgo: Deferred functions cannot access the surrounding function's result parameters.</span></li>
<li><span class="alert">Gccgo: Function results are not addressable.</span></li>
<li><span class="alert">Gccgo: Recover is not implemented.</span></li>
<li><span class="alert">Gccgo: The implemented version of panic differs from its specification.</span></li>
</ul>