Среда 01 Сентябрь 2004 20:32, Kim Woelders написал:
> Vadik Mironov wrote:
> > Good day, everybody !
> >
> > These two patches replace broken getword function in file.c with the
> > not broken one (I hope). Also i made small warkaround about one bug,
> > and i submit another patch later, but i need this function, so it
> > will be really cool, if somebody merge these patches to the CVS.
> > Thank you in advance.
>
> The getword() function is used only two places, in a function which
> probably never is called. As it is marked broken as well it is very
> close to elimination.
> If you need the quotation handling you may be able to use fword() or
> field(), otherwise maybe word() or simply sscanf().
> Also, please use char* (not unsigned) as the simple C string type like
> throughout the rest of the code.
>
> /Kim
Then i try to clarify why i wrote this and submit.
There is a bug in IPC_Debug (eesh , then simply "debug"), here is the patch:
--- ./e/etalon/e16/e/src/ipc.c 2004-08-21 01:13:56.000000000 +0400
+++ ./e/hacked/e16/e/src/ipc.c 2004-09-02 10:03:22.716571976 +0400
@@ -4432,6 +4432,11 @@
char param[1024];
int l;
const char *p;
+
+ if(NULL==params)
+ {
+ return ;
+ }
p = params;
l = 0;
I worked on a fullscreen applications problems under e (i had some troubles
with fullscreened reeaders and ooffice), but this happens not all the time,
and hopefully on the weekend i will be able to track this down.
I discovered this IPC_Debug null pointer and try to use eesh to get desired
info writing some more code to this function. When i looked in other
functions , i saw something like this:
-----------------------------------------------------------------------
static void
IPC_Cursor(const char *params, Client * c)
{
char buf[FILEPATH_LEN_MAX];
buf[0] = 0;
if (params)
{
char param1[FILEPATH_LEN_MAX];
char param2[FILEPATH_LEN_MAX];
char param3[FILEPATH_LEN_MAX];
param1[0] = 0;
param2[0] = 0;
param3[0] = 0;
word(params, 1, param1);
------------------------------------------------------------------------
there is two considerations on that code:
1. The allocation on the stack around 16 kilobytes is not a god idea, because
stack was invented for function calls and recursion , but not for storing
data. And this could theoretically lead to a problem in general case, if
system cannot allocate such a big chunk on the stack.
2. I don't know yet what happens with e, if i run something like this:
#!/bin/sh
eesh cursor "20000K of some trash withoun \n"
or something like :
name[0] = "/usr/X11R6/bin/eesh" ;
name[1] = "button" ;
name[3] = NULL ;
name[2] = malloc(20000) ;
int i = 0 ;
for(i=0;i<20000;i++)
{
name[2][i] = 'A' ;
}
execve(name[0],name,NULL) ;
hopefully nothing, but still this two functions word and fword are not safe,
scanf("%<num>n") is better, but it is not an easy tool for string parsing.
If somebody protected eesh from buffer smashing, then it is fine, but still
i'm suspicious in using word and fword anyway (and of course i believe there
is no suid binaries in disributions :-)).
The last point, that i would like to mention is unsigned char :
In that function i heavily used standard functions from ctype.h.
ISO/IEC 9899:1999 (C language) page 181.
BTW, another thing, if i declare the DEBUG macro through compiler option then
i cannot build eesh because there is only external declarations of the
call_level in E.h.
--
With best regards,
Vadik Mironov
<[EMAIL PROTECTED]>
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id808&op=click
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
