1. 16 Aug, 2017 8 commits
    • Brian Kessler's avatar
      math: eliminate overflow in Pow(x,y) for large y · 12465661
      Brian Kessler authored
      The current implementation uses a shift and add
      loop to compute the product of x's exponent xe and
      the integer part of y (yi) for yi up to 1<<63.
      Since xe is an 11-bit exponent, this product can be
      up to 74-bits and overflow both 32 and 64-bit int.
      
      This change checks whether the accumulated exponent
      will fit in the 11-bit float exponent of the output
      and breaks out of the loop early if overflow is detected.
      
      The current handling of yi >= 1<<63 uses Exp(y * Log(x))
      which incorrectly returns Nan for x<0.  In addition,
      for y this large, Exp(y * Log(x)) can be enumerated
      to only overflow except when x == -1 since the
      boundary cases computed exactly:
      
      Pow(NextAfter(1.0, Inf(1)), 1<<63)  == 2.72332... * 10^889
      Pow(NextAfter(1.0, Inf(-1)), 1<<63) == 1.91624... * 10^-445
      
      exceed the range of float64. So, the call can be
      replaced with a simple case statement analgous to
      y == Inf that correctly handles x < 0 as well.
      
      Fixes #7394
      
      Change-Id: I6f50dc951f3693697f9669697599860604323102
      Reviewed-on: https://go-review.googlesource.com/48290Reviewed-by: default avatarRobert Griesemer <gri@golang.org>
      12465661
    • Alex Brainman's avatar
      cmd/link: delete shNames · a9257b6b
      Alex Brainman authored
      Change-Id: Ie5d12ba4105fec17551637d066d0dffd508f74a4
      Reviewed-on: https://go-review.googlesource.com/55261
      Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      a9257b6b
    • Alex Brainman's avatar
      cmd/link: delete addpesection · 6aa38668
      Alex Brainman authored
      Change-Id: Iee9db172d28d4d372fa617907078a494e764bf12
      Reviewed-on: https://go-review.googlesource.com/55260Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      6aa38668
    • 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: default 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: default 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: default 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: default 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: default 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 32 commits