Search Options

Results per page
Sort
Preferred Languages
Advance

Results 11 - 14 of 14 for misbehaving (0.12 sec)

  1. src/runtime/panic.go

    // its own defers (d4 and d3), so drangefunc need not be at the
    // top of the list when deferprocat is used. This is why we pass
    // the atomic head explicitly.
    //
    // To keep misbehaving programs from crashing the runtime,
    // deferprocat pushes new defers onto the .head list atomically.
    // The fact that it is a separate list from the main goroutine
    // defer list means that the main goroutine's defers can still
    Registered: Wed Jun 12 16:32:35 UTC 2024
    - Last Modified: Wed May 29 17:58:53 UTC 2024
    - 43.8K bytes
    - Viewed (0)
  2. src/reflect/type.go

    	f.Offset = p.Offset
    
    	// NOTE(rsc): This is the only allocation in the interface
    	// presented by a reflect.Type. It would be nice to avoid,
    	// at least in the common cases, but we need to make sure
    	// that misbehaving clients of reflect cannot affect other
    	// uses of reflect. One possibility is CL 5371098, but we
    	// postponed that ugliness until there is a demonstrated
    	// need for the performance. This is issue 2320.
    Registered: Wed Jun 12 16:32:35 UTC 2024
    - Last Modified: Wed May 29 17:58:53 UTC 2024
    - 85.5K bytes
    - Viewed (0)
  3. src/cmd/go/testdata/script/mod_sumdb.txt

    rm go.sum
    
    # switching to truthful sumdb detects timeline inconsistency
    cp go.mod.orig go.mod
    env GOSUMDB=$sumdb
    ! go get rsc.io/fortune
    stderr 'SECURITY ERROR\ngo.sum database server misbehavior detected!'
    stderr 'proof of misbehavior:'
    
    # removing the cached wrong tree head and cached tiles clears the bad data
    rm $GOPATH/pkg/sumdb/$dbname/latest
    go clean -modcache
    go get rsc.io/fortune
    
    -- go.mod.orig --
    module m
    
    Registered: Wed Jun 12 16:32:35 UTC 2024
    - Last Modified: Tue Sep 28 17:19:14 UTC 2021
    - 1.2K bytes
    - Viewed (0)
  4. src/net/http/server.go

    	//
    	// Unfortunately, we have no straightforward way to be “reasonably certain”
    	// that we have received the client's ACK, and at any rate we don't want to
    	// allow a misbehaving client to soak up server connections indefinitely by
    	// withholding an ACK, nor do we want to go through the complexity or overhead
    	// of using low-level APIs to figure out when a TCP round-trip has completed.
    	//
    Registered: Wed Jun 12 16:32:35 UTC 2024
    - Last Modified: Fri Jun 07 17:57:01 UTC 2024
    - 123.4K bytes
    - Viewed (0)
Back to top