View Issue Details

IDProjectCategoryView StatusLast Update
0000423LDMud 3.3Compilation, Installationpublic2018-01-29 22:57
Reporterhkremss Assigned Tolars 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version3.3.712 
Fixed in Version3.3.713 
Summary0000423: --disable-use-new-inlines does not work (build fails)
DescriptionIf building with switch --disable-use-new-inlines gcc does stop 2x in closure.c and 1x in interpret.c. See additional informations.
Additional Informationclosure.c
closure.c: In function `f_symbol_function':
closure.c:6139: `l' undeclared (first use in this function)
closure.c:6139: (Each undeclared identifier is reported only once
closure.c:6139: for each function it appears in.)
closure.c: In function `f_symbol_variable':
closure.c:6289: `l' undeclared (first use in this function)
make: *** [closure.o] Error 1

interpret.c: In function `eval_instruction':
interpret.c:8335: `context_size' undeclared (first use in this function)
interpret.c:8335: (Each undeclared identifier is reported only once
interpret.c:8335: for each function it appears in.)
TagsNo tags attached.

Activities

hkremss

2005-12-01 04:16

reporter   ~0000431

If I fix these issues, the MUD does not boot at all anymore. There seem to be even more issues with inline stuff. There are lots of visibility change warnings in the error log (example):
2005.12.01 10:06:53 secure/master/misc.c line 34: Warning: Inconsistent declaration of '__inline_secure_master_misc_c_35_0000': Visibility changed from 'private varargs' to 'nomask private varargs'.

The last 3 lines in error log are:
2005.12.01 10:06:53 secure/simul_efun.c line 2355: Warning: Inconsistent declaration of '__inline_secure_simul_efun_c_2356_000a': Visibility changed from 'private varargs' to 'nomask private varargs' near ' {'.
2005.12.01 10:06:53 'illegal' instruction encountered.
2005.12.01 10:06:53 Current object was secure/simul_efun

hkremss

2005-12-01 04:33

reporter   ~0000432

Another note. My intention to use --disable-use-new-inlines was not to exclude all the code from the driver, but to avoid that some wizards use it in the MUD. At the moment we have no need for 'just another stylish inline feature'. Maybe it's easier to switch the 'function' keyword off, than to maintain hundreds of ifdefs arround the code...

lars

2005-12-02 03:28

reporter   ~0000434

The purpose of --disable-use-new-inlines was in the early days of the inlines code to deactivate it altogether in case it crashed the Mud. Since then, the code has proven stable (obviously, as nobody has tried to disable it in a long time), and eventually this configuration switch will go away completely.

Now, why do you want to disable the feature for some wizards? Even if I did implement a method to selectively disable the function keyword (that would to through privilege_violation()), wizards would still be able to create inline closures in the old ($ $) syntax.

hkremss

2005-12-02 06:15

reporter   ~0000435

At the moment, we run our MUD on 3.2 base, but want to migrate to 3.3 next year. So we check the 3.3 branch for new features and what we want to use and what not. We already use (::) inline closures and we don't have any security concerns about it, so in our eyes it would make no sense to handle it through privilege_violation().
But we want to keep the code as clean as possible. Our concern is, that this (new) inline 'function' feature will lead to complex code, which isn't easy to maintain nor debug. The same reason, we don't like the array-call_other() feature. It may be a nice feature for experimental code in small MUDs, but we are a 'production MUD' and some kind of conservative. ;-) So we would be happy, to switch 'function' off. If we cannot via configure, we will hack it manually in lex.c. But of course we prefer the 'official' solution.

lars

2005-12-02 13:31

reporter   ~0000436

I can't say that I agree - 'function' was introduced to allow cleaner code than (: :) does because it does away with the anonymous parameters $1..$9; and under the hood, both are the same thing anyway so it doesn't make sense to allow the one, but not the other. If there's anything in the driver promoting hard-to-maintain code, it's lambda closures.

Furthermore, maintainable code is nothing the language can enforce; if it's a concern, then the appropriate answer are code reviews.

array-call_other was a different topic, as this change indeed allowed for sinister magic to happen and bugs to be hidden, because there is no direct indication in the source to distinguish it from a regular call_other.

hkremss

2005-12-02 15:07

reporter   ~0000437

OK, lambda closures may create hard-to-maintain code too, but luckily the number of wizards producing lambdas is constantly shrinking... ;-) Though I liked it...

Anyway, I assume we have different points of view and I cannot convince you to create a configure switch for this issue. We (in our MUD) will discuss, how to handle this feature. You may close this topic, if nobody else wants to give a statement. But the --disable-use-new-inlines switch is still broken. This should be documented somewhere or be removed completely, if nobody wants to fix it. At the moment it is not very useful...

Thanks for the discussion.

lars

2005-12-04 19:20

reporter   ~0000441

The driver can again be compiled without the new inline closures; but for now I'm not implementing to disable just the 'function' keyword.

Issue History

Date Modified Username Field Change
2005-12-01 03:47 hkremss New Issue
2005-12-01 04:16 hkremss Note Added: 0000431
2005-12-01 04:33 hkremss Note Added: 0000432
2005-12-02 03:28 lars Note Added: 0000434
2005-12-02 06:15 hkremss Note Added: 0000435
2005-12-02 13:31 lars Note Added: 0000436
2005-12-02 15:07 hkremss Note Added: 0000437
2005-12-04 19:20 lars Status new => resolved
2005-12-04 19:20 lars Fixed in Version => 3.3.713
2005-12-04 19:20 lars Resolution open => fixed
2005-12-04 19:20 lars Assigned To => lars
2005-12-04 19:20 lars Note Added: 0000441
2006-02-28 21:04 lars Status resolved => closed
2010-11-16 10:42 lars Source_changeset_attached => ldmud.git master 06a4b53b
2018-01-29 19:59 lars Source_changeset_attached => ldmud.git master 06a4b53b
2018-01-29 22:57 lars Source_changeset_attached => ldmud.git master 06a4b53b