Ответ: Ответ: LIBBB: config_*()

[Bernhard Fischer]

On Tue, Jul 15, 2008 at 09:41:57PM +0000, Vladimir Dronnikov wrote:
>I was waiting for a draft to be committed so we could work on
>particular piece of code. Thank you for applying, Denys!

Folks, looking at the code that was committed, i'm questioning if
crap^Wstuff like that should be enabled per default since even the
simplest stuff (nameif) segfaulted.

Either we wait for patches to mature to some degree (do at least
some minimal testing) or experimental stuff should be put on a hack-away
branch, really.

Anyway. I've touched the parser now and converted init to use it (see
r22865 and before). Of course i did _not_ test it, so if init somehow
fails to chdir to your slash and prints a message telling you that
it does a countdown for self-destruction then that's somehow expected ;)

see below.

>2008/7/15, Denys Vlasenko <vda.linux at googlemail.com>:
>> On Tuesday 15 July 2008 06:31, Vladimir Dronnikov wrote:
>>> As I expected the gain regarding the only applet is not big (if any).
>>> But to develop common interfaces is definitely an important task in
>>> the long run. Even if not applied directly one may use config_*()
>>> prototypes inline with some code thrown, and still the logic would
>>> retain and would provide the right results. There would be no need to
>>> reinvent the wheel.
>>
>> Ok, I applied the patch.
>>
>> Making it all cute in one go seems to be difficult, so I propose
>> the following plan:
>>
>> - convert more applets to it

Let's build a list (perhaps in TODO) so we can check if all potential
users are cought.

+ ifupdown
- init
+ dumpleases ? Does that make sense?
+ inetd
+ bb__pgsreader()

>>   - ifupdowm will require "comment only if # is first non-space char" fix

It would be fancy if we can avoid using regexes. To recognize "/* */"
style comments, perhaps some variant of index_in_strings-kind of comment
skipper would be useful or needed? (well no. for C-style comments we
would have to resort to carefully chosen regex, i fear)
>>   - etc
>> - code size in config_read() calls: add define magic to collapse
>>   ntokens/mintokens/comment params into one int param (similar to
>>   #define xrealloc_vector trick)
>> - optimize runtime space usage even more by collapsing consecutive
>>   delimiters
>> - speed up
>>   - see big fat comment at libbb/get_line_from_file.c how to spped up
>>     line reads (and maybe even fix sed in the process)
>>   - fix "mdev -s" to not rescan config file two zillion times
>>
>> I do not mean that _you_ (or anyone else) *must* to work on this.
>> (But this would be nice of you if you do).
>> It is meant to be an explanation "why we just committed 300+ bloat,
>> and how we will fix it" :)

Exactly the reason why it should have been added to some interim branch,
IMHO.