View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000146||LDMud 3.7||General||public||2004-11-26 20:15||2022-10-06 21:48|
|Summary||0000146: Filenames in master calls should always start with a leading '/'|
|Description||This might break backwards compatibility.|
|Tags||No tags attached.|
Ok, had a look into it:
- make_path_absolute(): obviously does not get an absolute path and should not. ;-)
- include_file/inherit_file(): they get the file to be inherit/included not as absolute, because they should make them absolute, if necessary. The file currently compiled is given with absolute paths if !compat.
- compile_object(): not absolute
- get_ed_buffer_save_file_name(): not absolute
- get_wiz_name(): not absolute
- preload(): absolute paths
- privilege_violation(): seems to get only objects, although its mixed according to the manpage.
- valid_exec(): program has no leading /
- valid_read()/valid_write(): absolute path.
- runtime_error(), heart_beat_error(): curobj and curprg are not absolute.
- runtime_warning(): curobj is made absolute if !compat, but curprg not.
I just think about: another possibility than to manipulate the paths each time prior to apply_master() is to always use absolute object names and program names, not only during master applies, because that would be more consistent (e.g. you get the program in runtime_error() absolute, but in debug_info() it is not). But on the other hand, in the case of paths for reading/writing files that makes it more complicated access files in the driver...
Also, in that case, we should first get rid of the compat mode.
We should get rid of compat mode anyway. :-)
And I'd support the idea of having a leading '/' an all absolute path names.
Most changes would affect the master only, so the compatibility is not that a problem (if we do it in 3.5). And I don't think it would complicate the driver side (you just have to use filename+1 to skip the leading '/').
||You are right. But one problem is to find all the places where we use such paths and not have to add some +1 to the pointers. I am not completely convinced that that will not be a pain in the ass. But maybe someone else has better knowledge. ;-)|
Getting rid of compat mode: I'm not the one who would go over 100MB area lib code and check for correct handling of absolute path names in our compat mode mudlib.
is easy with gred/sed, things like
not. Especially occurances where a filename is computed are almost only to find by the hard way.
Lars already tried that and came to the conclusion that he'll stuck with native and !native mode.
||With a simul_efun object_name() that removes the slash there would only be the master and simul_efun to check and occurrences of efun::object_name.|
|2009-09-26 19:15||zesstra||Status||new => assigned|
|2009-09-26 19:15||zesstra||Assigned To||=> zesstra|
|2009-09-28 15:01||zesstra||Note Added: 0001327|
|2009-09-29 12:28||Gnomi||Note Added: 0001334|
|2009-09-30 16:12||zesstra||Relationship added||parent of 0000664|
|2009-09-30 16:13||zesstra||Project||LDMud => LDMud 3.5|
|2009-09-30 16:14||zesstra||Note Added: 0001362|
|2009-09-30 17:02||zesstra||Relationship added||parent of 0000254|
|2009-10-01 04:47||Coogan||Note Added: 0001388|
|2009-10-01 04:58||Gnomi||Note Added: 0001389|
|2010-07-14 04:39||zesstra||Target Version||=> 3.5.0|
|2017-10-04 21:39||zesstra||Project||LDMud 3.5 => LDMud 3.6|
|2017-10-04 21:39||zesstra||Category||Runtime => General|
|2021-04-09 14:20||zesstra||Assigned To||zesstra =>|
|2021-04-09 14:20||zesstra||Status||assigned => confirmed|
|2021-04-09 14:20||zesstra||Target Version||3.5.0 =>|
|2022-10-06 21:48||Gnomi||Project||LDMud 3.6 => LDMud 3.7|