Re: [rfc] macros and macro usage
On Sun, Jun 15, 2008 at 08:23:20PM +0200, Denys Vlasenko wrote: > USE_IF_ARPING(int x = y;) > USE_IF_NOT_ARPING(const int x = 5;) Sorry I'm way behind on this list. Wouldn't USE_IF_ARPING(int x = y); be less ugly? Null statements seem to be ok in C. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: Ответ: MODPROBE: next generation
On Sunday 22 June 2008 19:36, Vladimir Dronnikov wrote:
> > I don't understand. In which state?
>
> Lines 130, 141, 142 etc. of Config.in in BB modutils. It states that there
> exists bloat.
>
> > Yes, and let's also change options of "find" and "dd", they are
> > so un-Unixy and inconvenient. Our new ones will be shorter to type
> > and parsing code will be smaller (we can reuse getopt32()).
> >
> > Nice idea, eh? Do you see why it could be not such a good idea?
>
> No, no, no! Noone talks of command line options being changed, Denys.
> Changed is the internal representation of data constituting intrinsic module
> dependencies and options.
> > Vladimir, you are not responding to my concern that having incompatible
> > _interface_ of our module tools will hamper adoption of busybox
> > in desktop systems.
>
> Interface _does_ remain compatible. Moreover, more BBification is suggested.
> Loosely bound tools depmod/modprobe/insmod/rmmod is bound tightlier in one
> called modprobe. The rest are just simplest wrappers:
>
> depmod := modprobe
>
> rmmod := modprobe -r
>
> etc.
>
> Since there is no need in explicit depmod (the first call to modprobe will
> generate dependencies if they are missing)
+ // goto modules directory
+ xchdir(CONFIG_DEFAULT_MODULES_DIR);
+ if (uname(&uts) >= 0)
+ chdir(uts.release);
+
+ // prepare module definitions
+ modules_dep = xmalloc_open_read_close(CONFIG_DEFAULT_DEPMOD_FILE, NULL);
+ // no modules.dep? -> create it
It is better to not use "modules.dep" file, it is presumed
to have "standard" format. As I understand your code
generates different one.
+ if (!modules_dep) {
+ // depmod: dump modules definitions
+ int fd = xopen(CONFIG_DEFAULT_DEPMOD_FILE, O_CREAT | O_TRUNC |
O_WRONLY);
What will happen if /lib/modules is read-only
(it is ro on my machine)?
+ recursive_action(CONFIG_DEFAULT_MODULES_DIR,
Is it correct directory? Should it be "." instead?
+ ACTION_RECURSE, /* flags */
+ fileAction, /* file action */
+ NULL, /* dir action */
+ (void *)fd, /* user data */
+ 0 /* depth */
+ );
> all depmod quirks (setting base
> directory, kernel version, etc.) are obsolete.
Too bad depmod is used when I run "make modules_install" when I build new
kernels.
Will it error out now?
> No need to prepare
> dependencies for target system -- no need to depmod.
>
> Again, all the stuff is entirely compiled out if one requires desktop
> compatibility. Having read all this don't you think we can advance on both
> desktop and embedded field if we adopt the way as a simplified modutils
> alternative?
It should be compatible. depmod should behave as expected in
kernel's "make modules_install" step. Even if it doesn't create
modules.dep, it should not fail. Can you make it so?
--
vda
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: back to square 2
On Sunday 22 June 2008 16:36, walter harms wrote:
> Hello Denys,hi list
> i have still no clue why the error occurs.
> while searching i notices something else:
>
>
> static char *prev_line(char *p) // return pointer first char prev line
> {
> p = begin_line(p); // goto begining of cur line
> if (p[-1] == '\n' && p > text)
> p--;// step to prev line
> p = begin_line(p); // goto begining of prev line
> return p;
> }
>
> static char *next_line(char *p) // return pointer first char next line
> {
> p = end_line(p);
> if (*p == '\n' && p < end - 1)
> p++;// step to next line
> return p;
> }
>
>
> please take a look at the if().
>
> if (p[-1] == '\n' && p > text)
> p--;// step to prev line
>
> access to p[-1] and then checking that p is valid ?
> Is there any guarantee that p>text will be evaluated first ?
No, there is a guarantee that p[-1] == '\n' will be evaluated first.
In C, in (a && b) a is evaluated first, and if it's false,
b won't be evaluated.
>
> i would suggest:
> if ( p == text ) return p;
> if (p[-1] == '\n') p--;
> same goes for next_line().
I just swapped a and b in (a && b) here. Thanks!
--
vda
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: back to square 2
Hello Denys,hi list
i have still no clue why the error occurs.
while searching i notices something else:
static char *prev_line(char *p) // return pointer first char prev line
{
p = begin_line(p); // goto begining of cur line
if (p[-1] == '\n' && p > text)
p--;// step to prev line
p = begin_line(p); // goto begining of prev line
return p;
}
static char *next_line(char *p) // return pointer first char next line
{
p = end_line(p);
if (*p == '\n' && p < end - 1)
p++;// step to next line
return p;
}
please take a look at the if().
if (p[-1] == '\n' && p > text)
p--;// step to prev line
access to p[-1] and then checking that p is valid ?
Is there any guarantee that p>text will be evaluated first ?
i would suggest:
if ( p == text ) return p;
if (p[-1] == '\n') p--;
same goes for next_line().
re,
wh
ps: unfortunately my current vi.c is full of debug stuff but i hope you
can handle :)
Denys Vlasenko wrote:
> On Saturday 21 June 2008 16:29, walter harms wrote:
>> hi denis,
>> it seems that the patch has exposed some other error also:
>>
>> again clipping some data into vi it crashes. Now by a different reason:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0804f27c in char_insert (p=0x4018b006 "", c=10 '\n') at vi.c:1643
>> 1643for (; isblank(*q); q++) {
>>
>> p q
>> $1 = 0x80995d7
>>
>> i will investigate further.
>
> Thanks.
> --
> vda
>
>
>
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: [patch] editors/vi.c: compile error
On Sunday 22 June 2008 12:45, Cristian Ionescu-Idbohrn wrote: > editors/vi.c: In function 'do_cmd': > editors/vi.c:3643: error: expected ')' before 'readonly_mode' > editors/vi.c:3643: error: expected statement before ')' token > > Attached patch, possible workaround. Applied both, thanks! -- vda ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
[patch] editors/vi.c: compile error
editors/vi.c: In function 'do_cmd':
editors/vi.c:3643: error: expected ')' before 'readonly_mode'
editors/vi.c:3643: error: expected statement before ')' token
Attached patch, possible workaround.
Cheers,
--
CristianIndex: editors/vi.c
===
--- busybox-svn/editors/vi.c (revision 22467)
+++ busybox-svn/editors/vi.c (working copy)
@@ -269,7 +269,7 @@
#define modifying_cmds (G.modifying_cmds )
#define last_search_pattern (G.last_search_pattern)
#define chars_to_parse (G.chars_to_parse )
-
+
#define edit_file__cur_line (G.edit_file__cur_line)
#define refresh__old_offset (G.refresh__old_offset)
#define format_edit_status__tot (G.format_edit_status__tot)
@@ -3640,10 +3640,12 @@
break;
}
if (file_modified) {
- if (ENABLE_FEATURE_VI_READONLY && readonly_mode) {
-status_line_bold("\"%s\" File is read only", current_filename);
-break;
- }
+ USE_FEATURE_VI_READONLY(
+if (readonly_mode) {
+ status_line_bold("\"%s\" File is read only", current_filename);
+ break;
+}
+ )
cnt = file_write(current_filename, text, end - 1);
if (cnt < 0) {
if (cnt == -1)
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
[patch] editors/vi.c whitespace damage cleanup
Cheers, -- CristianIndex: editors/vi.c === --- editors/vi.c (revision 22467) +++ editors/vi.c (working copy) @@ -255,11 +255,11 @@ #define erase_char (G.erase_char ) #define last_input_char (G.last_input_char) #define last_forward_char (G.last_forward_char ) -#if ENABLE_FEATURE_VI_READONLY +#if ENABLE_FEATURE_VI_READONLY #define readonly_mode (G.readonly_mode ) -#else +#else #define readonly_mode 0 readonly_mode ) -#endif +#endif #define adding2q(G.adding2q ) #define lmc_len (G.lmc_len) #define ioq (G.ioq) @@ -269,7 +269,7 @@ #define modifying_cmds (G.modifying_cmds ) #define last_search_pattern (G.last_search_pattern) #define chars_to_parse (G.chars_to_parse ) - + #define edit_file__cur_line (G.edit_file__cur_line) #define refresh__old_offset (G.refresh__old_offset) #define format_edit_status__tot (G.format_edit_status__tot) ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
