Re: [E-devel] Engage / strcmp v. strncmp

2005-01-02 Thread Andrew Elcock
Frederick Heckel wrote:
On Fri, 17 Dec 2004 21:57:25 + Andrew Elcock [EMAIL PROTECTED]
claimed:
It should not be listening to directories at all - see how it passes 0
as the recurse setup bit? anyhow all .eet icons will be moved to .eapp
soon, so this code will change.
as for null winclasses - if (winclass  ...
is just wrong - if you have a null winclass the icon is not valid for 
engage, it requires winclass to function properly...

Fair enough. Since the directory nodes are structural, I'd suggest that
null checks on the app-winclass field may serve perfectly well to
ignore them as apps-- if the timescale of the .eapp change makes it
worth fixing this crash anyway.
(fwph)
OK - well, now null winclasses do not seg, but put out a warning.
Engage now uses .eapps in the ~/.e/e/applications/all directory which
(should) all have valid window classes!
use the e_util_eapp_edit application (in CVS/e17/apps/e_utils) to edit
the .apps if you do not do that already.
Hope this helps,
HandyAndE

---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Engage / strcmp v. strncmp

2004-12-29 Thread Andrew Elcock
[EMAIL PROTECTED] wrote:
On Fri, 17 Dec 2004 16:15:16 EST, Frederick Heckel said:
 

What happened here is that there was an empty directory sitting in my
mapping/ dir. It looks like e_app_new is fine with directories, but it
doesn't actually fill out the app-winclass field if
$subdir/.directory.eet doesn't exist, but still tries to add it as an
app.
   

That sounds buggy to me - it should either invent a default winclass value,
or not try to add it as an app.  But that's just my opinion based on a
quarter century of coding - the actual author of the code gets final call here. ;)
 

It should not be listening to directories at all - see how it passes 0 
as the recurse setup bit? anyhow all .eet icons will be moved to .eapp 
soon, so this code will change.

as for null winclasses - if (winclass  ...
is just wrong - if you have a null winclass the icon is not valid for 
engage, it requires winclass to function properly...

Handy
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Engage / strcmp v. strncmp

2004-12-17 Thread Frederick Heckel
Hello all,

I'm a longtime fan of Enlightenment, just waiting for DR17. I did a CVS
ebuild on my Gentoo system yesterday, and have tried out Engage. It's
very nice, except for one thing: when I try to actually setup any
launcher icons, it segfaults. 

Running a gdb trace, it was segfaulting in strcmp. Looking through the
code, I saw an awful lot of strcmps and strcpys. My question is, what is
this family of string functions being used? They're just inviting memory
errors like the seg fault I'm getting. Is there really any reason to not
just be safe and use the strn functions instead?

(fwph)

--
Frederick Heckel
[EMAIL PROTECTED]
(The strange attachment is my digital signature; do not be alarmed)

===
linux: the choice of a GNU generation
([EMAIL PROTECTED] put this on Tshirts in '93)


pgpk6VwASX4Pq.pgp
Description: PGP signature


Re: [E-devel] Engage / strcmp v. strncmp

2004-12-17 Thread Kim Woelders
Frederick Heckel wrote:
I'm a longtime fan of Enlightenment, just waiting for DR17. I did a 
CVS ebuild on my Gentoo system yesterday, and have tried out Engage. 
It's very nice, except for one thing: when I try to actually setup 
any launcher icons, it segfaults.

Running a gdb trace, it was segfaulting in strcmp. Looking through 
the code, I saw an awful lot of strcmps and strcpys. My question is, 
what is this family of string functions being used? They're just 
inviting memory errors like the seg fault I'm getting. Is there 
really any reason to not just be safe and use the strn functions 
instead?

strncmp cannot simply replace strcmp. There isn't even any point in
doing so for the reason mentioned here. Segv in strcmp is typically
because one of the pointers is invalid or NULL, and strncmp will most
likely segv in exactly the same way.
strcpy/strncpy is an entirely different matter as they potentially
overflow the destination buffer.
/Kim
---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Engage / strcmp v. strncmp

2004-12-17 Thread Frederick Heckel
On Fri, 17 Dec 2004 20:03:33 +0100 Kim Woelders [EMAIL PROTECTED]
claimed:
 strncmp cannot simply replace strcmp. There isn't even any point in
 doing so for the reason mentioned here. Segv in strcmp is typically
 because one of the pointers is invalid or NULL, and strncmp will most
 likely segv in exactly the same way.

Fair enough, though generally it seems like neither function really does
the right thing, as strcmp will happily keep comparing memory beyond the
capacity of a buffer, though this isn't really a problem unless there's
already been an overflow...

 strcpy/strncpy is an entirely different matter as they potentially
 overflow the destination buffer.

And the use of strcpy is far more of a concern to me; strcmp just comes
up because it's the function that made me check out the code in the
first place. There are also strcats floating around in there. 

(fwph)

--
Frederick Heckel
[EMAIL PROTECTED]
(The strange attachment is my digital signature; do not be alarmed)

===
It's raisins that make Post Raisin Bran so raisiny ...


pgpxgll119ozD.pgp
Description: PGP signature


Re: [E-devel] Engage / strcmp v. strncmp

2004-12-17 Thread Frederick Heckel

Anyway, a null check needs to be added to Engage's icon.c, in
od_icon_mapping_get() to fix the problem. app-winclass was null. Engage
starts up fine for me with this quick change:

358c358,359
 if (strcmp(winclass, app-winclass) == 0) {
---
 
 if (winclassapp-winclassstrcmp(winclass, app-winclass) == 0)
 {

(fwph)

--
Frederick Heckel
[EMAIL PROTECTED]
(The strange attachment is my digital signature; do not be alarmed)

===
I wish you were a Scotch on the rocks.


pgpjWd0Fr8UAq.pgp
Description: PGP signature


Re: [E-devel] Engage / strcmp v. strncmp

2004-12-17 Thread Valdis . Kletnieks
On Fri, 17 Dec 2004 15:11:43 EST, Frederick Heckel said:

 Anyway, a null check needs to be added to Engage's icon.c, in
 od_icon_mapping_get() to fix the problem. app-winclass was null. Engage
 starts up fine for me with this quick change:
 
 358c358,359
  if (strcmp(winclass, app-winclass) == 0) {
 ---
  
  if (winclassapp-winclassstrcmp(winclass, app-winclass) == 0)

This is just begging the question however - is this:

1) A proper fix, because od_icon_mapping_get() could legitimately be called
with a NULL and it should Do Something Reasonable

2) Papering over the *real* bug, which is that somebody else is failing to
set winclass or app-winclass before calling the function?

If it's case (2), then we're just looking at a matter of time before the *next*
symptom shows up.. ;)


pgpWUu0AdGx0j.pgp
Description: PGP signature


Re: [E-devel] Engage / strcmp v. strncmp

2004-12-17 Thread Frederick Heckel
On Fri, 17 Dec 2004 15:56:50 -0500 [EMAIL PROTECTED] claimed:
 This is just begging the question however - is this:
 
 1) A proper fix, because od_icon_mapping_get() could legitimately be
 called with a NULL and it should Do Something Reasonable
 
 2) Papering over the *real* bug, which is that somebody else is
 failing to set winclass or app-winclass before calling the function?

I'm not sure, actually. Someone else will have to define legitimate. I
generally believe that null checks are a good idea anyway, though they
can cover up bugs... Arguably that's coding style.

What happened here is that there was an empty directory sitting in my
mapping/ dir. It looks like e_app_new is fine with directories, but it
doesn't actually fill out the app-winclass field if
$subdir/.directory.eet doesn't exist, but still tries to add it as an
app. 

Should it pay attention to directories in mapping/ that lack a .eet
file?

(fwph)

--
Frederick Heckel
[EMAIL PROTECTED]
(The strange attachment is my digital signature; do not be alarmed)

===
A kind of Batman of contemporary letters.
-- Philip Larkin on Anthony Burgess
rs


pgpEfoiI8WSrj.pgp
Description: PGP signature


Re: [E-devel] Engage / strcmp v. strncmp

2004-12-17 Thread Valdis . Kletnieks
On Fri, 17 Dec 2004 16:15:16 EST, Frederick Heckel said:

 What happened here is that there was an empty directory sitting in my
 mapping/ dir. It looks like e_app_new is fine with directories, but it
 doesn't actually fill out the app-winclass field if
 $subdir/.directory.eet doesn't exist, but still tries to add it as an
 app.

That sounds buggy to me - it should either invent a default winclass value,
or not try to add it as an app.  But that's just my opinion based on a
quarter century of coding - the actual author of the code gets final call here. 
;)


pgpotz6jHEj09.pgp
Description: PGP signature


Re: [E-devel] Engage / strcmp v. strncmp

2004-12-17 Thread Frederick Heckel
On Fri, 17 Dec 2004 21:57:25 + Andrew Elcock [EMAIL PROTECTED]
claimed:
 It should not be listening to directories at all - see how it passes 0
 as the recurse setup bit? anyhow all .eet icons will be moved to .eapp
 soon, so this code will change.
 
 as for null winclasses - if (winclass  ...
 is just wrong - if you have a null winclass the icon is not valid for 
 engage, it requires winclass to function properly...

Fair enough. Since the directory nodes are structural, I'd suggest that
null checks on the app-winclass field may serve perfectly well to
ignore them as apps-- if the timescale of the .eapp change makes it
worth fixing this crash anyway.

(fwph)

--
Frederick Heckel
[EMAIL PROTECTED]
(The strange attachment is my digital signature; do not be alarmed)

===
Oh, that sound of male ego.  You travel halfway across the galaxy and
it's still the same song.
-- Eve McHuron, Mudd's Women, stardate 1330.1


pgpW5GJkxJpKo.pgp
Description: PGP signature


Re: [E-devel] Engage / strcmp v. strncmp

2004-12-17 Thread The Rasterman
On Fri, 17 Dec 2004 20:03:33 +0100 Kim Woelders [EMAIL PROTECTED] babbled:
(B
(B Frederick Heckel wrote:
(B  I'm a longtime fan of Enlightenment, just waiting for DR17. I did a 
(B  CVS ebuild on my Gentoo system yesterday, and have tried out Engage. 
(B  It's very nice, except for one thing: when I try to actually setup 
(B  any launcher icons, it segfaults.
(B  
(B  Running a gdb trace, it was segfaulting in strcmp. Looking through 
(B  the code, I saw an awful lot of strcmps and strcpys. My question is, 
(B  what is this family of string functions being used? They're just 
(B  inviting memory errors like the seg fault I'm getting. Is there 
(B  really any reason to not just be safe and use the strn functions 
(B  instead?
(B  
(B strncmp cannot simply replace strcmp. There isn't even any point in
(B doing so for the reason mentioned here. Segv in strcmp is typically
(B because one of the pointers is invalid or NULL, and strncmp will most
(B likely segv in exactly the same way.
(B strcpy/strncpy is an entirely different matter as they potentially
(B overflow the destination buffer.
(B
(Bthanks kim :) couldn't have said it better :) as an addition - beware of the
(Bnotion that just because you go use strncmp (or some strn function) doesn't
(Bsuddenly make your code safe. its a notion  the very inexperienced get if they
(Bjust go read some book or advice column saying they should use strn... the only
(Bway to do this is sit back and THINK of the input, output and possible errors
(Band cover them in the code. that always requires sitting and thinking about it
(B:) so just beware. it's not a fix. it's a pitfall of making you THINK you're
(Bsafe when you really are no safer than before.
(B
(B-- 
(B- Codito, ergo sum - "I code, therefore I am" --
(BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
$BMg9%B?(B  [EMAIL PROTECTED]
(BTokyo, Japan ($BEl5~(B $BF|K\(B)
(B
(B
(B---
(BSF email is sponsored by - The IT Product Guide
(BRead honest  candid reviews on hundreds of IT Products from real users.
(BDiscover which products truly live up to the hype. Start reading now. 
(Bhttp://productguide.itmanagersjournal.com/
(B___
(Benlightenment-devel mailing list
([EMAIL PROTECTED]
(Bhttps://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Engage / strcmp v. strncmp

2004-12-17 Thread Frederick Heckel
On Sat, 18 Dec 2004 09:58:19 +0900 Carsten Haitzler (The Rasterman)
[EMAIL PROTECTED] claimed:
 thanks kim :) couldn't have said it better :) as an addition - beware
 of the notion that just because you go use strncmp (or some strn
 function) doesn't suddenly make your code safe. its a notion  the very
 inexperienced get if they just go read some book or advice column
 saying they should use strn... the only way to do this is sit back and
 THINK of the input, output and possible errors and cover them in the
 code. that always requires sitting and thinking about it:) so just
 beware. it's not a fix. it's a pitfall of making you THINK you're safe
 when you really are no safer than before.

It's true that you can write bad and unsafe code with any set of
functions, and doing something like using the strn set rather than the
str functions doesn't automatically make code safe. That doesn't
invalidate the value of using strn functions and keeping careful track
of your buffer sizes. Don't get me wrong, I'm sure all the major
developers know the size of the buffers they're using, and probably will
not overflow them, but when you've got code that a potentially very
large pool of people will modify-- as either part of the development
cycle for e, or as code reuse in a separate project, or a fork of one of
the e projects-- it really just seems like a better idea to be explicit
about it.

(fwph)

--
Frederick Heckel
[EMAIL PROTECTED]
(The strange attachment is my digital signature; do not be alarmed)

===

Forget it, Marge, it's Chinatown!

-- Homer Simpson
   Secrets of a Successful Marriage


pgpYnGr5ouIWZ.pgp
Description: PGP signature


Re: [E-devel] Engage / strcmp v. strncmp

2004-12-17 Thread The Rasterman
On Fri, 17 Dec 2004 22:23:07 -0500 Frederick Heckel [EMAIL PROTECTED]
(Bbabbled:
(B
(B On Sat, 18 Dec 2004 09:58:19 +0900 Carsten Haitzler (The Rasterman)
(B [EMAIL PROTECTED] claimed:
(B  thanks kim :) couldn't have said it better :) as an addition - beware
(B  of the notion that just because you go use strncmp (or some strn
(B  function) doesn't suddenly make your code safe. its a notion  the very
(B  inexperienced get if they just go read some book or advice column
(B  saying they should use strn... the only way to do this is sit back and
(B  THINK of the input, output and possible errors and cover them in the
(B  code. that always requires sitting and thinking about it:) so just
(B  beware. it's not a fix. it's a pitfall of making you THINK you're safe
(B  when you really are no safer than before.
(B 
(B It's true that you can write bad and unsafe code with any set of
(B functions, and doing something like using the strn set rather than the
(B str functions doesn't automatically make code safe. That doesn't
(B invalidate the value of using strn functions and keeping careful track
(B of your buffer sizes. Don't get me wrong, I'm sure all the major
(B developers know the size of the buffers they're using, and probably will
(B not overflow them, but when you've got code that a potentially very
(B large pool of people will modify-- as either part of the development
(B cycle for e, or as code reuse in a separate project, or a fork of one of
(B the e projects-- it really just seems like a better idea to be explicit
(B about it.
(B
(Byes - but the solution is not (in this case) strn but fixing the problem
(Bupstream - ie blindly using string pointers without checking them :) or for that
(Bmatter passing in invalid ones (ie NULL may be invalid for that function). :)
(B
(B
(B
(B-- 
(B- Codito, ergo sum - "I code, therefore I am" --
(BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
$BMg9%B?(B  [EMAIL PROTECTED]
(BTokyo, Japan ($BEl5~(B $BF|K\(B)
(B
(B
(B---
(BSF email is sponsored by - The IT Product Guide
(BRead honest  candid reviews on hundreds of IT Products from real users.
(BDiscover which products truly live up to the hype. Start reading now. 
(Bhttp://productguide.itmanagersjournal.com/
(B___
(Benlightenment-devel mailing list
([EMAIL PROTECTED]
(Bhttps://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Engage / strcmp v. strncmp

2004-12-17 Thread Frederick Heckel
On Sat, 18 Dec 2004 12:45:47 +0900 Carsten Haitzler (The Rasterman)
[EMAIL PROTECTED] claimed:
 yes - but the solution is not (in this case) strn but fixing the
 problem upstream - ie blindly using string pointers without checking
 them :) or for that matter passing in invalid ones (ie NULL may be
 invalid for that function). :)

Well, yeah. :) But on principle it may just be worth keeping an eye on
those strcpys and strcats.

(fwph)

--
Frederick Heckel
[EMAIL PROTECTED]
(The strange attachment is my digital signature; do not be alarmed)

===
Economics is extremely useful as a form of employment for economists.
-- John Kenneth Galbraith


pgpb8rDT73ylx.pgp
Description: PGP signature