View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000423 | LDMud 3.3 | Compilation, Installation | public | 2005-12-01 02:47 | 2018-01-29 21:57 |
| Reporter | hkremss | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.3.712 | ||||
| Fixed in Version | 3.3.713 | ||||
| Summary | 0000423: --disable-use-new-inlines does not work (build fails) | ||||
| Description | If building with switch --disable-use-new-inlines gcc does stop 2x in closure.c and 1x in interpret.c. See additional informations. | ||||
| Additional Information | closure.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.) | ||||
| Tags | No tags attached. | ||||
|
|
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 |
|
|
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... |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
The driver can again be compiled without the new inline closures; but for now I'm not implementing to disable just the 'function' keyword. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-12-01 02:47 | hkremss | New Issue | |
| 2005-12-01 03:16 | hkremss | Note Added: 0000431 | |
| 2005-12-01 03:33 | hkremss | Note Added: 0000432 | |
| 2005-12-02 02:28 |
|
Note Added: 0000434 | |
| 2005-12-02 05:15 | hkremss | Note Added: 0000435 | |
| 2005-12-02 12:31 |
|
Note Added: 0000436 | |
| 2005-12-02 14:07 | hkremss | Note Added: 0000437 | |
| 2005-12-04 18:20 |
|
Status | new => resolved |
| 2005-12-04 18:20 |
|
Fixed in Version | => 3.3.713 |
| 2005-12-04 18:20 |
|
Resolution | open => fixed |
| 2005-12-04 18:20 |
|
Assigned To | => lars |
| 2005-12-04 18:20 |
|
Note Added: 0000441 | |
| 2006-02-28 20:04 |
|
Status | resolved => closed |
| 2010-11-16 09:42 |
|
Source_changeset_attached | => ldmud.git master 06a4b53b |
| 2018-01-29 18:59 |
|
Source_changeset_attached | => ldmud.git master 06a4b53b |
| 2018-01-29 21:57 |
|
Source_changeset_attached | => ldmud.git master 06a4b53b |
