Str returns *int8

[Inuart]

GoStr receives an *uint8, shouldn't Str return an *uint8 too?

[dmitshur]

That sounds like a valid point.

[emidoots]

I would guess the problem is more complex than that. I use GoStr with two functions: GetUniformLocation and GetAttribLocation, both of these functions take *int8 arguments.

I am not sure why this is exactly.

[Inuart]

Maybe it's easier to modify GoStr instead of Str.
This is my use case (having modified GoStr)

var L int32
gl.GetShaderiv(object, gl.INFO_LOG_LENGTH, &L)
if L > 1 {
    buff := make([]int8, L)
    gl.GetShaderInfoLog(object, L, &L, &buff[0])
    println(gl.GoStr(&buff[0]))
}

[dmitshur]

We should go in the more correct direction, rather one that's easier to modify (in case the two don't match).

It seems glGetUniformLocation is defined to accept a pointer to GLchar, and GLchar is defined as char unfortunately.

GLint glGetUniformLocation(GLuint program,
                           const GLchar *name);

Given that it's meant to deal with strings, I think Go's byte aka uint8 is a more appropriate mapping. Thoughts?

[errcw]

Given that it's meant to deal with strings, I think Go's byte aka uint8 is a more appropriate mapping.

The challenge is that GLchar may be used in other functions where its signedness is meaningful so we cannot (trivially) use an unsigned Go type. If we believe GLchar is only ever used in string contexts then we could change the mapping. I scrubbed through gl.xml and the existing uses of GLchar all appear string-related. However future GL versions may break this assumption. There is an additional complication insofar as we're changing the API which may break existing programs.

I'm marginally in favour of making the switch.

GoStr receives an *uint8

For historical reference GoStr takes a *uint8 because glGetString returns GLubyte*. (Of course. Because the GL API is full of consistency wins...)

[Inuart]

I believe the only other normal use in C of the char type is to use it as a byte type. Switching to byte looks more future-proof to me.

[bryanturley]

In c char, signed char and unsigned char are different types. ;)
Everything else defaults to signed but char is ambiguous.

[bryanturley]

http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/C-Dialect-Options.html
Search page for -fsigned-char.
Just in case you don't believe me ;)

[Inuart]

So it is a uint8 and not a byte? I'm ok with that but what was de deciding factor?

[emidoots]

So it is a uint8 and not a byte? I'm ok with that but what was de deciding factor?

byte is just an alias for uint8, according to the Go spec:

http://golang.org/ref/spec#Numeric_types

EDIT: submitted early on accident.

[errcw]

We prefer uint8 over byte because some GL functions, such as glGetString, use GLubyte rather than GLchar.

[dmitshur]

@errcw Is there a typo in your post? It doesn't make sense. In Go, byte and uint8 are two aliases for the exact same type. int8 and uint8 (aka byte) are different types though.

[errcw]

Even if byte and uint8 represent the same type I wanted to unify the same declared type wherever possible, hence choosing uint8.

[dmitshur]

That makes sense. :)

[errcw]

Bah misclicked.

[Inuart]

We prefer uint8 over byte because some GL functions, such as glGetString, use GLu byte rather than GLchar.

That sounds like the perfect use for byte. Represents 8 bits of "data" rather than a [0-255] number.

[dmitshur]

I don't disagree. Most Go funcs in standard library use byte rather than uint8 to refer to an unsigned integer type of size 1 byte, when it comes to dealing with text.

This is completely a human presentation difference. The two types are completely identical and interchangeable. The Go code cannot tell them apart, because, as soon as it enters the compiler and loses its human readable type name, there's only one underlying type.

http://play.golang.org/p/vCBcvzXzyr

You could change a library's func signature from byte to uint8 and back every day, and no one would notice.

[bryanturley]

It is a problem. In my binding generator I wrote a set of complicated rules to determine if something was a c string or just a byte array. It would be better to get them to fix the xml though.
https://github.com/bryanturley/glgen3/blob/master/reg.go#L748
It doesn't do arrays of strings though... (glShaderSource)

[errcw]

I agree we could have easily chosen byte vs. uint8 for both GLchar and GLubyte. And indeed I would not object to a PR that made the switch. My thinking was I wanted the types for GLbyte and GLubyte to be similar which implies int8 and uint8. Once GLubyte is uint8 then the effectively synonymous type GLchar should also be uint8.

[bryanturley]

I also chose uint8 for that exact reason, int8 and uint8.
The only reason I ever use byte is because it is one letter shorter and I am lazy.
Should also note that GLbyte is signed and go byte is unsigned.
GLbyte becomes int8
GLubyte becomes byte == confusion.