mirror of
https://github.com/golang/go
synced 2024-09-24 07:10:12 -06:00
116 lines
4.2 KiB
HTML
116 lines
4.2 KiB
HTML
<!--{
|
|
"Title": "Go 1.1 Release Notes",
|
|
"Path": "/doc/go1.1",
|
|
"Template": true
|
|
}-->
|
|
|
|
<h2 id="introduction">Introduction to Go 1.1</h2>
|
|
|
|
TODO
|
|
- overview
|
|
- link back to Go 1 and also Go 1 Compatibility docs.
|
|
|
|
<h2 id="language">Changes to the language</h2>
|
|
|
|
TODO
|
|
|
|
<h2 id="impl">Changes to the implementations and tools</h2>
|
|
|
|
TODO: more
|
|
|
|
<h3 id="int">Size of int on 64-bit platforms</h3>
|
|
|
|
<p>
|
|
The language allows the implementation to choose whether the <code>int</code> type and <code>uint</code> types are 32 or 64 bits. Previous Go implementations made <code>int</code> and <code>uint</code> 32 bits on all systems. Both the gc and gccgo implementations (TODO: check that gccgo does) <a href="http://golang.org/issue/2188">now make <code>int</code> and <code>uint</code> 64 bits on 64-bit platforms such as AMD64/x86-64</a>.
|
|
Among other things, this enables the allocation of slices with
|
|
more than 2 billion elements on 64-bit platforms.
|
|
</p>
|
|
|
|
<p>
|
|
<em>Updating</em>:
|
|
Most programs will be unaffected by this change.
|
|
Because Go does not allow implicit conversions between distinct
|
|
<a href="/ref/spec#Numeric_types">numeric types</a>,
|
|
no programs will stop compiling due to this change.
|
|
However, programs that contain implicit assumptions
|
|
that <code>int</code> is only 32 bits may change behavior.
|
|
For example, this code prints a positive number on 64-bit systems and
|
|
a negative one on 32-bit systems:
|
|
|
|
<pre>
|
|
x := ^uint32(0) // x is 0xffffffff
|
|
i := int(x) // i is -1 on 32-bit systems, 0xffffffff on 64-bit
|
|
fmt.Println(i)
|
|
</pre>
|
|
|
|
<p>Portable code intending 32-bit sign extension (yielding -1 on all systems)
|
|
would instead say:
|
|
</p>
|
|
|
|
<pre>
|
|
i := int(int32(x))
|
|
</pre>
|
|
|
|
<h3 id="asm">Assembler</h3>
|
|
|
|
<p>
|
|
Due to the <a href="#int">int</a> and TODO: OTHER changes,
|
|
the placement of function arguments on the stack has changed.
|
|
Functions written in assembly will need to be revised at least
|
|
to adjust frame pointer offsets.
|
|
</p>
|
|
|
|
<h3 id="race">Data race detector</h3>
|
|
|
|
<p>
|
|
The implementation now includes a built-in <a href="/doc/articles/race_detector.html">data race detector</a>.
|
|
</p>
|
|
|
|
<h2 id="library">Changes to the standard library</h2>
|
|
|
|
<h3 id="debug/elf">debug/elf</h3>
|
|
<p>
|
|
Previous versions of the debug/elf package intentionally skipped over the first
|
|
symbol in the ELF symbol table, since it is always an empty symbol. This symbol
|
|
is no longer skipped since indexes into the symbol table returned by debug/elf,
|
|
will be different to indexes into the original ELF symbol table. Any code that
|
|
calls the debug/elf functions Symbols or ImportedSymbols may need to be
|
|
adjusted to account for the additional symbol and the change in symbol offsets.
|
|
</p>
|
|
|
|
<h3 id="net">net</h3>
|
|
|
|
<p>
|
|
The protocol-specific resolvers were formerly
|
|
lax about the network name passed in. For example, although the documentation was clear
|
|
that the only valid networks for <code>ResolveTCPAddr</code> are <code>"tcp"</code>,
|
|
<code>"tcp4"</code>, and <code>"tcp6"</code>, the Go 1.0 implementation silently accepted
|
|
any string. The Go 1.1 implementation returns an error if the network is not one of those strings.
|
|
The same is true of the other protocol-specific resolvers <code>ResolveIPAddr</code>, <code>ResolveUDPAddr</code>, and
|
|
<code>ResolveUnixAddr</code>.
|
|
</p>
|
|
|
|
<p>
|
|
The previous <code>ListenUnixgram</code> returned <code>UDPConn</code> as
|
|
arepresentation of the connection endpoint. The Go 1.1 implementation
|
|
returns <code>UnixConn</code> to allow reading and writing
|
|
with <code>ReadFrom</code> and <code>WriteTo</code> methods on
|
|
the <code>UnixConn</code>.
|
|
</p>
|
|
|
|
<h3 id="time">time</h3>
|
|
<p>
|
|
On FreeBSD, Linux, NetBSD, OS X and OpenBSD, previous versions of the time package
|
|
returned times with microsecond precision. The Go 1.1 implementation of time on these
|
|
systems now returns times with nanosecond precision. Code may exist that expects to be
|
|
able to store such a time in an external format with only microsecond precision,
|
|
read it back, and recover exactly the same time instant.
|
|
In Go 1.1 the same time will not be recovered, since the external storage
|
|
will have discarded nanoseconds.
|
|
To address this case, there are two new methods of time.Time, Round and Truncate,
|
|
that can be used to remove precision from a time before passing it to
|
|
external storage.
|
|
</p>
|
|
|
|
TODO
|