1. 16 Aug, 2017 5 commits
    • Alex Brainman's avatar
      cmd/link: use peSection everywhere · babc5b1d
      Alex Brainman authored
      Change-Id: I4d4e8452b9b9e628f3ea8b2b727ad63ec2a1dd31
      Reviewed-on: https://go-review.googlesource.com/55259Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      babc5b1d
    • Alex Brainman's avatar
      cmd/link: add peSection · 2c2b1723
      Alex Brainman authored
      Change-Id: Id3aeeaeaacf5f079fb2ddad579f2f209b7fc0e06
      Reviewed-on: https://go-review.googlesource.com/55258Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      2c2b1723
    • Alex Brainman's avatar
      cmd/link: introduce and use peFile and peStringTable · 20832e6d
      Alex Brainman authored
      Change-Id: Icd13b32d35cde474c9292227471f916a64af88eb
      Reviewed-on: https://go-review.googlesource.com/55257Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      20832e6d
    • Joe Tsai's avatar
      archive/tar: make Writer error handling consistent · b9a79f32
      Joe Tsai authored
      The Writer logic was not consistent about when an IO error would
      persist across multiple calls on Writer's methods.
      
      Thus, to make the error handling more consistent we always check
      the persistent state of the error prior to every exported method
      call, and return an error if set. Otherwise, it is the responsibility
      of every exported method to persist any fatal errors that may occur.
      
      As a simplification, we can remove the close field since that
      information can be represented by simply storing ErrWriteAfterClose
      in the err field.
      
      Change-Id: I8746ca36b3739803e0373253450db69b3bd12f38
      Reviewed-on: https://go-review.googlesource.com/55590
      Run-TryBot: Joe Tsai <joetsai@digital-static.net>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      b9a79f32
    • Joe Tsai's avatar
      archive/tar: add support for long binary strings in GNU format · 5c20ffbb
      Joe Tsai authored
      The GNU tar format defines the following type flags:
      	TypeGNULongName = 'L' // Next file has a long name
      	TypeGNULongLink = 'K' // Next file symlinks to a file w/ a long name
      
      Anytime a string exceeds the field dedicated to store it, the GNU format
      permits a fake "file" to be prepended where that file entry has a Typeflag
      of 'L' or 'K' and the contents of the file is a NUL-terminated string.
      
      Contrary to previous TODO comments,
      the GNU format supports arbitrary strings (without NUL) rather UTF-8 strings.
      The manual says the following:
      <<<
      The name, linkname, magic, uname, and gname are
      null-terminated character strings
      > <<<
      > All characters in header blocks are represented
      > by using 8-bit characters in the local variant of ASCII.
      
      From this description, we gather the following:
      * We must forbid NULs in any GNU strings
      * Any 8-bit value (other than NUL) is permitted
      
      Since the modern world has moved to UTF-8, it is really difficult to
      determine what a "local variant of ASCII" means. For this reason,
      we treat strings as just an arbitrary binary string (without NUL)
      and leave it to the user to determine the encoding of this string.
      (Practically, it seems that UTF-8 is the typical encoding used
      in GNU archives seen in the wild).
      
      The implementation of GNU tar seems to confirm this interpretation
      of the manual where it permits any arbitrary binary string to exist
      within these fields so long as they do not contain the NUL character.
      
       $ touch `echo -e "not\x80\x81\x82\x83utf8"`
       $ gnutar -H gnu --tar -cvf gnu-not-utf8.tar $(echo -e "not\x80\x81\x82\x83utf8")
      
      The fact that we permit arbitrary binary in GNU strings goes
      hand-in-hand with the fact that GNU also permits a "base-256" encoding
      of numeric fields, which is effectively two-complement binary.
      
      Change-Id: Ic037ec6bed306d07d1312f0058594bd9b64d9880
      Reviewed-on: https://go-review.googlesource.com/55573Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      5c20ffbb
  2. 15 Aug, 2017 35 commits