sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: image/jpeg: correct for EXIF orientation?
Labels: Thinking

<pre>JPEG files can embed EXIF metadata specifying one of 8 mirroring+rotation options.  Only
2-3 of these are in common use, from people holding their phones sideways when taking
pictures.

It would be nice of the image/jpeg package could, perhaps optionally, correct for these.

Camlistore will be doing it on its own, but it seems like something the image/jpeg
package is in a good position to do automatically.

It's probably only safe to do the left-90 and right-90 ones automatically (and only when
width &amp; height change), so users can detect whether the operation has already been
done and not apply the transformation again, as orientation-fixing code has to do anyway
(because you can't trust whether upstream software in the wild fixed the metadata for
you when it flipped-and-resaved the image, so you also have to check the before &amp;
after dimensions).

If we want to do this in image/jpeg, I've attached a screenshot of the 8 modes and a
tarball of 16 JPEG files: 1 for each mode without EXIF, and 1 for each mode with the
Orientation field set to &quot;fix&quot; the image back to a lowercase eff letter.  The
f files are written on 8x8 pixel boundaries, so we can do pixel-wise compares in tests
safely.</pre>


Attachments:
1. <a href="https://storage.googleapis.com/go-attachment/4341/0/exif-orientations.png">exif-orientations.png</a> (22969 bytes)
2. <a href="https://storage.googleapis.com/go-attachment/4341/0/f.tar">f.tar</a> (30720 bytes)
Repository: go
Issue: cmd/compile: possible error message improvement
Labels: NeedsInvestigation

<pre><a href="http://play.golang.org/p/87zosrj611">http://play.golang.org/p/87zosrj611</a>

package main

var x = 10
var y = 0.9 * x

prog.go:4: constant 0.9 truncated to integer

If you don't know that x is an int or that * requires both sides to have the same type,
this is a bit of a leap.

constant 0.9 truncated during conversion to type int (to match x)

might be a little better.</pre>
Repository: go
Issue: cmd/compile: which errors are confusing?
Labels: Suggested

<pre>It would be fascinating to take each of the yyerror statements in cmd/gc and plug it
into a google search to find mailing list threads about the errors. How are they
misinterpreted? What could be clearer?</pre>
Repository: go
Issue: x/pkgsite: switch to use html/template
Labels: Security,pkgsite

<pre>Godoc should use the auto-escaping htm/template package instead of text/template, for
security reasons.

With text/template, it is hard to write UI code that doesn't introduce content injection
vulnerabilities.</pre>
Repository: go
Issue: doc/tour: write more tours
Labels: Documentation,NeedsInvestigation

by **jimmyok@google.com**:

<pre>The go lang tour expects coding experience in a previous language, with comments like
&quot;type does what you would expect&quot; 

I think for someone with little to no previous coding experience the tour would be next
to impossible to finish. There are also a lot of examples with complex mathematical
operations, such as re-writing sqrt and Fibonacci for experienced programmers this would
be fine, but If I was trying to get a member of my family to go through the tour they
would probably leave at that point.</pre>
Repository: go
Issue: cmd/compile: error message for bad case in switch should suggest select
Labels: Thinking

<pre>When writing a switch statement like this:

package main

func main() {
    ch := make(chan int)    
    switch {
    case &lt;-ch:
    default:
    }
}

The compiler error is:

prog.go:6: invalid case &lt;-ch in switch (mismatched types int and bool)

This is a correct message, but for cases where the user is doing channel operations in
the cases, can we add to the parenthetical &quot;; did you mean select?&quot; ? It
shouldn't be displayed if the type of the channel expression is bool, obviously.</pre>
Repository: go
Issue: text/template: Allow func to take region as final argument
Labels: Thinking,FeatureRequest

<pre>I would like to extend Go templates to allow funcs to accept a region as an argument. 
This is useful any time you want to process or transform a section of text. 

For example, I would like to write a func that performs syntax highlighting
(server-side, while all existing solutions are in javascript):

{{/* A sample template */}}
...
A description of my ExampleFunc function and an example of its usage:
{{prettify &quot;go&quot;}}
func ExampleFunc() {
  ...
}
{{end}}

For that, I would like to use a template func with a signature like:

&quot;prettify&quot;: func(lang, body string) template.HTML

The value of the parameter is the region, already executed.  This is necessary to allow
usage of template functionality within the region:

{{prettify &quot;go&quot;}}
  {{range .examples}}
    func Example1() {
      {{.}}
    }
  {{end}}
{{end}}

The func may be called using the current convention, e.g. {{prettify &quot;go&quot;
&quot;func x()&quot;}}, but the template system allows any func with a final argument of
type &quot;string&quot; to use the region form.</pre>
Repository: go
Issue: cmd/compile: omit zeroing of named return value when possible
Labels: NeedsInvestigation

<pre>In the program below, f1 and f2 should ideally generate the same code: if a return
variable name is never mentioned in the function and there are no returns without
arguments and no defer statements, the variable need not be cleared on entry:

g% cat x.go
package main

type T [16]int

func f1() (t T) {
    return g()
}

func f2() T {
    return g()
}

func g() T
g% go tool 6g -S x.go

--- prog list &quot;f1&quot; ---
0000 (x.go:5) TEXT    f1+0(SB),$256-128
0001 (x.go:5) LEAQ    t+0(FP),DI
0002 (x.go:5) MOVQ    $0,AX
0003 (x.go:5) MOVQ    $16,CX
0004 (x.go:5) REP     ,
0005 (x.go:5) STOSQ   ,
0006 (x.go:6) CALL    ,g+0(SB)
0007 (x.go:6) LEAQ    (SP),BX
0008 (x.go:6) LEAQ    autotmp_0000+-128(SP),BP
0009 (x.go:6) MOVQ    BP,DI
0010 (x.go:6) MOVQ    BX,SI
0011 (x.go:6) MOVQ    $16,CX
0012 (x.go:6) REP     ,
0013 (x.go:6) MOVSQ   ,
0014 (x.go:6) LEAQ    autotmp_0000+-128(SP),BX
0015 (x.go:6) LEAQ    t+0(FP),BP
0016 (x.go:6) MOVQ    BP,DI
0017 (x.go:6) MOVQ    BX,SI
0018 (x.go:6) MOVQ    $16,CX
0019 (x.go:6) REP     ,
0020 (x.go:6) MOVSQ   ,
0021 (x.go:6) RET     ,

--- prog list &quot;f2&quot; ---
0022 (x.go:9) TEXT    f2+0(SB),$256-128
0023 (x.go:10) CALL    ,g+0(SB)
0024 (x.go:10) LEAQ    (SP),BX
0025 (x.go:10) LEAQ    autotmp_0001+-128(SP),BP
0026 (x.go:10) MOVQ    BP,DI
0027 (x.go:10) MOVQ    BX,SI
0028 (x.go:10) MOVQ    $16,CX
0029 (x.go:10) REP     ,
0030 (x.go:10) MOVSQ   ,
0031 (x.go:10) LEAQ    autotmp_0001+-128(SP),BX
0032 (x.go:10) LEAQ    .noname+0(FP),BP
0033 (x.go:10) MOVQ    BP,DI
0034 (x.go:10) MOVQ    BX,SI
0035 (x.go:10) MOVQ    $16,CX
0036 (x.go:10) REP     ,
0037 (x.go:10) MOVSQ   ,
0038 (x.go:10) RET     ,

--- prog list &quot;init&quot; ---
0039 (x.go:13) TEXT    init+0(SB),$0-0
0040 (x.go:13) MOVBQZX initdone·+0(SB),AX
0041 (x.go:13) CMPB    AX,$0
0042 (x.go:13) JEQ     ,48
0043 (x.go:13) CMPB    AX,$2
0044 (x.go:13) JNE     ,46
0045 (x.go:13) RET     ,
0046 (x.go:13) CALL    ,runtime.throwinit+0(SB)
0047 (x.go:13) UNDEF   ,
0048 (x.go:13) MOVB    $2,initdone·+0(SB)
0049 (x.go:13) RET     ,
g%</pre>
Repository: go
Issue: cmd/go: go get broken for bzr with no-tree repos
Labels: ExpertNeeded,Suggested

by **bigjools**:

<pre>What steps will reproduce the problem?
1. Set up no-tree repos, or,
  in bazaar.conf, set up an alias: &quot;branch = branch --no-tree&quot;
3. &quot;go get launchpad.net/juju-core/...&quot;

What is the expected output?
A valid working tree.


What do you see instead?
go get fails because my package tree is not checked out of the repo:

$ go get -v launchpad.net/juju-core/...
launchpad.net/juju-core (download)
# cd /home/ed/canonical/Go/src/launchpad.net/juju-core; bzr update -r revno:-1
bzr: ERROR: No WorkingTree exists for
&quot;file:///home/ed/canonical/Go/src/launchpad.net/juju-core/.bzr/checkout/&quot;.
package launchpad.net/juju-core/...: exit status 3



Which compiler are you using (5g, 6g, 8g, gccgo)?
How do I find out?

Which operating system are you using?
Ubuntu 12.10

Which version are you using?  (run 'go version')
go1.0.2

Please provide any additional information below.</pre>
Repository: go
Issue: cmd/compile: init loop does not trace through inlined functions
Labels: NeedsInvestigation

<pre>$ cat x.go
package p
var x = f
func f() { g() }
func g() { _ = x }
$ 6g x.go
x.go:2: initialization loop:
    x.go:2 x refers to
    x.go:3 f refers to
    x.go:2 x

Should be f refers to g refers to x (but g has been inlined into f and been dropped).</pre>
Repository: go
Issue: go/printer: unhappy formatting of const declaration
Labels: NeedsInvestigation

<pre>in go/parser/interface.go:

const (
    PackageClauseOnly Mode             = 1 &lt;&lt; iota // parsing stops after package clause
    ImportsOnly                                    // parsing stops after import declarations
    ParseComments                                  // parse comments and add them to AST
    Trace                                          // print a trace of parsed productions
    DeclarationErrors                              // report declaration errors
    SpuriousErrors                                 // same as AllErrors, for backward-compatibility
    AllErrors         = SpuriousErrors             // report all (not just the first 10) errors per file
)

One would expect the &quot;=&quot; to line up. The algorithm for that layout has been
tweaked many times, though. Revisit at some point.</pre>
Repository: go
Issue: compress/bzip2: implement bz2 encoder
Labels: FeatureRequest

by **johnkgallagher**:

<pre>All the other compress/* packages include both decompression and compression.
compress/bzip2 only supports decompression.</pre>
Repository: go
Issue: go/build: should package be aware of GOBIN?
Labels: NeedsInvestigation

<pre>When using build.Import(&quot;GOPATH/src/myCmd&quot;, &quot;&quot;, 0) a *Package is
returned that has the field BinDir set to be GOPATH/bin. 
Package.BinDir is documented as &quot;command install directory&quot;.
However: cmd/go states &quot;If the GOBIN environment variable is set, commands are
installed to the directory it names instead of DIR/bin.&quot;
(<a href="http://golang.org/cmd/go/#hdr-GOPATH_environment_variable)">http://golang.org/cmd/go/#hdr-GOPATH_environment_variable)</a>

Is it up to pkg/go/build to check for the existence of GOBIN? Or should a user
implementation check for GOBIN?

Example of a fix:
<a href="https://github.com/GeertJohan/rerun/commit/b3bf4d74391a31fb9d313b07535388a47c3eae87">https://github.com/GeertJohan/rerun/commit/b3bf4d74391a31fb9d313b07535388a47c3eae87</a>

pkg/go/build source code concerning the *Package BinDir field:
<a href="http://code.google.com/p/go/source/browse/src/pkg/go/build/build.go#521">http://code.google.com/p/go/source/browse/src/pkg/go/build/build.go#521</a></pre>
Repository: go
Issue: cmd/asm: MOVL $x-8(SP) and LEAL x-8(SP) are different
Labels: NeedsInvestigation

<pre>MOVL $x-8(SP), AX assembles to raw LEAL -8(SP), AX.
LEAL x-8(SP), AX assembles to raw LEAL (framesize-8)(SP), AX.
It's a bit confusing that they have different interpretations of x-8(SP).

Same for MOVQ on 6a.

Can wait until after Go 1 because I think I'm the only one who ever uses that form
instead of writing LEAL/LEAQ.</pre>
Repository: go
Issue: cmd/go: reorganize documentation
Labels: Documentation,NeedsFix,GoCommand

<pre>The documentation for the go command appears in doc.go and then again in various files,
plus appendices in package testing and package go/build. It's unwieldy to maintain and
hard for users to think of where to look for each question. It would be nice to tidy
this up at some point.</pre>
Repository: go
Issue: image/gif: decoding untrusted (very large) images can cause huge memory allocations
Labels: Thinking

by **jeff.allen**:

<pre>What steps will reproduce the problem?
1. decode attached gif, get bad behavior due to giant malloc followed by giant memset(0).
2. finally get error about UnexpectedEOF because there is not as much pixel data as the
bounds say there should be.

The problem is that the gif has a frame in it that would need 4.2e9 bytes to hold
according to bounding box, but it only has 1 byte. The allocation of the 4.2e9 bytes
succeeds, but at considerable pain. Then the UnexpectedEOF is thrown.

What is the expected output?

Getting the error without allocating a huge amount of memory first.

What do you see instead?

Long pause and unresponsive computer due to giant memory allocation.

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')

tip</pre>


Attachments:
1. <a href="https://storage.googleapis.com/go-attachment/5050/0/bug525326.gif">bug525326.gif</a> (11606 bytes)
Repository: go
Issue: x/pkgsite/internal/fetch/dochtml: BUG, TODO etc. should be re-thought
Labels: Documentation,NeedsInvestigation,pkgsite,UX

<pre>Godoc needs updated rules and a nice UI for interpreting and presenting BUG(foo),
TODO(bar) etc. The current setup is odd: it treats things internal to functions
specially, while things at top level are too loosely bound. For instance,

// Foo bars blatz.
// BUG(gopher): Foo should bing bang bam.
func Foo() { } 

will fold the TODO onto the previous line, while

// BUG(gopher): Foo should bing bang bam.

// Foo bars blatz.
func Foo() { } 

will print the BUG for every query of the package. This is far from intuitive or helpful.</pre>
Repository: go
Issue: cmd/link: use more standard calling convention on arm
Labels: NeedsInvestigation

<pre>Unlike the 386 and amd64, arm stores the return address in the word at the top of the
stack rather than in the word below the incoming parameter area.

This is a deviation from the native arm calling convention which also stores the return
address below the incoming parameter area.

Following the native convention would make it easier and less error prone to translate
runtime code between all the supported targets.

The documentation for the native calling convention can be found at following address

<a href="http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf">http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf</a></pre>
Repository: go
Issue: cmd/gofmt: reformats block comments
Labels: Thinking

by **borman@google.com**:

<pre>What steps will reproduce the problem?

Use /* */ for block comments.  Example:

func f() {
        /*
         * don't do this right now
        fmt.Printf(`a
multi-line
string`)
        */
        return
}

Gofmt alters the content of the comment (which includes the /* and */).  The first time
gofmt is called it produces:

func f() {
        /*
                 * don't do this right now
                fmt.Printf(`a
        multi-line
        string`)
        */
        return
}

and if called again it produces:

func f() {
        /*
                         * don't do this right now
                        fmt.Printf(`a
                multi-line
                string`)
        */
        return
}

gofmt should not have altered the comment in the first place.  The /* was indented
correctly up front.</pre>
Repository: go
Issue: cmd/compile: more clever syntax error reporting
Labels: NeedsInvestigation

<pre>Using the go 1.0.3 compiler, the code at <a href="http://play.golang.org/p/mSSyjMd_MU">http://play.golang.org/p/mSSyjMd_MU</a> gives a
syntax error on line 15 that there is an unexpected ), while the actual error is that
there is a missing } on line 10. In this specific case, hypothetically the compiler
could realize the error is before line 15, because there are two return statements (line
10 and 12) otherwise. 

I imagine finding the &quot;true&quot; location of the syntax error in the general case
is hard to do, but I figured I would document the behavior in case something could be
done.</pre>
Repository: go
Issue: cmd/compile: too many errors stops too early -- check other related errors
Labels: NeedsInvestigation

<pre>I'm in the middle of debugging a package which is full of a bunch of code I wrote
quickly. At present, the package consists of three files

<a href="http://play.golang.org/p/XgNpoFpwcp">http://play.golang.org/p/XgNpoFpwcp</a>   filename fluidtensors.go
<a href="http://play.golang.org/p/p9897ak11y">http://play.golang.org/p/p9897ak11y</a>    filename threedtensor.go
<a href="http://play.golang.org/p/8QrkK-IzCp">http://play.golang.org/p/8QrkK-IzCp</a>     filename computations.go


when I run gc (version 1.0.3), I get the following output

brendan:~/Documents/mygo$ go build ransuq/tensor
# ransuq/tensor
src/ransuq/tensor/computations.go:9: re.SymTensor.Dim() used as value
src/ransuq/tensor/computations.go:10: re.SymTensor.Dim() used as value
src/ransuq/tensor/computations.go:11: re.SymTensor.Dim() used as value
src/ransuq/tensor/computations.go:13: re.SymTensor.Dim() used as value
src/ransuq/tensor/computations.go:25: tau.SymTensor.Dim() used as value
src/ransuq/tensor/computations.go:26: tau.SymTensor.Dim() used as value
src/ransuq/tensor/computations.go:27: tau.SymTensor.Dim() used as value
src/ransuq/tensor/computations.go:29: tau.SymTensor.Dim() used as value
src/ransuq/tensor/computations.go:41: tau.SymTensor.Dim() used as value
src/ransuq/tensor/computations.go:53: tau.SymTensor.Dim() used as value
src/ransuq/tensor/computations.go:53: too many errors

re.SymTensor.Dim() being used as a value is not a problem. The problem is that the Dim()
method of SymTensor (in threedtensor.go) is incorrectly returning a value. Relevant code
segment:

func (s *SymTensor) Dim() {
    return t.nDim
}

In the ideal case, the compiler would check that the full method of SymTensor is correct
before throwing the error about Dim() being used as a value. Barring that, it would be
nice if the compiler would output some other errors not of that form. The code is
computations is not logically incorrect, it's the code is threedtensor that's incorrect,
and so having this as the only output error is confusing.</pre>
Repository: go
Issue: runtime: consider caching previous map hash value
Labels: Performance

<pre>Michael Jones notes that the following pattern is common in Go code:

  if v, ok := map[key]; ok { // or !ok
      ....
      map[key] = newValue
  }

If hashing that key type is expensive (say: large string/struct) and the map isn't empty
or very small, the above code does it twice.

If we kept a per-P cache of the last key &amp; last computed hash value for that P, we
could eliminate some hash calls.

Probably worth measuring. (Probably not for Go 1.1)</pre>
Repository: go
Issue: encoding/json: use the Error method to marshal an error value?
Labels: Thinking,v2

<pre>What steps will reproduce the problem?
<a href="http://play.golang.org/p/epXpwk0s4s">http://play.golang.org/p/epXpwk0s4s</a>

What is the expected output?
Something like this:
<a href="http://play.golang.org/p/Dk0l6fTj01">http://play.golang.org/p/Dk0l6fTj01</a>

What do you see instead?
{&quot;bar&quot;:{},&quot;foo&quot;:{}}

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


Which operating system are you using?
Linux (Ubuntu 12.04, 3.2.0-38-generic)

Which version are you using?  (run 'go version')
go version go1.0.3
go version devel +5260abd6df41 Sat Mar 30 19:05:00 2013 +0800 linux/amd64

Please provide any additional information below.
I think it's not intuitive behaviour. fmt prints errors without problems, why json not?</pre>
Repository: go
Issue: proposal: database/sql: support a way to perform bulk actions
Labels: help wanted,Proposal,FeatureRequest

<pre>The current implementation of database/sql doesn't provide a way to insert multiple rows
at once, without getting to the wire upon every call to

db.Exec

There are APIs outside which either provide a general way for bulk actions

cf.  SQLBulkCopy of ADO.NET 2.0 [1]

or has a specifier upto how many statements should be grouped together

cf. Batch Update of ADO.NET 2.0 DataAdapter Object [1]

or simply supports an array to be bound to Exec, open which Exec iterates internally,
preventing execessive wire communication. [2]



[1] Codeproject, &quot;Multiple Ways to do Multiple Inserts&quot;
<a href="http://www.codeproject.com/Articles/25457/Multiple-Ways-to-do-Multiple-Inserts">http://www.codeproject.com/Articles/25457/Multiple-Ways-to-do-Multiple-Inserts</a>
[2] Python PEP 249 -- Python Database API Specification v2.0
<a href="http://www.python.org/dev/peps/pep-0249/#executemany">http://www.python.org/dev/peps/pep-0249/#executemany</a></pre>
Repository: go
Issue: cmd/link: support gdb debugging when hostlinking
Labels: NeedsInvestigation

<pre>When linking with the host linker, the .debug_gdb_scripts symbol isn't emitted, causing
the gdb python script to not be loaded.

It appears that this isn't the only problem since manually loading the script throws the
following error:

Loading Go Runtime support.
Traceback (most recent call last):
  File &quot;../go/src/pkg/runtime/runtime-gdb.py&quot;, line 198, in &lt;module&gt;
    _rctp_type = gdb.lookup_type(&quot;struct runtime.rtype&quot;).pointer()
gdb.error: No struct type named runtime.rtype.</pre>
Repository: go
Issue: cmd/cgo: -godefs doesn't handle embedded struct fields correctly
Labels: NeedsInvestigation

by **Mortdeus@gocos2d.org**:

<pre>Before filing a bug, please check whether it has been fixed since the
latest release. Search the issue tracker and check that you're running the
latest version of Go:

Run &quot;go version&quot; and compare against
<a href="http://golang.org/doc/devel/release.html">http://golang.org/doc/devel/release.html</a>  If a newer version of Go exists,
install it and retry what you did to reproduce the problem.

Thanks.

What steps will reproduce the problem?
This struct...

//&lt;libdrm/drm.h&gt;
struct drm_stats {
        unsigned long count;
    struct {
        unsigned long value;
        enum drm_stat_type type;
    } data[15];
};

When wrapped with cgo as

`
Stats C.struct_drm_stats
`

gets converted by godefs to

`
type Stats struct {
    Count uint64
    Data  [15]_Ctype_struct___0
}
`

What is the expected output?
type Stats struct {
         Count uint64
         Data [15]struct{
              Value uint64 //or uint32
              Type uint32
         }
}

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

Which operating system are you using?
archlinux x86-64

Which version are you using?  (run 'go version')
go version devel +4a712e80e9b1 Tue Apr 09 15:00:21 2013 -0700 linux/amd64

Please provide any additional information below.

<a href="https://github.com/mortdeus/egles/tree/master/drm">https://github.com/mortdeus/egles/tree/master/drm</a></pre>
Repository: go
Issue: cmd/cgo: godefs shouldnt try to guess which struct field's identifier prefixes preceding `_` is okay to strip.
Labels: NeedsInvestigation

by **Mortdeus@gocos2d.org**:

<pre>Godef may produce structs with multiple declarations of the same field identifiers if
its allowed to automatically strip the prefix of a C struct's field identifier. For
example,

When this C struct

struct drm_drawable_info {
    unsigned int num_rects;
        struct drm_clip_rect *rects;
};

is run through godefs it produces the following Go struct.

DrawableInfo struct {
    Rects uint32
    Pad_cgo_0 [4]byte
    Rects     *ClipRect
}

Which obviously isnt correct. 

The problem with this approach is...

A. I have to open the C source code to find out what the old identifier name used to be.
B. Obviously the tool isnt smart enough to know what prefixes are okay and which should
be stripped. 
C. This kind of &quot;magic&quot; implicit functionality is much better implemented as
explicit command line flag with the developer in control.</pre>