History | Log In     View a printable version of the current page.  
  • All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you've read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: VWR-438
Type: Bug Bug
Status: Closed Closed
Resolution: Misfiled
Priority: Normal Normal
Assignee: Unassigned
Reporter: Rita Cummings
Votes: 1
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR

llSetObjectDesc should limit length of description

Created: 14/Apr/07 04:55 AM   Updated: 05/Feb/08 06:33 AM
Component/s: Scripting, Inventory
Affects Version/s: None
Fix Version/s: None

Issue Links:
Relates
 


 Description  « Hide

1) Use llSetObjectDesc() to set the description to a text longer than 256 characters.
2) Take the object to the inventory
3) Try to rez it

it will fail with a "Unable to create requested object - parse failure." message

4) ask what does it mean to someone in the "Help Request" IM channel

you'll be told that it's because of your network connection and that she would bet her "SL teddy bear" on that.


 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
bushing Spatula - 14/Apr/07 07:11 AM
This is NOT a "critical" bug!

LL will have to weigh in here, but I'm going to guess they're going to close this as "won't fix" because there is a hard limit of 256 bytes for descriptions (of more or less any sort, but including object descriptions); to fix this, the message template would have to be changed from "Variable 1" to "Variable 2" in many places.

If anything, the bug here is that llSetObjectDesc() doesn't fail when you try to set the description, but if this is fixed, you still won't be able to set a longer description.

Rita Cummings - 14/Apr/07 12:59 PM
127 or 256 characters long?

Where did Lindens state the description length?

Change the wiki so that people don't waste their time in this thing!

Rita Cummings - 14/Apr/07 01:14 PM
I set it to critical because it causes data loss, as per definition of critical. Sorry.

Rita Cummings - 14/Apr/07 06:51 PM
And "data loss" is both the data that you stored in the description field and, which is more important, the object in the inventory and its content that cannot be rezzed anymore.

So there is a bug to fix here anyway.

Lex Neva - 15/Apr/07 08:55 AM
I have to agree with Rita on this. I'm upgrading this bug to critical because it can result in content loss for an unsuspecting person who's set a long description accidentally when using llSetObjectDesc(). Next time they try to rez their object, they find they've completely lost it.

I wouldn't rate the other issue on this topic (descriptions getting randomly truncated to 256 characters) as critical, because the system was never intended to support descriptions longer than 256 characters; but I would say that llSetObjectDesc() MUST implement bounds checking so as to avoid content loss as described succinctly in this issue.

Haravikk Mistral - 17/Apr/07 03:38 PM
I'd say the object should have it's description truncated to whatever the limit is rather than throwing up an error, THEN it can be sent. But we may as well reduce llSetObjectDesc() to 256 characters as well, a description is just that; a description. It's not intended for data-storage and it's always been touchy at best, just limit it completely, we don't need objects that have an extra 8k of overhead anyway.

bushing Spatula - 24/Apr/07 03:29 AM
No, this would be "Normal: Minor loss of function, or other problem where workaround is present." (The workaround is "don't do that, then".)

The fix here is to fix llSetObjectDesc to prevent someone from accidentally attempting this.

Eddy Stryker - 24/Apr/07 04:05 AM
llSetObjectDesc() is an LSL command that is run on the server, the bug needs to be refiled as a SVC (Service) bug. Whether the command should fail with a length of greater than 255 characters (a null terminator is required in the binary UDP protocol) or automatically truncate would be a good topic of discussion in the newly filed bug.

Boroondas Gupte - 09/Sep/07 07:25 AM
"don't do that, then" is only a workaround if you know about the issue *before* you have done so. Otherwise the object will be already lost which isn't expected behavior, I'd say.

anthony reisman - 14/Sep/07 10:08 AM
I created an issue as a SVC bug and linked it so this doesn't get lost. While it some may not consider it a "Critical" bug I do believe it is something that does need resolving so it shouldn't be closed unless another one is opened.

Lex Neva - 15/Sep/07 09:08 AM
For future reference, it's possible to convert a VWR bug to a SVC bug by using the "Move" option on the left.