Difference between revisions of "Talk:ERR GENERIC"
Jump to navigation
Jump to search
Omei Qunhua (talk | contribs) (Misuse of ERR_GENERIC) |
|||
| Line 6: | Line 6: | ||
::Agreed. If ERR_GENERIC is "A nebulous and inexplicable error, nothing is known about it" then it shouldn't really be used in cases where -1 specifically means "NOT FOUND". Such as llListFindList() and llSubStringIndex(). [[User:Omei Qunhua|Omei Qunhua]] 04:39, 4 January 2014 (PST) | ::Agreed. If ERR_GENERIC is "A nebulous and inexplicable error, nothing is known about it" then it shouldn't really be used in cases where -1 specifically means "NOT FOUND". Such as llListFindList() and llSubStringIndex(). [[User:Omei Qunhua|Omei Qunhua]] 04:39, 4 January 2014 (PST) | ||
:::Shit. I've been found out, twice. Yes, I wrote both the description for ERR_GENERIC and attributed it to mean NOT FOUND. Guidance as to it's real meaning was non-existent. If you were going to bolt an error value onto an old function, it would be generic. So if ERR_GENERIC isn't to be used in this case that is fine, I'll roll it all back, but what does it actually mean? And it made the code of the "!= -1" folks code so much easier to read (they could do with a NOT_FOUND constant). As to 0xFFFFFFFFFFFFFFFF, changing how integer literals worked would break existing scripts (when they were recompiled), 64bit integers would likely be a new type. We don't need to worry about 64bit integers for a good while, to quote Maestro Linden (who was joking) in {{JIRA|BUG-4703}} about [http://en.wikipedia.org/wiki/Year_2038_problem Year 2038 problem] "Scheduled for sprint-summer'''2027'''". Anyway, how do we want to move forward? -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 21:01, 4 January 2014 (PST) | |||
Revision as of 22:01, 4 January 2014
Hex vs Decimal
Oh! Do people who come to the wiki for help understand 0xFFFFFFFF better than -1? Have we lost the plot? Will all these constants be changed when LSL moves to a 64-bit VM? Mind you, 0xFFFFFFFFFFFFFFFF would be a bit of a mouthful Omei Qunhua 02:33, 3 January 2014 (PST)
- This one is not supposed to be a flag, it was for llReturnObjectsByID and llReturnObjectsByOwner, part of a sequence. The string and list index usage appears to have been editorial whim on the wiki, working by coincidence. --ObviousAltIsObvious Resident 10:43, 3 January 2014 (PST)
- Agreed. If ERR_GENERIC is "A nebulous and inexplicable error, nothing is known about it" then it shouldn't really be used in cases where -1 specifically means "NOT FOUND". Such as llListFindList() and llSubStringIndex(). Omei Qunhua 04:39, 4 January 2014 (PST)
- Shit. I've been found out, twice. Yes, I wrote both the description for ERR_GENERIC and attributed it to mean NOT FOUND. Guidance as to it's real meaning was non-existent. If you were going to bolt an error value onto an old function, it would be generic. So if ERR_GENERIC isn't to be used in this case that is fine, I'll roll it all back, but what does it actually mean? And it made the code of the "!= -1" folks code so much easier to read (they could do with a NOT_FOUND constant). As to 0xFFFFFFFFFFFFFFFF, changing how integer literals worked would break existing scripts (when they were recompiled), 64bit integers would likely be a new type. We don't need to worry about 64bit integers for a good while, to quote Maestro Linden (who was joking) in BUG-4703 about Year 2038 problem "Scheduled for sprint-summer2027". Anyway, how do we want to move forward? -- Strife (talk|contribs) 21:01, 4 January 2014 (PST)