#rockbox 2018-11-11

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).

#rockbox log for 2018-11-11

00:12:36	jhMikeS	Bilgus: that -1 was completely intentional
00:14:04	Bilgus	I'm sure it was, that is why I overlooked it as an issue the first time
00:14:07	jhMikeS	And besides, strlen() will act like memchr(s, '\0', -1)
00:15:04	Bilgus	my 60 mb config.cfg file says different
00:16:15	Bilgus	jhMikeS make a custom build of a simulator and change any setting then close it
00:17:07	Bilgus	Well not at HEAD since I already pushed the change..
00:17:12	jhMikeS	I'm wondering if it's something with the parameter.
00:17:35	jhMikeS	The change really shouldn't be needed. I'm just saying.
00:19:03	jhMikeS	How would memchr miss a NULL. If a NULL isn't actually present, size has no limit, other than the buffer.
00:19:18	Bilgus	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	Bilgus	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	jhMikeS	which memchr is used? ours?
00:23:05	Bilgus	well its the sim so I can only assume the one on this machine
00:25:23	jhMikeS	memchr must be messed up if our own isn't
00:25:45		Quit ZincAlloy (Quit: Leaving.)
00:30:02	Bilgus	Just to illustrate https://imgur.com/a/RuOojvF
00:31:10	jhMikeS	I see lots of tiny text I can't make out
00:31:40	Bilgus	thats the contents of the file the point was the 68.98 mb
00:31:44	jhMikeS	ah
00:32:58	jhMikeS	so a null was in fact present in the argument but memchr didn't actual stop? is that correct?
00:33:48	Bilgus	yes
00:34:40	Bilgus	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	jhMikeS	then I'd conclude the particular memchr implementation screwed
00:35:01	Bilgus	perhaps but there is a note
00:35:18	jhMikeS	I wonder if it internally converts the len parameter to some signed representation
00:36:10	Bilgus	give me a second let me find the note
00:37:43	Bilgus	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	jhMikeS	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	Bilgus	'However, if memchr does not have any strict requirement on evaluation order, then this invokes undefined behavior.'
00:49:09	jhMikeS	Yeah, but really, I must be too dense to interpret wft that's really supped to mean.
00:50:04	jhMikeS	that memchr should return the first occurrence of c with n bytes is quite defined
00:50:40	jhMikeS	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	Bilgus	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	Bilgus	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	Bilgus	your*
00:54:02	Bilgus	one further note is that when I set len to SSIZE_MAX it fixed it as well
00:56:00	Bilgus	SSIZEMAX is 2147483648 on my machine maybe I should look at what size_t len = -1; actually creates
00:56:16	jhMikeS	so the implementation isn't actually prepared to deal with a large value for a size_t
00:57:11	jhMikeS	there was some MS bug recently caused by being sloppy with sign conversions internally
00:58:07	Bilgus	well I assume -1 would be 4294967295 so maybe but this machine is the ubuntu sim that we supply..
00:58:37	Bilgus	or at least the really old one if someone finally updated it
00:59:17	jhMikeS	I was using ubuntu when writing the new code, though I keep it updated all the time
00:59:29	jhMikeS	the VM
01:00
01:00:17	Bilgus	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	jhMikeS	(size_t)-1 should have defined behavior
01:01:06	Bilgus	I figured what I pushed is a reasonable implementation while keeping the use of precision*
01:01:55	jhMikeS	I of course checked the output without precision specification and had no issues
01:05:24	jhMikeS	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	Bilgus	this is 32 bit
01:06:54	Bilgus	and I think its using the rockbox memchr by cursory glance
01:09:35	Bilgus	no nevermind memchr@@GLIBC_2.0
01:09:47	Bilgus	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: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