Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2018-11-11

00:12:36jhMikeSBilgus: that -1 was completely intentional
00:14:04BilgusI'm sure it was, that is why I overlooked it as an issue the first time
00:14:07jhMikeSAnd besides, strlen() will act like memchr(s, '\0', -1)
00:15:04Bilgusmy 60 mb config.cfg file says different
00:16:15BilgusjhMikeS make a custom build of a simulator and change any setting then close it
00:17:07BilgusWell not at HEAD since I already pushed the change..
00:17:12jhMikeSI'm wondering if it's something with the parameter.
00:17:35jhMikeSThe change really shouldn't be needed. I'm just saying.
00:19:03jhMikeSHow would memchr miss a NULL. If a NULL isn't actually present, size has no limit, other than the buffer.
00:19:18BilgusAgreed, 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:17BilgusIKR 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:53jhMikeSwhich memchr is used? ours?
00:23:05Bilguswell its the sim so I can only assume the one on this machine
00:25:23jhMikeSmemchr must be messed up if our own isn't
00:25:45 Quit ZincAlloy (Quit: Leaving.)
00:30:02BilgusJust to illustrate https://imgur.com/a/RuOojvF
00:31:10jhMikeSI see lots of tiny text I can't make out
00:31:40Bilgusthats the contents of the file the point was the 68.98 mb
00:31:44jhMikeSah
00:32:58jhMikeSso a null was in fact present in the argument but memchr didn't actual stop? is that correct?
00:33:48Bilgusyes
00:34:40BilgusI 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:42jhMikeSthen I'd conclude the particular memchr implementation screwed
00:35:01Bilgusperhaps but there is a note
00:35:18jhMikeSI wonder if it internally converts the len parameter to some signed representation
00:36:10Bilgusgive me a second let me find the note
00:37:43Bilgusthis 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:10jhMikeSIt 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:32Bilgus'However, if memchr does not have any strict requirement on evaluation order, then this invokes undefined behavior.'
00:49:09jhMikeSYeah, but really, I must be too dense to interpret wft that's really supped to mean.
00:50:04jhMikeSthat memchr should return the first occurrence of c with n bytes is quite defined
00:50:40jhMikeSthere'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:55BilgusI read it as Non - posix or even posix implementations prior have the option to go in reverse if they so desire
00:51:47Bilgusif 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:49Bilgusyour*
00:54:02Bilgusone further note is that when I set len to SSIZE_MAX it fixed it as well
00:56:00BilgusSSIZEMAX is 2147483648 on my machine maybe I should look at what size_t len = -1; actually creates
00:56:16jhMikeSso the implementation isn't actually prepared to deal with a large value for a size_t
00:57:11jhMikeSthere was some MS bug recently caused by being sloppy with sign conversions internally
00:58:07Bilguswell I assume -1 would be 4294967295 so maybe but this machine is the ubuntu sim that we supply..
00:58:37Bilgusor at least the really old one if someone finally updated it
00:59:17jhMikeSI was using ubuntu when writing the new code, though I keep it updated all the time
00:59:29jhMikeSthe VM
01:00
01:00:17BilgusI 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:06jhMikeS(size_t)-1 should have defined behavior
01:01:06BilgusI figured what I pushed is a reasonable implementation while keeping the use of precision*
01:01:55jhMikeSI of course checked the output without precision specification and had no issues
01:05:24jhMikeSmy 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:36Bilgusthis is 32 bit
01:06:54Bilgusand I think its using the rockbox memchr by cursory glance
01:09:35Bilgusno nevermind memchr@@GLIBC_2.0
01:09:47Bilgusok 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:00
02:06:22 Join dys [0] (~dys@p5DD5B5A8.dip0.t-ipconnect.de)
02:38:53 Join mmint [0] (~mmint@unaffiliated/mmint)
03:00
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:00
04:07:01 Quit mmint (Ping timeout: 250 seconds)
05:00
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:00
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:00
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:00
08:04:04 Join ufdm [0] (~ufdm@c-75-72-5-49.hsd1.mn.comcast.net)
09:00
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:00
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:00
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:00
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:00
13:09:49 Quit ZincAlloy (Quit: Leaving.)
13:46:45***Saving seen data "./dancer.seen"
14:00
14:22:45 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com)
14:24:14 Quit thomasjfox (Quit: Konversation terminated!)
15:00
15:46:46***Saving seen data "./dancer.seen"
16:00
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:00
17:01:45 Quit lebellium (Client Quit)
17:46:48***Saving seen data "./dancer.seen"
18:00
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:00
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:00
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:00
21:46:55***Saving seen data "./dancer.seen"
23:00
23:31:35 Quit ZincAlloy (Quit: Leaving.)
23:43:45 Quit lebellium (Quit: Leaving)
23:46:58***Saving seen data "./dancer.seen"

Previous day | Next day