fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
Meths has quit [Read error: Connection reset by peer]
fche2 has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
fche has joined #systemtap
orivej has quit [Ping timeout: 268 seconds]
fche has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
mjw has joined #systemtap
orivej has joined #systemtap
fche has joined #systemtap
drsmith has left #systemtap [#systemtap]
drsmith has joined #systemtap
tromey has joined #systemtap
orivej has quit [Ping timeout: 268 seconds]
brolley has joined #systemtap
agentzh has joined #systemtap
<agentzh>
fche: it seems that stap strings are null-terminated. is it possible to make it support arbitrary binary strings by storing the size explicitly?
<agentzh>
fche: it would be really sad if we cannot have \0 inside the string values.
<fche>
that would be a big change. In some other stappy context, we have functions that \x-escape binary values e.g.
<agentzh>
yeah, i know it would be big though i believe necessary :) stap strings are builtin types anyway.
<agentzh>
will you accept such patch?
<fche>
tough call ... again all the tapset functions would have to be changed, embedded-c api ditto
mjw has quit [Remote host closed the connection]
<agentzh>
fche: we could still preserve a trailing \0 after the `len` bytes so existing embedded c code won't break if they still look for \0.
<agentzh>
*existing out-of-tree
<fche>
length byte/short to sit at [-1] ?
<agentzh>
it has to sit at the beginning.
<agentzh>
otherwise we cannot know which \0 is the real terminator.
<agentzh>
and yes, [-1] where 1 means size_t.
<fche>
you're aware of -DMAXSTRINGLEN?
<agentzh>
yes
<agentzh>
been bitten by it for many times :)
<fche>
ok so size_t is almost certainly an overkill (8 bytes?)
<agentzh>
ah, you are talking about optimization, oh, yes, short would be better.
<agentzh>
even int is overkill.
<agentzh>
byte is too small.
<agentzh>
unsigned short looks perfect.
<agentzh>
65535
<fche>
I can see value in such a change, but also concern about compatibility & robustness. so tough to judge.
<agentzh>
i think it's better to try out the real patch. then it would be easier to judge.
<agentzh>
we don't mind working out such a patch.
<agentzh>
we do need it ourselves very badly anyway.
<agentzh>
but i do agree it'll be a big change.
<fche>
yeah, so as long as this is just for sake of argument, i.e., no commitment to accept, it'd be interesting to see
<agentzh>
not at all.
<agentzh>
as long as you would be interested.
* agentzh
is not that demanding ;)
<fche>
ok
<agentzh>
btw, i've got the array-func-arg feature passing all of my existing test cases. it is a bigger change than i expected since the translator does not really keep track of the arity.
<agentzh>
in most of the cases it simply sets the arity to zero and/or assumes the arity to be zero. so i have to change all those places.
<agentzh>
mostly in elaborate.cxx and translator.cxx.
<agentzh>
i'll add more trickier test cases today to exercise the type inferencer and translator even harder.
<fche>
and would like to see a design outline for that one too in terms of translation output, safety (locking, prevention of modification-in-loop e.g.)
<agentzh>
yeah, the foreach loop would deserve special care, i haven't got to that yet.
<agentzh>
if there are any other places deversing special care, it'll be great if you can give me some hints.
<fche>
not sure - cannot keep all the special cases in head :)
<agentzh>
gotcha
<fche>
that's why changing such core stuff is tricky
<agentzh>
*nod*
<agentzh>
it's a great way to get familiar with the stap internals.
<agentzh>
for me :)
<agentzh>
try making stap break and then fix it.
* fche
is impressed by the bravery
mjw has joined #systemtap
tromey has quit [Quit: ERC (IRC client for Emacs 26.1.50)]