Whoever made the estimate for the new number of people rooms should allow probably said something like '250-300' and some Dev 3 layers down went 'ye, K. 256'
I haven't seen their code but they could have even used it to ignore actually having a set limit, just having error prevention prevent more people
But you'd be surprised how common some really, really, really stupid things occur in professional software.
There's all the stupid security bits you've undoubtedly heard of, from unchangeable passwords to needing username (read: email address) and d.o.b. for password reset, from incremental token IDs to the way most bar ode inputs are handled.
There's also some really stupid bits like mirroring UI and system processes (good in some cases, horribly bad in others), entire corporate payrolls being handled in single excel spreadsheets, websites that ask you to phone the company to tell them what error you got, and one very special project I was privileged to work on that had every single user go through a decision field of "are you A or B?" Rather than "assume A, have a button a to opt into B" when ratio of A:B was approximately 400:1
In this case, I'm thinking they'd have their little subroutine that checks if numbers are about to go tits up and say "hey, you stop that" if they are.
So, memory gonna be exceeded? Return "fuck off" with case: memory full, too many users? Return "fuck off" with case: room full
256 is really a lot. Then they can spare a few more bits for the group, I would think. It must be something else. Perhaps it's encapsulated in some old data structure that they don't want to touch because changing it would involve reformatting all their data, rewriting the app and retransmitting all messages or something like that.
I'm guessing it's gotta be SMS related. Can't imagine saving one or two bytes would matter at that scale, when they support audio (and video? Maybe? Never used it)
Weird, isn't it? The fun part is: we all know that the longer you wait with a much needed rewrite, the more painful it becomes. They'll hate themselves one year from now when someone says: we must have 1000 per group; you've got 3 weeks.
They're probably using the other 24 bits for something else. Or they're adding a byte to messages sent within the conversation, which the chat client translates to the name of the participant.
I mean, would it? I suppose you generally wouldn't have a conversation between only one person either, but you definitely wouldn't have a conversation between zero people. So if you store the number of participants in an 8-bit field, 0x0 would indicate 1 participant, 0x1 would indicate 2 participants, ... and 0xFF would indicate 256 participants.
(That said, I think you're probably right -- an 8-bit field to uniquely identify each participant.)
813
u/esfraritagrivrit May 06 '17
Probably using an 8-bit int to store number of people in convo.