Re: [E-devel] API Documentation?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vincent Torri wrote: | | On Thu, 16 Dec 2004, Alex wrote: | | |I know that I have seen documentation for the APIs that the libraries |implement, but I can't find it anymore and a search of the archive |hasn't turned it up either. Can someone point me in the right direction? | | | the documentation on the site is a bit outdated | if you have the cvs tree, make sure you have doxygen installed and run | gendoc in the main directory of the lib whose documentation you want. Thanks! - -alex -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBwxOVdmWtRNAkjzERAoTqAJ9V6HTKbtsB3e1WvAG9kSLUl+VXgQCcDXPo 5ckB4JJWAEYhVCvKEgLeYVM= =y2ed -END PGP SIGNATURE- --- 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
[E-devel] Engage / strcmp v. strncmp
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
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
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
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
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
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
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
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
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
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
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
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