sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/cgo: cannot call functions with variable-argument lists.
Labels: NeedsInvestigation

by **akidan**:

<pre>A package such as the following will not compile with cgo. 
(printf is a contrived example, but this would be useful for bridging objective c
through id objc_msgSend(id self, SEL op, ...);)

--- (file foo.go)
package foo

// #include &lt;stdio.h&gt;
import &quot;C&quot;

func PrintStuff() {
    C.printf(C.CString(&quot;Hello&quot;))
}

---

$ cgo foo.go

What is the expected output?
Program compiles and is able to call function with variable-argument list.

What do you see instead?
unexpected type: ...

What is your $GOOS?  $GOARCH?
darwin amd64

Which revision are you using?  (hg identify)
43fd9bb529f0+ tip</pre>
Repository: go
Issue: os/v2: fix inconsistent casing in names
Labels: v2,NeedsInvestigation

<pre>Is there any sort of rule about the casing of functions used in the &quot;os&quot;
package?  Looking through, it doesn't sound like it's very easy to recall whether a
given function should be called LikeThat or Likethat.

For instance:

Mkdir
MkdirAll
TempDir
Getenv
ForkExec
Readlink
ReadAt
Readdir

It feels very ad-hoc, and hard to recall.</pre>
Repository: go
Issue: x/build: set up a qemu builder
Labels: help wanted,Builders,NeedsInvestigation,new-builder

by **m@capitanio.org**:

<pre>I noticed a significant improvements in the arm tool chain :-)
I think it makes now a sense to take a closer look at bugs
in different environments.

The first shot is a qemu in user mode:
qemu-arm version 0.12.5
The host is (ubuntu 10.10)
GOARCH=arm
GORUN=qemu-arm
hg identify ba58b167f1fc+ tip

I tried with disabled peep or with GOARM=5, the bugs are similar.

Some syscalls are not covered, (I would propose
a QUEMU_UM to disable tests that use them):

(epoll_create)
        netchan\
        rpc\
        websocket\

Some packages show a non-deterministic behaviour,
a few do always break. I have no clue if qemu, go or
both are buggy:

        go/printer\
        compress/flate\
        compress/gzip\
        compress/zlib\
        os\
        big\
        rpc/jsonrpc\
        sync\ #(+ run.bash)
        bytes\

After disabling them, the test-suite *passed* all remaining tests.

----

Script bugs:
        run.bash: cmd/ebnflint ???
        run.bash: doc/progs [ &quot;$GOHOSTOS&quot; == windows ] ???
        run.bash: doc/codelab/wiki

The test/run script fails with:
./run -v
sed: can't read ./tmp.go: No such file or directory
fail: chan/powser2.go
fail: chan/select3.go
109a110,119
&gt; =========== chan/powser2.go
&gt; throw: malloc/free - deadlock
&gt; 
&gt; [signal 0xb code=0x1 addr=0x0 pc=0x15720]
&gt; 
&gt; 
&gt; =========== chan/select3.go
&gt; qemu-arm: /build/buildd/qemu-kvm-0.12.5+noroms/cpu-exec.c:784: handle_cpu_signal:
Assertion `__ret == (abi_ulong)__ret' failed.
&gt; $RUNFILE: line 1: PID Aborted                 $E ./$A.out
&gt; 
158a169,174
&gt; 
&gt; =========== fixedbugs/bug243.go
&gt; Unsupported setsockopt level=41 optname=26 
&gt; qemu: Unsupported syscall: 250
&gt; Start pollServer: epoll_create: function not implemented
&gt; Unsupported setsockopt level=41 optname=26 
1 known bugs; 0 unexpected bugs; test output differs


The captured outputs are attached.</pre>


Attachments:
1. <a href="https://storage.googleapis.com/go-attachment/1508/0/qemu-um-bugs.txt">qemu-um-bugs.txt</a> (26808 bytes)
Repository: go
Issue: cmd/cgo: add C.WcharString
Labels: help wanted,FeatureRequest

<pre>for calling routines that need a wchar_t*</pre>
Repository: go
Issue: cmd/compile: 1.3MB program takes 290MB of memory to compile
Labels: Performance

<pre>When compiling pkg/exp/eval or test/64bit.go, RSS memory usage using 5g or 6g exceeds
100mb. 

What is the expected output?

RSS usage should be more inline with other packages, around 10-20 mb

What do you see instead?

When compiling pkg/exp/eval or test/64bit.go, RSS memory usage using 5g or 6g exceeds
100mb. 

Which compiler are you using (5g, 6g, 8g, gccgo)?

5g and 6g

Which operating system are you using?

Debian 6 amd64 and arm5

Which revision are you using?  (hg identify)

+tip

Please provide any additional information below.</pre>
Repository: go
Issue: cmd/link: generate mingw-compatible symbol table
Labels: NeedsInvestigation

<pre>As per summary.</pre>
Repository: go
Issue: image/jpeg: chroma downsampling ratios are restricted
Labels: NeedsInvestigation

by **laeuter**:

<pre>What steps will reproduce the problem?
1. Try to decode my JPEG photos

What is the expected output?
They should be decodable

What do you see instead?
A good number is rejected with the UnsupportedError &quot;chroma downsample ratio&quot;.
Inspection show that the (h,v) pairs of the components are (2,2), (1,1), (2,2).

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
MacOS X 10.7.1

Which revision are you using?  (hg identify)
32a5db196298 (release-branch.r60) release/release.r60.2

Please provide any additional information below.
I tried to recode the images by opening them in other programs, rotating and resaving
them, but in most cases the images remain undecodable.</pre>
Repository: go
Issue: x/pkgsite: generate static docs
Labels: NeedsInvestigation,FeatureRequest,pkgsite

<pre>It is fairly trivial to compile a given Go version and run the doc server locally to
search for an older API.

But it would be nice if golang.org provided access to docs per release. One simple
solution to this is to add an option to godoc to generate static docs on disk -- just a
tree of static files (search would be disabled of course). Then docs for old versions
could be made available somewhere in golang.org.

One additional benefit is that projects that want to ship docs could generate the static
files and provide the html files for download, or create pdfs, chms etc based on them.

PS: I tried searching for a similar issue; sorry if this is a duplicate.</pre>
Repository: go
Issue: cmd/compile: include registerization info for gdb
Labels: NeedsInvestigation

<pre>What steps will reproduce the problem?

foo.go:

package main

import &quot;os&quot;

type I interface{}

func main() {
    var i I = 1
    os.Exit(i.(int))
}

6g foo.go
6l foo.6
gdb 6.out
GNU gdb (GDB) 7.2-gg20
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later &lt;<a href="http://gnu.org/licenses/gpl.html&gt">http://gnu.org/licenses/gpl.html&gt</a>;
Type &quot;show copying&quot; and &quot;show warranty&quot; for licensing/warranty
details.
This GDB was configured as &quot;x86_64-linux&quot;.

&lt;<a href="http://wiki/Main/GnuDebugger">http://wiki/Main/GnuDebugger</a>  FAQ: <a href="http://go/gdb">http://go/gdb</a>  Email: gdb-team  IRC: #gdb&gt;
Hey, I'm GDB 7.x.  Check me out!  <a href="http://wiki/Main/Gdb7x">http://wiki/Main/Gdb7x</a>

Reading symbols from /home/iant/gcc/gccgo2-objdir/6.out...done.
Loading Go Runtime support.
(gdb) break foo.go:9
Breakpoint 1 at 0x400c36: file /home/iant/foo1.go, line 9.
(gdb) run
Starting program: /home/iant/gcc/gccgo2-objdir/6.out 

Breakpoint 1, main.main () at /home/iant/foo1.go:9
9       os.Exit(i.(int))
(gdb) print i
No symbol &quot;i&quot; in current context.
(gdb) info locals
No locals.
(gdb) step
runtime.assertE2T (t=void, e=void) at /home/iant/go/src/pkg/runtime/iface.c:286
286 runtime·assertE2T(Type *t, Eface e, ...)
(gdb) finish
Run till exit from #0  runtime.assertE2T (t=void, e=void)
    at /home/iant/go/src/pkg/runtime/iface.c:286
0x0000000000400c4f in main.main () at /home/iant/foo1.go:9
9       os.Exit(i.(int))
(gdb) print i
No symbol &quot;i&quot; in current context.
(gdb) step
os.Exit (code=1) at /home/iant/go/src/pkg/os/proc.go:34
34  func Exit(code int) { syscall.Exit(code) }



What is the expected output?

I expect to see information about the local variable.</pre>
Repository: go
Issue: cmd/gofix: typechecker should vet input
Labels: NeedsInvestigation

<pre>in gofix:

Method entries require &quot;func()&quot;.
Func entries require not having it.
both should be consistent, and the
type checker should panic when presented
with input it doesn't understand.</pre>
Repository: go
Issue: cmd/compile: static init maps should never generate code
Labels: Performance,NeedsInvestigation,binary-size

<pre>so that unreferenced maps can be dropped by linker</pre>
Repository: go
Issue: cmd/go: distingush between command line and gui apps on windows
Labels: OS-Windows

<pre>Something that is controlled by &quot;-H windows&quot; / &quot;-H windowsgui&quot; flag
in 8l/6l at this moment.</pre>
Repository: go
Issue: cmd/compile: why are stack frames so large?
Labels: Performance,help wanted

<pre>In src/cmd/go, scanPackage has a 1816-byte stack frame on my 64-bit Mac.
Quickly counting local variables I see about 46 words worth of automatics,
so 368 bytes.  Where is the rest?</pre>
Repository: go
Issue: x/tools/build/dashboard: email notify on subrepo breakages
Labels: NeedsInvestigation

<pre>Send mail when a sub-repository fails to build.</pre>
Repository: go
Issue: go/doc: collect methods from embedded interfaces
Labels: NeedsInvestigation

<pre>Summary says it all.</pre>
Repository: go
Issue: proposal: spec: cannot assign to a field of a map element directly: m["foo"].f = x
Labels: LanguageChange,Proposal,LanguageChangeReview

<pre>The non-addressability requirement of map index expressions makes sense by itself since
we don't want a surviving pointer to a map element.

But surely it should be ok to have an invisible temporary pointer p to the respective
field which is just used during the assignment (*p = x). It seems that this doesn't
introduce any more issues than what we have already when assigning to a larger map
element that cannot be assigned to atomically.

E.g., the following program should be legal:

package main

import &quot;fmt&quot;

var m = map[string]struct{x, y int} {
    &quot;foo&quot;: {2, 3},
}

func main() {
    m[&quot;foo&quot;].x = 4 // cannot assign to m[&quot;foo&quot;].x
    fmt.Println(m)
}</pre>
Repository: go
Issue: compress/flate: api to configure sliding window size
Labels: help wanted

<pre>It seems there is no way to set window size in current compress/flate API. (it looks
const value now)

In <a href="http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-05">http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-05</a>, there
is a parameter to limit the LZ77 sliding window size.
I think I need such API in go.net/websocket.

Could you add some API to set window size in future (after Go1)?

When tip added new API, could I use the package in Go1 with
import &quot;code.google.com/p/go/compress/flate&quot;
or so?</pre>
Repository: go
Issue: cmd/api: work with gccgo
Labels: Suggested

<pre>And use it to track the two implementations stay in sync.</pre>
Repository: go
Issue: x/pkgsite: list main programs / commands separately from other packages
Labels: NeedsInvestigation,pkgsite

<pre>This is a follow-up to the really nice update from Russ with CL:
<a href="http://golang.org/cl/5711058/">http://golang.org/cl/5711058/</a>

It will be nice to separate user ($GOPATH) commands from packages in directory listing.
One way to do this is to show user commands (from $GOPATH/src/cmd/*) in Commands view,
and not in Packages view.

godoc currently handles user packages found in $GOPATH nicely, by putting user packages
alongside built-in packages, so one sees all the packages available to him.

In the same vein, it will be nice if godoc can handle commands, by putting user commands
alongside built-in commands. 

For example, suppose you have:
  $GOPATH/src/{pkg1...n}
  $GOPATH/src/cmd/{cmd1...n}

It will be nice if godoc skips showing anything under src/cmd in the
&quot;Packages&quot; view (ie skip cmd/{cmd1...n}), and show stuff under src/cmd/
({cmd1...n}) in the &quot;Commands&quot; view. 

Currently, I see my commands in the Packages view, and the import line is wrong, and
there's really no extra information it gives, since I can't use the command code in any
other packages (so it ends up adding clutter).

To illustrate further, in my codebase, when I run godoc, I see my commands somewhere in
the middle of the pack, below my b###.net/* and bytes packages and before
code.google.com/* packages. It's very easy to miss (especially with the comfortable
spacing style), and you wouldn't realize those are not actually packages, but commands.
I then click the &quot;Commands&quot; link where I'd expect to see them, but see only
the standard ones (like go, gofmt, vet, yacc, etc). 

(This suggestion is limited to godoc alone; the definition of $GOPATH and its
interaction with go command shouldn't be affected)

##################### DETOUR ######################
It will also be nice if there's a quick link above Packages/Commands views to:
  .. (up one directory level) 
  Packages
  Commands

Currently, the .. is way at the bottom (along with Sub Directories), and to get to
Packages or Commands listing, you have to click References at the top and start over.


Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
Linux

Which revision are you using?  (hg identify)
ba91b34fe212+ tip

Please provide any additional information below.</pre>
Repository: go
Issue: x/build: allow installation in a different directory on macos
Labels: help wanted,OS-Darwin

<pre>The default is /usr/local/go, but it would be nice if it could do the right things if
you elect to install elsewhere.</pre>
Repository: go
Issue: gccgo: gcov branch coverage doesn't look quite right
Labels: NeedsInvestigation

<pre>What steps will reproduce the problem?

<a href="https://groups.google.com/d/msg/golang-nuts/g8DsZaN8o9Q/hsY_83nDGiMJ">https://groups.google.com/d/msg/golang-nuts/g8DsZaN8o9Q/hsY_83nDGiMJ</a>

What do you see instead?

look at a report like

<a href="http://alberts.github.com/home/alberts/deps/src/code.google.com/p/go.crypto/cast5/cast5.go.gcov.html">http://alberts.github.com/home/alberts/deps/src/code.google.com/p/go.crypto/cast5/cast5.go.gcov.html</a>

there's lots of untaken branches in places that look like code that doesn't involve
branches at all.

I'm wondering if it's due to bounds checks, allocations that could fail, etc.

Overall, I think these make the branch coverage numbers less useful than they could be.

Which compiler are you using (5g, 6g, 8g, gccgo)?

gccgo

Which operating system are you using?

linux

Which revision are you using?  (hg identify)

gofrontend rev ca4aaf510222</pre>
Repository: go
Issue: x/crypto/ssh/terminal: file descriptor type is inconvenient
Labels: NeedsInvestigation

by **jeff.allen**:

<pre>What steps will reproduce the problem?
1. write terminal.MakeRaw(os.Stdout.Fd())
2. notice it doesn't compile
3. write terminal.MakeRaw(int(os.Stdout.Fd()))

What is the expected output?

It would be nicer if MakeRaw agreed with Fd() that the type of a file descriptor is
uintptr.

Which revision are you using?  (hg identify)

bce220d03774 weekly/weekly.2012-03-22</pre>
Repository: go
Issue: x/pkgsite: support custom build tags list
Labels: NeedsInvestigation,FeatureRequest,pkgsite

<pre>Before filing a bug, please check whether it has been fixed since
the latest release: run &quot;hg pull&quot;, &quot;hg update default&quot;, rebuild, and
retry
what you did to reproduce the problem.  Thanks.

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. Run godoc on a package having some files with build constraints e.g. // +build ignore
2. The files are skipped by godoc and their contents are not reflected in godoc output.
I don't see the files listed either.
3.

What is the expected output?

I expected to see the information in godoc.

What do you see instead?
Nothing.

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
Linux

Which version are you using?  (run 'go version')
Running at tip, but go version gives:
go version weekly.2012-03-22 +de7e784537ac

Please provide any additional information below.</pre>
Repository: go
Issue: syscall: support 'mode 2 seccomp' on Linux
Labels: NeedsInvestigation

<pre>Ubuntu 12.04 LTS comes with &quot;mode 2 seccomp&quot; and the mainline kernel is
currenly in the process of accepting seccomp patches.

In short, &quot;mode 2 seccomp&quot; adds an ability to apply syscall filters to the
current process.

A good tutorial is <a href="http://outflux.net/teach-seccomp/">http://outflux.net/teach-seccomp/</a>
I have tested it with the daily build of Ubuntu 12.04 LTS,
$ uname -a
Linux krasin-seccomp 3.2.0-20-generic #32-Ubuntu SMP Thu Mar 22 02:22:46 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux

I understand that this feature is not on top of the priority, but when Go 1 is here, it
would be probably time to add this support.</pre>
Repository: go
Issue: go/build: ImportDir accepts directories that don't exist
Labels: Thinking

<pre>What steps will reproduce the problem?

<a href="http://play.golang.org/p/P1R9-ON7KU">http://play.golang.org/p/P1R9-ON7KU</a>

What is the expected output?

Some sort of error.

What do you see instead?

An incomplete build.Package describing something that doesn't exist.

Which compiler are you using (5g, 6g, 8g, gccgo)?

gc

Which version are you using?  (run 'go version')

go1</pre>
Repository: go
Issue: encoding/xml: foo>bar,attr - foo ignored
Labels: Suggested

by **krolaw**:

<pre>see - <a href="http://play.golang.org/p/KIbSFNO0Sz">http://play.golang.org/p/KIbSFNO0Sz</a>

In the case of foo&gt;bar,attr 
foo is ignored in both Marshal an Unmarshal.  This behavior contradicts tags.

Thanks.</pre>
Repository: go
Issue: doc: document typical runtime requirements of Go programs
Labels: Documentation,NeedsInvestigation

by **hadrien.grasland**:

<pre>While browsing the golang.org website, I was unable to find a satisfactory documentation
of the run-time requirements of Go programs.

I did explore the &quot;tiny&quot; toy OS kernel example of the Go source tree, but it
is now deprecated. The &quot;How is the run-time support implemented?&quot; FAQ entry,
on its side, only provides compiler-specific data, and with no guarantee that it will
remain valid in the future.

I believe that documenting these in the spec (the &quot;System considerations&quot;
section comes to mind) is important if Go is to be used for system programming tasks. As
of now, there is no way to clearly draw the line between what can be implemented in Go
and what must be implemented in a lower-level language like C or C++, in a manner that
won't change in the future. There is also no way to guarantee that switching or
upgrading compilers won't break existing Go system software by suddenly adding more
run-time requirements.</pre>
Repository: go
Issue: proposal: spec: remove string(int)
Labels: LanguageChange,Proposal,LanguageChangeReview

<pre>The conversion of an integer to a string was put in very early to bootstrap formatted
printing, if I remember correctly. It's odd, though, and no longer necessary, if it ever
was. It also causes inconsistencies, since string(0xD800) cannot produce the UTF-8
encoding for that code point (by definition, surrogates are not legal in UTF-8) so must
produce something else. We chose the &quot;\uFFFD&quot; since that's the only reasonable
option, but that means:

1) the result isn't obvious
2) string(0xD800) and &quot;\uD800&quot; do different things: the former produces the
UTF-8 for U+FFFD while the latter is statically rejected.

I propose that, in some remote future, we eliminate this conversion from the language.</pre>
Repository: go
Issue: reflect: MakeInterface
Labels: NeedsInvestigation

<pre>Feature request for MakeInterface, to go along with the newly-arrived MakeFunc (Issue
1765).

Good goal would be gomock without source code generation.</pre>
Repository: go
Issue: cmd/compile: output variable names in data race reports
Labels: RaceDetector

<pre>It would be nice if in data race reports we print variable size and symbolic name as
well. E.g. &quot;Read of 'foo.Bar'&quot;.</pre>
Repository: go
Issue: cmd/compile: eliminate duplicate instrumentation in racewalk
Labels: Performance,RaceDetector

<pre>Use simple analysis to eliminate duplicate instrumentation in cases like:

x = ...;
... = x;

Currently it leads to insertion of 2 raceread() calls.</pre>
Repository: go
Issue: crypto/aes: add assembly for non-AES-NI machines
Labels: Performance,NeedsInvestigation

<pre>golang https server described in <a href="https://golang.org/issue/4073?c=8">https://golang.org/issue/4073?c=8</a>
and tested with

siege --benchmark --concurrent=100 &quot;<a href="https://localhost:8082&quot">https://localhost:8082&quot</a>;

command gives

Lifting the server siege...      done.
Transactions:                    779 hits
Availability:                 100.00 %
Elapsed time:                  40.56 secs
Data transferred:               0.02 MB
Response time:                  4.85 secs
Transaction rate:              19.21 trans/sec
Throughput:                     0.00 MB/sec
Concurrency:                   93.11
Successful transactions:         779
Failed transactions:               0
Longest transaction:           10.22
Shortest transaction:           0.34

But nginx does better:

Transactions:                   5120 hits
Availability:                 100.00 %
Elapsed time:                  53.87 secs
Data transferred:               0.74 MB
Response time:                  1.04 secs
Transaction rate:              95.04 trans/sec
Throughput:                     0.01 MB/sec
Concurrency:                   98.92
Successful transactions:        5120
Failed transactions:               0
Longest transaction:            1.08
Shortest transaction:           0.15

hg id is 8e87cb8dca7d. windows/386.

linux/386 golang server does about the same:

Lifting the server siege...      done.
Transactions:                   1867 hits
Availability:                 100.00 %
Elapsed time:                 118.75 secs
Data transferred:               0.05 MB
Response time:                  6.23 secs
Transaction rate:              15.72 trans/sec
Throughput:                     0.00 MB/sec
Concurrency:                   97.89
Successful transactions:        1867
Failed transactions:               0
Longest transaction:           13.59
Shortest transaction:           0.32

<a href="https://golang.org/issue/4073?c=6">https://golang.org/issue/4073?c=6</a> claims similar results comparing to
&quot;hello world node.js app&quot;.

I would investigate more, but I know nothing about SSL.

Alex</pre>
Repository: go
Issue: syscall: package is underdocumented
Labels: Documentation,NeedsInvestigation

by **szopa@google.com**:

<pre>The standard library syscall package is underdocumented. I was trying to figure how to
write my own utimensat (unimplemented) and I was having a very hard time. What is more,
reading the source of the package doesn't really help, as its code is supposed to be
going through mksyscall.

What I would like to see:

1. An example of writing an unimplemented syscall.

2. How to pass arguments to syscalls (eg. strings should be pointers to nul terminated
byte sequences.

3. Information how to get the right uintptr (reflect or unsafe, when to use each of
them).

4. Documentation any types introduced.

5. A little bit of background information about syscalls would be nice, but that's not
strictly necessary.</pre>