[07:07:01] --> WingedHussar has joined #gemrb
[07:09:28] --> lynxlynxlynx has joined #gemrb
[07:09:28] --- ChanServ gives channel operator status to lynxlynxlynx
[07:48:48] <edheldil> DrMcCoy: vinyl records are still in vogue :-P
[07:48:57] <edheldil> or rather, again
[07:52:13] <DrMcCoy> I know. And there's bands, especially doom/stoner ones, that release some stuff on vinyl only. Annoying
[07:53:16] <DrMcCoy> Ditto with audio cassettes
[07:57:37] <-- WingedHussar has left IRC (Quit: WingedHussar)
[08:29:19] --> WingedHussar has joined #gemrb
[10:18:23] --- ermo^ is now known as ermo
[10:53:16] <-- lynxlynxlynx has left IRC (Read error: Operation timed out)
[11:09:55] --> lynxlynxlynx has joined #gemrb
[11:09:56] --- ChanServ gives channel operator status to lynxlynxlynx
[11:35:45] --- ermo is now known as ermo^
[12:16:15] <-- gembot has left IRC (Ping timeout: 245 seconds)
[12:17:47] --> gembot has joined #gemrb
[12:21:26] <edheldil> "Project is already registered on Coverity Scan" <-- so it's possibly just a lag before they scan it
[12:27:22] <fuzzie> lynxlynxlynx: did you use your sf mail address for that?
[12:28:18] <lynxlynxlynx> meh, quite likely
[12:28:43] <fuzzie> postfix here gave up on delivering to that due to only getting 451s
[12:30:03] <fuzzie> so might be worth bothering email@example.com
[12:33:33] <lynxlynxlynx> looking if there are any login forms anywhere
[12:34:57] <fuzzie> should be on front page
[12:34:59] <lynxlynxlynx> nothing saved in my browser
[12:47:23] <lynxlynxlynx> i'll write 'em
[14:55:58] --- ermo^ is now known as ermo
[15:09:42] <-- WingedHussar has left IRC (Quit: WingedHussar)
[15:40:58] <fuzzie> probably it'll be a fairly unapproachable mess
[15:41:04] <fuzzie> but it can't hurt
[16:45:06] --> Maighstir has joined #gemrb
[17:53:07] --> Yoshimo has joined #gemrb
[18:10:52] <-- Yoshimo has left IRC (Quit: Yoshimo)
[18:18:09] --> botton has joined #gemrb
[18:18:09] <-- botton has left #gemrb
[18:38:18] <lynxlynxlynx> coverity replied asap
[18:38:24] <lynxlynxlynx> it was the email
[18:38:35] <lynxlynxlynx> everything is fine now
[18:39:38] <lynxlynxlynx> uff, time flies, i submitted in on feb the fifth
[18:50:23] --> Yoshimo has joined #gemrb
[18:58:41] <lynxlynxlynx> ok, first dump submitted
[19:07:45] <lynxlynxlynx> interesting, there was a gemrb-developers mailing list for a while
[19:16:14] <lynxlynxlynx> no familiar folk there except balrog
[19:16:58] <lynxlynxlynx> Just wanted to let you know that I just got word that my Baldur's Gate II
[19:16:58] <lynxlynxlynx> package has been shipped today and is on its way. If anyone needs any files
[19:16:58] <lynxlynxlynx> to test thier goodies against, just drop me a note and I'll get you whatever
[19:16:58] <lynxlynxlynx> you need. I expect it'll be here by next friday, possibly sooner. <-- :)
[19:20:30] <fuzzie> lynxlynxlynx: pm me the coverity password, if you could?
[19:20:48] <lynxlynxlynx> sure
[19:21:20] <lynxlynxlynx> oh, i got the results back, let's see
[19:21:30] <fuzzie> i mean, the project one
[19:22:13] <fuzzie> thanks
[19:22:32] <lynxlynxlynx> that was it
[19:22:47] <fuzzie> i got bothered into signing up for the scummvm one today too
[19:22:53] <lynxlynxlynx> they have a tough captcha though, haven't managed to add users yet
[19:23:08] <lynxlynxlynx> do you know if you need to use spaces too?
[19:23:14] <fuzzie> you don't
[19:24:35] <fuzzie> but i'm hardly expert :p
[19:26:40] <fuzzie> it seems to take quite a long time for their servers to actually update with anything though.
[19:26:46] <fuzzie> such as new users.
[19:29:26] <lynxlynxlynx> we have 264 artefacts
[19:29:44] <fuzzie> anything useful looking?
[19:29:45] <wjp> lynxlynxlynx: can you give me the password too?
[19:30:15] <lynxlynxlynx> we can make it report to gemrb-commits
[19:30:55] <fuzzie> don't they have to be kept non-public?
[19:33:16] <fuzzie> hm, no rules in sight
[19:33:29] --> edheldil_ has joined #gemrb
[19:34:25] <lynxlynxlynx> right, i don't remember seeing any report from others
[19:35:11] <lynxlynxlynx> nice analysis
[19:35:33] <fuzzie> "You agree that by accepting access to the Service you commit not to distribute or share details of the service or its analysis with any entity without prior authorization from Coverity."
[19:36:43] <fuzzie> the uninitialized members ones are just annoying
[19:38:23] <fuzzie> 1004388 is a bit silly, and i assume 4387/4386/4385 are false positives
[19:38:39] <lynxlynxlynx> you mean the python ones?
[19:39:01] <fuzzie> 4389/4390/4391 are a very sensible point
[19:39:31] <fuzzie> i mean all of the uninitialized members ones
[19:39:53] <fuzzie> some of them might be valid but it's such a mess..
[19:40:12] <lynxlynxlynx> the font one is a nice catch too (4485)
[19:40:21] <lynxlynxlynx> err 4458
[19:40:35] <fuzzie> a lot of them are good
[19:40:50] <fuzzie> 4473 for example :)
[19:41:02] <fuzzie> and yes 4458 is very good
[19:42:24] <fuzzie> 4433 is v.silly considering all the effort it goes to to set the 'table' var :)
[19:42:52] <lynxlynxlynx> just classify them as you go, so we don't nplicate the review effort
[19:44:36] <fuzzie> oh, i see, our strlcpy is weird
[19:44:41] <fuzzie> erm, our strnlen
[19:46:35] <wjp> 4386 could have been done with an ever longer chain of missing breaks without the goto :-)
[19:46:40] <wjp> s/ever/even/
[19:47:40] <fuzzie> i'm not sure how to mark 4388
[19:47:47] <fuzzie> thereotically key should never be null, but..
[19:47:55] <fuzzie> why is strnlen not just asserting?
[20:04:53] <fuzzie> gosh, I should really point projects at this when I find their code full of security holes
[20:16:26] <lynxlynxlynx> is it just me or is there no trivial way of getting just a list of items that need work (triaged as a bug for example)?
[20:18:27] <wjp> you can create new filters
[20:18:58] <wjp> hit the '+' icon next to the 'Issues' heading in the left menubar
[20:19:22] <wjp> and then the down arrow next to the newly created item
[20:20:52] <lynxlynxlynx> thanks
[20:20:57] --> brada has joined #gemrb
[20:28:01] <lynxlynxlynx> heyo
[20:28:18] <lynxlynxlynx> good an interesting font problem for you
[20:28:28] <lynxlynxlynx> i can't run valgrind on plain gemrb anymore
[20:28:58] <lynxlynxlynx> it's replacement libraries choke on the sanity assert in GemRB::Font::GetDoubleByteString
[20:29:34] <fuzzie> it's a bad check :P
[20:29:34] <wjp> hm, let me try
[20:29:36] <lynxlynxlynx> just commenting it out shows no other issues and the run was practically clear too
[20:29:43] <fuzzie> i commented on this already
[20:30:02] <fuzzie> the realloc should be removed too
[20:30:07] <fuzzie> did you comment that out?
[20:30:11] <lynxlynxlynx> no
[20:30:35] <fuzzie> oh, i guess it's harmless
[20:30:41] <fuzzie> so never mind
[20:30:43] <fuzzie> it is a bad check though
[20:30:48] <wjp> oh, that's silly
[20:31:11] <lynxlynxlynx> should be a strcmp?
[20:31:24] <wjp> no
[20:31:33] <wjp> old string is gone after the realloc
[20:31:43] <wjp> just remove the assert
[20:32:15] <fuzzie> also the comment just before it, and the 'ieWord *test' line
[20:32:26] <lynxlynxlynx> yeah, it wouldn't compile without that
[20:37:25] <brada> fuzzie: if you remove the realloc it makes clang static anylizer go banannas
[20:39:43] <lynxlynxlynx> i'm not removing it
[20:40:34] <Seniorita> [commit] lynxlynxlynx: STOImporter::GetItem: make sure items have at least one charge https://github.com/gemrb/gemrb/commit/e98c2dd975c38a8b88d8218dba30b7711a9e20d7
[20:40:35] <Seniorita> [commit] lynxlynxlynx: Font::GetDoubleByteString: remove bogus assert https://github.com/gemrb/gemrb/commit/15ca13daed84b408aba2855e806fe59e9eb21fe0
[20:40:36] <brada> the easier is there only because i couldnt seem to find out if that is garuanteed. there should have been a long comment about it…
[20:40:36] <Seniorita> [commit] lynxlynxlynx: BAMFontManager::GetFont: don't use out-of-scope variables https://github.com/gemrb/gemrb/commit/23a35b0a03d8c33a965a4856dc3739d9fb24de5b
[20:40:44] <brada> maybe in the commit message only
[20:43:40] <fuzzie> brada: you should've #ifdeffed it for the static analyser, though
[20:43:55] <brada> but why?
[20:43:59] <brada> i mean why is it a problem?
[20:44:30] <brada> i did ask this before btw :p
[20:44:33] <fuzzie> because it can easily be a new allocation and a memory copy
[20:44:44] <brada> why?
[20:44:44] <fuzzie> yeah, i complained about it before, but it seems not when you were here
[20:44:47] <fuzzie> why not?
[20:44:48] <brada> its always a smaller value
[20:45:01] <fuzzie> realloc doesn't guarantee you get the same memory back
[20:45:05] <brada> all the research i did shows it will always be the same
[20:45:27] <brada> there was a rather length stack overflow about it
[20:45:38] <brada> SO question that is
[20:45:44] <fuzzie> do you know where?
[20:45:54] <brada> i may be able to conjure it up in google
[20:46:04] <brada> i realize now i should have linked it in with my comment
[20:46:07] <fuzzie> the first SO question I get is actually a note that it clearly isn't the case because valgrind doesn't do it
[20:46:20] <fuzzie> ( http://stackoverflow.com/questions/9575122/can-i-assume-that-calling-realloc-with-a-smaller-size-will-free-the-remainder )
[20:46:22] <Seniorita> c - Can I assume that calling realloc with a smaller size will free the remainder? - Stack Overflow
[20:46:55] <fuzzie> and the next is http://stackoverflow.com/questions/1736433/can-realloc-move-pointer-if-new-size-smaller with the first answer saying "Nope" and the second saying "no" and the third saying "no", etc.. :P
[20:46:57] <Seniorita> c - can realloc move pointer if new size smaller? - Stack Overflow
[20:47:48] <fuzzie> poking through the next few results I only find people agreeing
[20:48:05] <brada> maybe it wasnt on SO after all
[20:48:08] <brada> anyway
[20:48:13] <brada> ifdef it then
[20:49:07] <brada> the accepted answer to that it yes…
[20:49:28] <fuzzie> yes, i mean 'no, realloc is not guaranteed to give you the same pointer back'
[20:50:43] <brada> in practice it must work much of the time :p
[20:50:49] <brada> like i said remove it
[20:50:53] <brada> ifdef it for clang
[20:51:16] <fuzzie> well, I think in the 2x case it will almost always work
[20:51:25] <-- Yoshimo has left IRC (Quit: Yoshimo)
[20:51:46] <fuzzie> but obviously things like valgrind won't cooperate, since they *always* return a new value from realloc to detect these cases
[20:52:06] <fuzzie> but my argument is just about the assert being bad
[20:52:32] <brada> i didnt know about valgrind
[20:52:52] <brada> last time i checked valgrind still didnt work on os x 10.8
[20:53:17] <fuzzie> not too surprising
[20:53:28] <brada> why?
[20:53:37] <brada> im not sure what is giving them trouble
[20:53:59] <fuzzie> apple don't exactly help :P
[20:54:12] <fuzzie> but in general valgrind is useful enough that it's worth installing in a vm
[20:54:39] <lynxlynxlynx> ouch, that must be a serious memory hog
[20:55:05] <fuzzie> oh?
[20:55:05] <lynxlynxlynx> clang and gcc now have a similar plugin from google, but it's likely not as complete
[20:55:16] <fuzzie> well, it does a different thing
[20:55:18] <brada> valgrind now says "with limited support for 10.8"
[20:55:19] <fuzzie> it's worth using both
[20:55:24] <brada> so at least it runs i guess :p
[20:55:26] <fuzzie> in fact really I'd advocate using everything
[20:55:39] <brada> yeah
[20:56:00] <brada> there are still plenty of clang analyzer warnings :D
[20:56:05] <fuzzie> are they valid, though?
[20:56:08] <brada> some
[20:56:17] <brada> otheres im unsure of
[20:56:21] <fuzzie> both clang and msvc analyzers seem to mostly produce noise
[20:56:36] <fuzzie> but there are certainly some serious bugs pointed out by coverity
[20:56:39] <brada> yeah a lot are the uninilialized value
[20:58:24] <fuzzie> CID 1004458 is probably yours
[20:58:44] <lynxlynxlynx> i already pushed a fix for that
[20:58:47] <fuzzie> aha
[20:59:22] <fuzzie> so well I can just point to 23a35b0a03d8c33a965a4856dc3739d9fb24de5b then as nice analyzer result :)
[21:22:09] <-- edheldil_ has left IRC (Ping timeout: 252 seconds)
[22:33:12] --- ermo is now known as ermo^
[23:08:20] <-- Maighstir has left IRC (Quit: .)
[23:10:22] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:40:54] <-- Cable_ has left IRC (Read error: Operation timed out)
[23:54:24] --> Cable_ has joined #gemrb