View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000798LDMud 3.5Efunspublic2011-12-09 16:562018-01-30 03:59
ReporterSorcerer Assigned Tozesstra  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Target Version3.5.0Fixed in Version3.5.0 
Summary0000798: deprecate/remove strlen()
DescriptionAs far as I can tell, strlen() does exactly the same as sizeof() with the one exception that it only accepts strings as argument. But exactly in this there is an inconsistency: usually, efuns that expect strings as argument throw an error upon passing 0. strlen accepts 0.

So, if there are no internal differences between strlen() and sizeof() that favor strlen() I suggest to deprecate it and in some future after 3.5 remove it. If someone really needs it at that point for compatibility, a sefun returning sizeof() does the trick.
TagsNo tags attached.

Activities

zesstra

2011-12-09 23:47

administrator   ~0002088

These two efuns currently have the same result, but not really the same meaning.
We discussed that 2-3 years ago in some issue about wide char strings.
As soon as we will introduce wide char strings (e.g. UTF16), sizeof() and strlen() will start to differ (sizeof(): no of bytes, strlen(): no of characters).
Therefore I always recommend to use strlen() if a wizard wants to know the no of characters.
So I don't think we should deprecate strlen().

Gnomi

2011-12-09 23:54

manager   ~0002089

I disagree. Even with unicode support sizeof() should return the number of characters, not bytes. Sizeof() never returns the number of bytes, it returns the number of elements in arrays, mappings or strings. And it does so because the number of bytes are not relevant to the wizard in any way. Also for wide strings all string indexing functions would work on a character basis, so the byte count is never needed.

Gnomi

2011-12-10 00:00

manager   ~0002090

So I'm in favor of deprecating strlen().

zesstra

2011-12-10 00:02

administrator   ~0002091

I was sure, the discussion a few years ago was in the other direction. ;-) But maybe it was not you, but someone else. I agree, that the indexing operator for strings should work on the basis of characters.
One problem is, that for some applications you have to know to length of a string in bytes (e.g. you want to send over the network and no \0 termination). They might be rarely used in MUDs, but I would take them into account.

Gnomi

2011-12-10 00:08

manager   ~0002092

When sending a unicode string you first have to convert it into a specific encoding, yielding a kind of array of bytes. This byte array is no more a unicode string, but would be treated like a ASCII string (the kind we have now), where strlen() and sizeof() would return the number of bytes (as it is now).

zesstra

2014-02-23 22:41

administrator   ~0002233

I will add a comment to the manpage of strlen(). But we will wait a bit for deprecating strlen() in the code so that our users can first work on a plethora of new type errors in their mudlibs. ;-)

zesstra

2015-05-10 20:29

administrator   ~0002255

We will also remove this one in 3.5.0 since it is a simple replacement by script or sefun.

zesstra

2016-01-20 16:17

administrator   ~0002273

Fix committed in revision 41a17400ede247f0ef6b894d204f66baddbc41ab to master branch (see changeset 1044 for details). Thank you for reporting!

zesstra

2018-01-29 18:59

administrator   ~0002305

Fix committed in revision 41a17400ede247f0ef6b894d204f66baddbc41ab to master branch (see changeset 1350 for details). Thank you for reporting!

zesstra

2018-01-29 21:57

administrator   ~0002356

Fix committed in revision 41a17400ede247f0ef6b894d204f66baddbc41ab to master branch (see changeset 2676 for details). Thank you for reporting!

zesstra

2018-01-30 03:59

administrator   ~0002407

Fix committed in revision 41a17400ede247f0ef6b894d204f66baddbc41ab to master branch (see changeset 3763 for details). Thank you for reporting!

Issue History

Date Modified Username Field Change
2011-12-09 16:56 Sorcerer New Issue
2011-12-09 23:47 zesstra Note Added: 0002088
2011-12-09 23:54 Gnomi Note Added: 0002089
2011-12-10 00:00 Gnomi Note Added: 0002090
2011-12-10 00:02 zesstra Note Added: 0002091
2011-12-10 00:08 Gnomi Note Added: 0002092
2014-02-23 22:41 zesstra Note Added: 0002233
2014-02-23 22:41 zesstra Status new => confirmed
2014-02-23 22:46 zesstra Source_changeset_attached => ldmud.git master a9de3f24
2014-02-23 22:49 zesstra Target Version => 3.5.0
2015-05-10 20:29 zesstra Note Added: 0002255
2015-05-10 20:29 zesstra Assigned To => zesstra
2015-05-10 20:29 zesstra Status confirmed => assigned
2016-01-20 16:17 zesstra Source_changeset_attached => ldmud.git master 41a17400
2016-01-20 16:17 zesstra Note Added: 0002273
2016-01-20 16:17 zesstra Status assigned => resolved
2016-01-20 16:17 zesstra Resolution open => fixed
2016-01-20 16:17 zesstra Fixed in Version => 3.5.0
2018-01-29 18:59 zesstra Source_changeset_attached => ldmud.git master 41a17400
2018-01-29 18:59 zesstra Source_changeset_attached => ldmud.git master a9de3f24
2018-01-29 18:59 zesstra Note Added: 0002305
2018-01-29 21:57 zesstra Source_changeset_attached => ldmud.git master 41a17400
2018-01-29 21:57 zesstra Source_changeset_attached => ldmud.git master a9de3f24
2018-01-29 21:57 zesstra Note Added: 0002356
2018-01-30 03:59 zesstra Source_changeset_attached => ldmud.git master 41a17400
2018-01-30 03:59 zesstra Source_changeset_attached => ldmud.git master a9de3f24
2018-01-30 03:59 zesstra Note Added: 0002407