FAQ
So what's the maximum length for a Go identifier?

Actually this problem is quite odd. Trying to "go build" this program:

https://github.com/metaleap/go-xsd/blob/master/xsd-makepkg/tests/xsd-test-svg/main.go

gives the following output:

# github.com/metaleap/t
c:\gd\pkg\windows_amd64/github.com/metaleap/go-xsd-pkg/www.w3.org/TR/2002/WD-SVG11-20020108/SVG.xsd_go.a(_go_.6):
name too long

So I created a small independent test program with a really really long
identifier name and its error message is different: "identifier too long".
(BTW would be *extreeemely* useful if this one and the above one both had
the format "identifier %s too long (has length %i, max is %i)" or some
such... most error messages throughout Go are great like that,
unfortunately these two aren't).

Also I should note that "go build" for the package being imported
(SVG.xsd_go) raises no issues about too-long identifiers (or names), and
creates the .a package just fine. I can also import that one into other
non-main packages and have *their* .a packages built just fine. Only when
finally attempting to use any such package in a main package for an
executable does this problem occur, I guess it's only then that "real
linking" of various .a's occurs.

As for said SVG package, this problem only started occurring when go-xsd
added support to add a Walk() method to any generated type, plus a
potentially quite "big" single struct var called W, starting (currently) at
line 9294:

https://github.com/metaleap/go-xsd-pkg/blob/master/www.w3.org/TR/2002/WD-SVG11-20020108/SVG.xsd_go/SVG.xsd.go#L9294

In auto-generated code you end up with some pretty weird combined
identifier names, so would be reaaally useful to know what kinds of limits
exist. The Go Spec says zilch about this, sadly. At least in the
"identifiers" section I was consulting. WIP I guess? I expect to find such
things in a spec document... ;)

I was also using the search function at golang.org looking for "name too
long". Ignoring the matches for gob/decode, dnsclient_unix and zerrors, the
other matches where in the linked-related packages (5l/6l/8l). That message
is being produced when a call to some "Blinelen" function returns a value >
0, but I couldn't find said function's definition with golang.org search,
so suppose it's a C func somewhere way deep in the compiler code-base...

So what are my options? If any of the identifiers in SVG.xsd.go are too
long, why wouldn't the compile stage complain with "identifier too long"
(rather than link stage with "name too long"), as it does when I just
experimentally manually add a simple way-too-long identifier?

--

Search Discussions

  • Rémy Oudompheng at Nov 16, 2012 at 6:26 pm
    what is the length of the full path to your source file?
    I think it cannot exceed 256 characters.

    Rémy.

    2012/11/16, Philipp Schumann <philipp.schumann@gmail.com>:
    So what's the maximum length for a Go identifier?

    Actually this problem is quite odd. Trying to "go build" this program:

    https://github.com/metaleap/go-xsd/blob/master/xsd-makepkg/tests/xsd-test-svg/main.go

    gives the following output:

    # github.com/metaleap/t
    c:\gd\pkg\windows_amd64/github.com/metaleap/go-xsd-pkg/www.w3.org/TR/2002/WD-SVG11-20020108/SVG.xsd_go.a(_go_.6):

    name too long

    So I created a small independent test program with a really really long
    identifier name and its error message is different: "identifier too long".
    (BTW would be *extreeemely* useful if this one and the above one both had
    the format "identifier %s too long (has length %i, max is %i)" or some
    such... most error messages throughout Go are great like that,
    unfortunately these two aren't).

    Also I should note that "go build" for the package being imported
    (SVG.xsd_go) raises no issues about too-long identifiers (or names), and
    creates the .a package just fine. I can also import that one into other
    non-main packages and have *their* .a packages built just fine. Only when
    finally attempting to use any such package in a main package for an
    executable does this problem occur, I guess it's only then that "real
    linking" of various .a's occurs.

    As for said SVG package, this problem only started occurring when go-xsd
    added support to add a Walk() method to any generated type, plus a
    potentially quite "big" single struct var called W, starting (currently) at

    line 9294:

    https://github.com/metaleap/go-xsd-pkg/blob/master/www.w3.org/TR/2002/WD-SVG11-20020108/SVG.xsd_go/SVG.xsd.go#L9294

    In auto-generated code you end up with some pretty weird combined
    identifier names, so would be reaaally useful to know what kinds of limits
    exist. The Go Spec says zilch about this, sadly. At least in the
    "identifiers" section I was consulting. WIP I guess? I expect to find such
    things in a spec document... ;)

    I was also using the search function at golang.org looking for "name too
    long". Ignoring the matches for gob/decode, dnsclient_unix and zerrors, the

    other matches where in the linked-related packages (5l/6l/8l). That message

    is being produced when a call to some "Blinelen" function returns a value >

    0, but I couldn't find said function's definition with golang.org search,
    so suppose it's a C func somewhere way deep in the compiler code-base...

    So what are my options? If any of the identifiers in SVG.xsd.go are too
    long, why wouldn't the compile stage complain with "identifier too long"
    (rather than link stage with "name too long"), as it does when I just
    experimentally manually add a simple way-too-long identifier?

    --

    --
  • Philipp Schumann at Nov 16, 2012 at 6:49 pm
    Thanks, but that's most likely not the issue. I checked this... With my
    $TMP set to c:\t\ none of the paths involved exceed 200. Also tried to
    go-build the above main.go from a real short path
    (c:\gd\src\github.com\metaleap\t\ just to try it). Also, this issue is only
    new since the introduction of said new "W" struct (used to be a longer
    name, "W" is part of my experimentation in reducing overall "nameage"....)


    On Saturday, November 17, 2012 2:20:35 AM UTC+8, Rémy Oudompheng wrote:

    what is the length of the full path to your source file?
    I think it cannot exceed 256 characters.

    Rémy.

    2012/11/16, Philipp Schumann <philipp....@gmail.com <javascript:>>:
    So what's the maximum length for a Go identifier?

    Actually this problem is quite odd. Trying to "go build" this program:

    https://github.com/metaleap/go-xsd/blob/master/xsd-makepkg/tests/xsd-test-svg/main.go
    gives the following output:

    # github.com/metaleap/t
    c:\gd\pkg\windows_amd64/
    github.com/metaleap/go-xsd-pkg/www.w3.org/TR/2002/WD-SVG11-20020108/SVG.xsd_go.a(_go_.6):
    name too long

    So I created a small independent test program with a really really long
    identifier name and its error message is different: "identifier too long".
    (BTW would be *extreeemely* useful if this one and the above one both had
    the format "identifier %s too long (has length %i, max is %i)" or some
    such... most error messages throughout Go are great like that,
    unfortunately these two aren't).

    Also I should note that "go build" for the package being imported
    (SVG.xsd_go) raises no issues about too-long identifiers (or names), and
    creates the .a package just fine. I can also import that one into other
    non-main packages and have *their* .a packages built just fine. Only when
    finally attempting to use any such package in a main package for an
    executable does this problem occur, I guess it's only then that "real
    linking" of various .a's occurs.

    As for said SVG package, this problem only started occurring when go-xsd
    added support to add a Walk() method to any generated type, plus a
    potentially quite "big" single struct var called W, starting (currently) at
    line 9294:

    https://github.com/metaleap/go-xsd-pkg/blob/master/www.w3.org/TR/2002/WD-SVG11-20020108/SVG.xsd_go/SVG.xsd.go#L9294
    In auto-generated code you end up with some pretty weird combined
    identifier names, so would be reaaally useful to know what kinds of limits
    exist. The Go Spec says zilch about this, sadly. At least in the
    "identifiers" section I was consulting. WIP I guess? I expect to find such
    things in a spec document... ;)

    I was also using the search function at golang.org looking for "name too
    long". Ignoring the matches for gob/decode, dnsclient_unix and zerrors, the
    other matches where in the linked-related packages (5l/6l/8l). That message
    is being produced when a call to some "Blinelen" function returns a value >
    0, but I couldn't find said function's definition with golang.orgsearch,
    so suppose it's a C func somewhere way deep in the compiler code-base...

    So what are my options? If any of the identifiers in SVG.xsd.go are too
    long, why wouldn't the compile stage complain with "identifier too long"
    (rather than link stage with "name too long"), as it does when I just
    experimentally manually add a simple way-too-long identifier?

    --

    --
  • Philipp Schumann at Nov 16, 2012 at 6:28 pm
    By the way I have a couple of such small test progs like the SVG one
    mentioned:

    https://github.com/metaleap/go-xsd/tree/master/xsd-makepkg/tests

    These two build fine: atom and rss

    The others don't: svg, kml, collada

    So they all have similar path lengths, but the "W" structs for atom and rss
    are fairly small, whereas the other 3 "W" structs are incredibly big.
    Anyone know, what's the maximum number for struct fields?.... ;)

    On Saturday, November 17, 2012 2:25:55 AM UTC+8, Philipp Schumann wrote:

    Thanks, but that's most likely not the issue. I checked this... With my
    $TMP set to c:\t\ none of the paths involved exceed 200. Also tried to
    go-build the above main.go from a real short path (c:\gd\src\github.com\metaleap\t\
    just to try it). Also, this issue is only new since the introduction of
    said new "W" struct (used to be a longer name, "W" is part of my
    experimentation in reducing overall "nameage"....)


    On Saturday, November 17, 2012 2:20:35 AM UTC+8, Rémy Oudompheng wrote:

    what is the length of the full path to your source file?
    I think it cannot exceed 256 characters.

    Rémy.

    2012/11/16, Philipp Schumann <philipp....@gmail.com>:
    So what's the maximum length for a Go identifier?

    Actually this problem is quite odd. Trying to "go build" this program:

    https://github.com/metaleap/go-xsd/blob/master/xsd-makepkg/tests/xsd-test-svg/main.go
    gives the following output:

    # github.com/metaleap/t
    c:\gd\pkg\windows_amd64/
    github.com/metaleap/go-xsd-pkg/www.w3.org/TR/2002/WD-SVG11-20020108/SVG.xsd_go.a(_go_.6):
    name too long

    So I created a small independent test program with a really really long
    identifier name and its error message is different: "identifier too long".
    (BTW would be *extreeemely* useful if this one and the above one both had
    the format "identifier %s too long (has length %i, max is %i)" or some
    such... most error messages throughout Go are great like that,
    unfortunately these two aren't).

    Also I should note that "go build" for the package being imported
    (SVG.xsd_go) raises no issues about too-long identifiers (or names), and
    creates the .a package just fine. I can also import that one into other
    non-main packages and have *their* .a packages built just fine. Only when
    finally attempting to use any such package in a main package for an
    executable does this problem occur, I guess it's only then that "real
    linking" of various .a's occurs.

    As for said SVG package, this problem only started occurring when go-xsd
    added support to add a Walk() method to any generated type, plus a
    potentially quite "big" single struct var called W, starting
    (currently) at
    line 9294:

    https://github.com/metaleap/go-xsd-pkg/blob/master/www.w3.org/TR/2002/WD-SVG11-20020108/SVG.xsd_go/SVG.xsd.go#L9294
    In auto-generated code you end up with some pretty weird combined
    identifier names, so would be reaaally useful to know what kinds of limits
    exist. The Go Spec says zilch about this, sadly. At least in the
    "identifiers" section I was consulting. WIP I guess? I expect to find such
    things in a spec document... ;)

    I was also using the search function at golang.org looking for "name too
    long". Ignoring the matches for gob/decode, dnsclient_unix and zerrors, the
    other matches where in the linked-related packages (5l/6l/8l). That message
    is being produced when a call to some "Blinelen" function returns a value >
    0, but I couldn't find said function's definition with golang.orgsearch,
    so suppose it's a C func somewhere way deep in the compiler
    code-base...
    So what are my options? If any of the identifiers in SVG.xsd.go are too
    long, why wouldn't the compile stage complain with "identifier too long"
    (rather than link stage with "name too long"), as it does when I just
    experimentally manually add a simple way-too-long identifier?

    --

    --
  • Rémy Oudompheng at Nov 16, 2012 at 7:16 pm

    On 2012/11/16 Philipp Schumann wrote:
    By the way I have a couple of such small test progs like the SVG one
    mentioned:

    https://github.com/metaleap/go-xsd/tree/master/xsd-makepkg/tests

    These two build fine: atom and rss

    The others don't: svg, kml, collada

    So they all have similar path lengths, but the "W" structs for atom and rss
    are fairly small, whereas the other 3 "W" structs are incredibly big. Anyone
    know, what's the maximum number for struct fields?.... ;)

    On Saturday, November 17, 2012 2:25:55 AM UTC+8, Philipp Schumann wrote:

    Thanks, but that's most likely not the issue. I checked this... With my
    $TMP set to c:\t\ none of the paths involved exceed 200. Also tried to
    go-build the above main.go from a real short path
    (c:\gd\src\github.com\metaleap\t\ just to try it). Also, this issue is only
    new since the introduction of said new "W" struct (used to be a longer name,
    "W" is part of my experimentation in reducing overall "nameage"....)
    Can you try giving a name to the giant struct type ? The linker can
    probably be fixed to avoid that issue. The problem is that the name of
    the type is very long (the type name is "struct { .... }").

    Rémy.

    --
  • Philipp Schumann at Nov 16, 2012 at 7:21 pm
    Wow, now why on earth didn't I think about this... *facepalm* that's most
    likely the issue! Will try right away and report back.


    On Saturday, November 17, 2012 3:16:44 AM UTC+8, Rémy Oudompheng wrote:

    On 2012/11/16 Philipp Schumann <philipp....@gmail.com <javascript:>>
    wrote:
    By the way I have a couple of such small test progs like the SVG one
    mentioned:

    https://github.com/metaleap/go-xsd/tree/master/xsd-makepkg/tests

    These two build fine: atom and rss

    The others don't: svg, kml, collada

    So they all have similar path lengths, but the "W" structs for atom and rss
    are fairly small, whereas the other 3 "W" structs are incredibly big. Anyone
    know, what's the maximum number for struct fields?.... ;)

    On Saturday, November 17, 2012 2:25:55 AM UTC+8, Philipp Schumann wrote:

    Thanks, but that's most likely not the issue. I checked this... With my
    $TMP set to c:\t\ none of the paths involved exceed 200. Also tried to
    go-build the above main.go from a real short path
    (c:\gd\src\github.com\metaleap\t\ just to try it). Also, this issue is
    only
    new since the introduction of said new "W" struct (used to be a longer
    name,
    "W" is part of my experimentation in reducing overall "nameage"....)
    Can you try giving a name to the giant struct type ? The linker can
    probably be fixed to avoid that issue. The problem is that the name of
    the type is very long (the type name is "struct { .... }").

    Rémy.
    --
  • Philipp Schumann at Nov 16, 2012 at 7:33 pm
    OK, that was it indeed, issue resolved! Thanks again.

    On Saturday, November 17, 2012 3:21:24 AM UTC+8, Philipp Schumann wrote:

    Wow, now why on earth didn't I think about this... *facepalm* that's most
    likely the issue! Will try right away and report back.


    On Saturday, November 17, 2012 3:16:44 AM UTC+8, Rémy Oudompheng wrote:
    On 2012/11/16 Philipp Schumann wrote:
    By the way I have a couple of such small test progs like the SVG one
    mentioned:

    https://github.com/metaleap/go-xsd/tree/master/xsd-makepkg/tests

    These two build fine: atom and rss

    The others don't: svg, kml, collada

    So they all have similar path lengths, but the "W" structs for atom and rss
    are fairly small, whereas the other 3 "W" structs are incredibly big. Anyone
    know, what's the maximum number for struct fields?.... ;)


    On Saturday, November 17, 2012 2:25:55 AM UTC+8, Philipp Schumann
    wrote:
    Thanks, but that's most likely not the issue. I checked this... With
    my
    $TMP set to c:\t\ none of the paths involved exceed 200. Also tried to
    go-build the above main.go from a real short path
    (c:\gd\src\github.com\metaleap\t\ just to try it). Also, this issue
    is only
    new since the introduction of said new "W" struct (used to be a longer
    name,
    "W" is part of my experimentation in reducing overall "nameage"....)
    Can you try giving a name to the giant struct type ? The linker can
    probably be fixed to avoid that issue. The problem is that the name of
    the type is very long (the type name is "struct { .... }").

    Rémy.
    --
  • Russ Cox at Nov 25, 2012 at 8:00 pm
    Thanks for reporting this. Even though you found a workaround we
    should probably fix the original problem, namely that your large
    unnamed struct created a symbol with name length > 8192 bytes, which
    the linker then could not handle. I created golang.org/issue/4438.

    Russ

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 16, '12 at 6:00p
activeNov 25, '12 at 8:00p
posts8
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase