[go-nuts] Re: strange failure of golang.org/x/crypto/argon2.IDKey
Memory parameter to IDKey is in kilobytes. Your code is specifying 200 kilobytes. Ren On Friday, 3 January 2020 07:14:22 UTC, andre@gmail.com wrote: > > > I attached a minimal test program to reproduce an issue with > golang.org/x/crypto/argon2. > > It calls IDKey twice with the same parameters. The first call executes, > but during the second call the program crashes. > > Strange thing: The program does not always crash. If it crashes then I can > call it multiple times in a row and it always crashes. > But then maybe if I try a few hours later it does not crash. And if I try > it then again and again it will always work normally. > > Another curious thing is that when it crashes it usually (but not always) > kills the whole terminal emulator (gnome-terminal) with it. > I am running this on Fedora 31 64-bit (Intel Core i5-5200U). > strace shows at the end: > > +++ killed by SIGKILL +++ > > The crash happens somewhere in the argon2.processBlocks function. > > Any ideas ? Should I open an issue on https://github.com/golang/go ? > > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/abdd2b5e-d5cc-4b00-b86e-b842224deccd%40googlegroups.com.
Re: [go-nuts] Re: [64]byte()[:]
Or look at the source of bytes.Equal() first. :) https://golang.org/src/bytes/bytes.go?s=505:533#L8 Ren On Sunday, 17 November 2019 17:54:47 UTC, Kevin Malachowski wrote: > > Good call, I don't know why I didn't think of the stack allocation. > > The conversion to string first is also quite interesting. If bytes.Equal > is inlined in practice, profiling is probably the only way to tell which is > faster. > > > > > On Sun, Nov 17, 2019, 2:48 AM Axel Wagner > wrote: > >> On Sun, Nov 17, 2019 at 1:00 AM Kevin Malachowski > > wrote: >> >>> "make"ing a byre slice every time you call Equal is not likely as >>> efficient; surely it will put pressure on the garbage collector, assuming >>> it's not just called a few times. >>> >> >> AFAICT the compiler correctly deduces that the slice doesn't escape and >> puts it on the stack. So, no, it doesn't :) >> >> >>> >>> Writing something in less lines is not strictly better. I'd probably >>> just make package level variable and reuse it among multiple calls to that >>> function. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golan...@googlegroups.com . >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/9cfa25b8-4a18-47ca-9f37-5d5ae5b71849%40googlegroups.com >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3bd2d434-4c45-42a9-b138-42d133c9168d%40googlegroups.com.
[go-nuts] Re: [64]byte()[:]
Trick is knowing the compiler can optimize string(b) away.
const z8 = "\x00\x00\x00\x00\x00\x00\x00\x00"
const z64 = z8 + z8 + z8 + z8 + z8 + z8 + z8 + z8
if string(b64) == z64 {
}
Ren
On Saturday, 16 November 2019 03:32:32 UTC, Gert wrote:
>
> Is it possible to write this without creating a separate var b64 first?
> Basically just write it in one line?
>
> var b64 [64]byte // 64 zero bytes
> if bytes.Equal(b64[:], x) {}
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/c0479f85-6625-46b2-a748-423866a4028b%40googlegroups.com.
[go-nuts] Etiquette on reusing test code
Wondering what the etiquette is for using test code from other packages, both from golang stdlib and /x/ ? Obviously the BSD like license stays, but is there an expected way of documenting the tests are modified versions written by other parties? Ren -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Golang, SQL and ORM avoidance techniques
On Tuesday, 6 June 2017 13:46:58 UTC+1, venturestre...@gmail.com wrote: > > On a complete tangent, are you calling a stored procedure there? I thought > the database/sql package didn't support MySQL stored procedures yet? > Haven't encountered a serious issue, as yet. Obviously output parameters, and probably return values aren't supported. Selects appear to work fine. With simple single row insert statements sql.Result's LastInsertId() only returns 0, though sql.Result's RowsAffected() does return 1. Ren -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Golang, SQL and ORM avoidance techniques
Wrote something similar recently.
One difference is that I moved the rows.Scan call into the passed in
function.
type Scannable interface {
Scan(...interface{}) error
}
func scanIntoUser(u *store.User) func(s Scannable) error {
return func(s Scannable) error {
return s.Scan(, , , )
}
}
func (s *userStore) UserByName(name string) (*store.User, error) {
u := {}
err := ExpectOneRow(s.db, scanIntoUser(u), "CALL spUserByName(?)", name)
if err != nil {
return nil, err
}
return u, nil
}
Idea being gives an opportunity to do some mapping by scanning into local
variables and then assign them into the object, for instance dealing with
NULLs. Scan into a sql.Null* variable, and modify whatever struct as see
appropriate.
Ren
On Friday, 2 June 2017 13:55:12 UTC+1, brylant wrote:
>
>
> I've been trying hard (well.. as much as I can considering my lack of
> in-depth go knowledge or - to be perfectly honest - lack of in-depth
> knowledge of anything) to find suitable go+sql technique that would not
> require a lot of code repetition, not use reflection and not use ORMs of
> any sort... Could somebody please tell me if there's anything particularly
> wrong with the following:
>
>
> type ScannerFunc func() []interface{}
>
> func (db *DB) ScanSome(stmt string, sf ScannerFunc, params ...interface{})
> error {
> rows, err := db.Query(stmt, params...)
> if err != nil {
> return err
> }
> defer rows.Close()
> for rows.Next() {
> err = rows.Scan(sf()...)
> if err != nil {
> return err
> }
> }
> if err = rows.Err(); err != nil {
> return err
> }
> return nil
> }
>
> Having the above I could then implement the following for each of my
> 'models' (User being an example below). This could easily be 'go
> generate'-d for each model
>
>
> type User struct {
> UserID int64
> Namestring
> Roleint
> // (...)
> }
>
> func ScanUsersFunc(users *[]*User) ScannerFunc {
> return ScannerFunc(func() []interface{}) {
> u := User{}
> *users = append(*users, )
> var r []interface{} = []interface{}{, , ,
> (more
> properties)}
> return r
> }
> }
>
>
> and finally use it like this:
>
>
> const (
> sqlUsersByRole = "SELECT user_id,name,role, (more if needed) FROM
> user WHERE role=?"
> sqlAllUsers= "SELECT user_id,name,role FROM user"
> )
>
> func (db *DB) UsersByRole(role int) ([]*User, error) {
> users := make([]*User, 0)
> err := db.ScanSome(sqlUsersByRole, ScanUsersFunc(), role)
> if err != nil {
> return nil, err
> }
> return users, nil
> }
>
> func (db *DB) AllUsers() ([]*User, error) {
> users := make([]*User, 0)
> err := db.ScanSome(sqlAllUsers, ScanUsersFunc())
> if err != nil {
> return nil, err
> }
> return users, nil
> }
>
>
> Alternatively (to avoid scanning/returning all results) a callback could
> be provided to ScanSome and called after each scan.
>
> Obviously I could also implement ScanOne for situations where I only
> expect one row of results...
>
>
> So - any obvious issues with the above 'technique'...?
>
>
> Thanks,
>
> adam
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
