[spam] software responsibility

Karl gmkarl at gmail.com
Thu Nov 4 11:59:44 PDT 2021


the guy on github isn't familiar with github or something, and it's quite
confusing.

1429

pretty hard to continue.  maybe with some time I can understand how to
respond to the guy.

i'll move forward and testing the stable code with the test app.  then i'll
try adding my change.  if I ever finish, i'll plan to tell the guy, "hey
what you said was kinda confusing to me, so I just did it".

1430

tmux reloading panes again

1431

1432

gotta bring raid array up.  looks like my usb hub is unpowered.

1434

gotta reboot android

1435

k test time

1436

test passed.  which gives me working code and shows me how to rebuild this
project at the same time.  i'll try removing the extra set option call, and
look at appropriate control flow logic hopefully.

okay.  I remember now.  wait.  no.  I don't.

1438

1439

the first confusing thing is the check in libusb_init .  it passes the
default options to the backend again only if no ctx pointer was bpassed,
and there is no default ctx pointer.

ok, so it only passes them, if it is making a new default ctx ptr.

meanwhile, the old android flag had set a static flag and ignored the ctx
pointer.

my new code associates the flag with the ctx instead.  currently unstable.

the current code still ignores the ctx pointer.

1442

so, the current tip code assumes that options are associated with ctxs.  if
no ctx is passed, it stores them as defaults: but it only passes them on if
creating a default ctx.

so there's maybe a tiny leakish, for this use, in hjelmn's code where
defaults set with no context, are unused if the user sets a context

and something else with harbulot's code

with the old android code, defaults were set for the context before it was
created.

this could mean passing them on, even if the context is not the default.

alternatively, the intent of hjelmn's code could have been to set options
on context storage before it is initialised.  I guess that seems a little
unsafeish to me, unsure, nobody's mentioned trying it I guess.

1445

so what's the plan

seems most direct to pass defaults in whether a new default context is made
or not

alternatively we could stay near the current code, and set defaults when
the option is passed, and read straight from the defaults.

I thought of two approaches to the option situation I might as well add as
comments to a different issue
- options could be passed on an uninitialised context
- the backend could be refactored to initialise on use, so that early
options can be passed after it is constructed

regarding the first option, it seems that the user only has control of
context pointer storage, so that's not too workable unless allocation is
separated from initialisation

k I submitted those ideas to their issue for such ideas
1454

ok um

copypaste: seems most direct to pass defaults in whether a new default
context is made or not

alternatively we could stay near the current code, and set defaults when
the option is passed, and read straight from the defaults.

it seems more compatible a little to keep the approach I currently have of
setting the defaults in the option handler, and reading from them to manage
the options.

this is similar to the solution bits made by the visiting contributer.

1455

current issues include:
- deadlock, roughly resolved
- segfault?  let's see what he addressed

right.  my option handler checks wrt null.

this issue should go away if duplicate passing goes away.

but basically, it's ok to reset it if the value is unchanged ... I guess
... maybe ...?  i'll try looking at it!

I think I might be able to complete this!

1459
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 6037 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20211104/caf51e14/attachment.txt>


More information about the cypherpunks mailing list