--- Log for 11.11.118 Server: barjavel.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 month and 5 days ago 00.12.36 # Bilgus: that -1 was completely intentional 00.14.04 # I'm sure it was, that is why I overlooked it as an issue the first time 00.14.07 # And besides, strlen() will act like memchr(s, '\0', -1) 00.15.04 # my 60 mb config.cfg file says different 00.16.15 # jhMikeS make a custom build of a simulator and change any setting then close it 00.17.07 # Well not at HEAD since I already pushed the change.. 00.17.12 # I'm wondering if it's something with the parameter. 00.17.35 # The change really shouldn't be needed. I'm just saying. 00.19.03 # How would memchr miss a NULL. If a NULL isn't actually present, size has no limit, other than the buffer. 00.19.18 # Agreed, and at first I copied rbversion into the buffer and that fixed it as well so maybe something to do with its location in the binary 00.20.17 # IKR I sat there and verified the string had a null by stepping through it each character and then ran memcmp on it and it missed it every time! 00.20.53 # which memchr is used? ours? 00.23.05 # well its the sim so I can only assume the one on this machine 00.25.23 # memchr must be messed up if our own isn't 00.25.45 Quit ZincAlloy (Quit: Leaving.) 00.30.02 # Just to illustrate https://imgur.com/a/RuOojvF 00.31.10 # I see lots of tiny text I can't make out 00.31.40 # thats the contents of the file the point was the 68.98 mb 00.31.44 # ah 00.32.58 # so a null was in fact present in the argument but memchr didn't actual stop? is that correct? 00.33.48 # yes 00.34.40 # I even tried adding extra nulls and even setting chr to a character in the string it was like it wasn't even looking at the right string 00.34.42 # then I'd conclude the particular memchr implementation screwed 00.35.01 # perhaps but there is a note 00.35.18 # I wonder if it internally converts the len parameter to some signed representation 00.36.10 # give me a second let me find the note 00.37.43 # this is what atsampson referenced that got me looking at it in the first place.. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1533.htm 00.38.50 Join Corun [0] (~Corun@cpc112703-nmal22-2-0-cust350.19-2.cable.virginm.net) 00.38.52 Quit Corun (Client Quit) 00.43.10 # It sounds like it's preferring strnlen because it won't actually look at bytes past any match point but memchr might actually read beyond. Still that doesn't say it shouldn't return the first occurence of '\0' 00.45.32 # 'However, if memchr does not have any strict requirement on evaluation order, then this invokes undefined behavior.' 00.49.09 # Yeah, but really, I must be too dense to interpret wft that's really supped to mean. 00.50.04 # that memchr should return the first occurrence of c with n bytes is quite defined 00.50.40 # there's also 'Implementations shall behave as if they read the memory byte by byte from the beginning of the bytes pointed to by s and stop at the first occurrence of c (if it is found in the initial n bytes).' 00.50.55 # I read it as Non - posix or even posix implementations prior have the option to go in reverse if they so desire 00.51.47 # if this were true then yor/my assumptions would be true Implementations shall behave as if they read the memory byte by byte from the beginning of the bytes pointed to by s and stop at the first occurrence of c (if it is found in the initial n bytes). 00.52.49 # your* 00.54.02 # one further note is that when I set len to SSIZE_MAX it fixed it as well 00.56.00 # SSIZEMAX is 2147483648 on my machine maybe I should look at what size_t len = -1; actually creates 00.56.16 # so the implementation isn't actually prepared to deal with a large value for a size_t 00.57.11 # there was some MS bug recently caused by being sloppy with sign conversions internally 00.58.07 # well I assume -1 would be 4294967295 so maybe but this machine is the ubuntu sim that we supply.. 00.58.37 # or at least the really old one if someone finally updated it 00.59.17 # I was using ubuntu when writing the new code, though I keep it updated all the time 00.59.29 # the VM 01.00.17 # I have to head out but I can look into it further if you desire or change it to using SSIZE_MAX since I assume you were using memchr in prep for a wchar implementation 01.01.06 # (size_t)-1 should have defined behavior 01.01.06 # I figured what I pushed is a reasonable implementation while keeping the use of precision* 01.01.55 # I of course checked the output without precision specification and had no issues 01.05.24 # my opinion so far is the implementation doesn't actually like the full unsigned size_t range 01.05.28 Quit dys (Ping timeout: 252 seconds) 01.06.36 # this is 32 bit 01.06.54 # and I think its using the rockbox memchr by cursory glance 01.09.35 # no nevermind memchr@@GLIBC_2.0 01.09.47 # ok gtg 01.12.09 Quit michaelni (Ping timeout: 268 seconds) 01.25.29 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) 01.38.26 Quit mmint (Ping timeout: 264 seconds) 01.46.34 *** Saving seen data "./dancer.seen" 01.58.45 Join Bilgus_ph [0] (d0365aa1@gateway/web/freenode/ip.208.54.90.161) 01.59.50 Quit Bilgus_ph (Client Quit) 02.06.22 Join dys [0] (~dys@p5DD5B5A8.dip0.t-ipconnect.de) 02.38.53 Join mmint [0] (~mmint@unaffiliated/mmint) 03.03.22 Quit mmint (Ping timeout: 252 seconds) 03.04.05 Join mmint [0] (~mmint@unaffiliated/mmint) 03.27.01 Join massiveH [0] (~massiveH@ool-18e4e27c.dyn.optonline.net) 03.46.35 *** Saving seen data "./dancer.seen" 03.54.36 Join diox [0] (~u@h-103-251.A785.priv.bahnhof.se) 04.07.01 Quit mmint (Ping timeout: 250 seconds) 05.10.45 Join this_is_a_nick [0] (~amofiuhr_@ip186-132-50-179.ct.co.cr) 05.46.36 *** Saving seen data "./dancer.seen" 06.09.51 Quit ufdm (Read error: Connection reset by peer) 06.12.49 Join ufdm [0] (~ufdm@c-75-72-5-49.hsd1.mn.comcast.net) 06.38.15 Quit TheSeven (Disconnected by services) 06.38.25 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 07.02.34 Quit Moarc (Quit: i znowu NADMUCHAƁ BALONA) 07.07.43 Join Moarc [0] (~chujko@a105.net128.okay.pl) 07.36.44 Quit ufdm (Read error: Connection reset by peer) 07.46.26 Quit jhMikeS (Ping timeout: 240 seconds) 07.46.38 *** Saving seen data "./dancer.seen" 08.04.04 Join ufdm [0] (~ufdm@c-75-72-5-49.hsd1.mn.comcast.net) 09.30.49 Join massive_H [0] (~massiveH@ool-18e4e27c.dyn.optonline.net) 09.31.40 Quit massiveH (Ping timeout: 268 seconds) 09.46.39 *** Saving seen data "./dancer.seen" 10.26.53 Join ZincAlloy [0] (~Adium@2a02:8108:9440:dfc:49a6:bd15:4863:cf5e) 10.35.15 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 11.13.10 Quit Natch (Remote host closed the connection) 11.26.47 Join Natch [0] (~Natch@h-112-130.A444.priv.bahnhof.se) 11.46.42 *** Saving seen data "./dancer.seen" 12.04.40 Quit this_is_a_nick (Remote host closed the connection) 12.16.27 Quit Moarc (Quit: i znowu NADMUCHAƁ BALONA) 12.20.39 Join Moarc [0] (~chujko@a105.net128.okay.pl) 12.37.32 Join xorly [0] (~xorly@ip-86-49-24-93.net.upcbroadband.cz) 13.09.49 Quit ZincAlloy (Quit: Leaving.) 13.46.45 *** Saving seen data "./dancer.seen" 14.22.45 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 14.24.14 Quit thomasjfox (Quit: Konversation terminated!) 15.46.46 *** Saving seen data "./dancer.seen" 16.26.41 Quit sanchaez (Ping timeout: 268 seconds) 16.28.31 Join ZincAlloy [0] (~Adium@2a02:8108:9440:dfc:49a6:bd15:4863:cf5e) 16.35.40 Join sanchaez [0] (~sanchaez@reactos/developer/sanchaez) 16.37.11 Quit massive_H (Quit: Leaving) 16.59.41 Join lebellium [0] (~lebellium@2a01cb0802f85900914d6a4d2560df00.ipv6.abo.wanadoo.fr) 17.01.45 Quit lebellium (Client Quit) 17.46.48 *** Saving seen data "./dancer.seen" 18.18.00 Join Corun [0] (~Corun@cpc112703-nmal22-2-0-cust350.19-2.cable.virginm.net) 18.30.46 Join lebellium [0] (~lebellium@2a01cb0802f85900bcd4d92c257b197d.ipv6.abo.wanadoo.fr) 18.46.02 Join mmint [0] (~mmint@unaffiliated/mmint) 18.59.16 Quit mmint (Ping timeout: 252 seconds) 19.03.12 Join mmint [0] (~mmint@unaffiliated/mmint) 19.46.50 *** Saving seen data "./dancer.seen" 19.58.21 Quit Corun (Quit: This computer has gone to sleep) 20.18.13 Join MulX [0] (~mulx@eva.aplu.fr) 20.19.05 Quit APLU (Ping timeout: 264 seconds) 20.19.05 Nick MulX is now known as APLU (~mulx@eva.aplu.fr) 21.46.55 *** Saving seen data "./dancer.seen" 23.31.35 Quit ZincAlloy (Quit: Leaving.) 23.43.45 Quit lebellium (Quit: Leaving) 23.46.58 *** Saving seen data "./dancer.seen"