From: Ernst B. <e.b...@xe...> - 2006-09-13 14:47:51
Attachments:
threadname.patch
|
Hi, Here a little patch that changes the argv[0] of threads started with lcd4linux's thread.c to the thread name. The new name will then show up on "ps" et al. a few more patches to the thread functions will follow shortly, I'm implementing some stuff for my "VFD4Linux" driver and will send patches for the generic parts I need during the progress. /Ernst |
From: Michael R. <re...@eu...> - 2006-09-13 15:04:58
|
Hi Ernst, > Here a little patch that changes the argv[0] of threads started with > lcd4linux's thread.c to the thread name. Fine, good idea! Did you already commit? Did I give you CVS write access? > a few more patches to the thread functions will follow shortly, I'm > implementing some stuff for my "VFD4Linux" driver and will send patches for > the generic parts I need during the progress. Patches are always welcome! > info("thread %s starting...", name); > + if (thread_argc > 0) { > + strncpy(thread_argv[0],name,strlen(thread_argv[0])); > + } just curious: isn't there a problem if the new (thread) name is longer than the "original" name, so your strncpy would overwrite things that are better not overwritten? I thing I read something like this sometime somewhere..... bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
From: Ernst B. <e.b...@xe...> - 2006-09-13 15:53:50
|
On Wednesday 13 September 2006 17:04, Michael Reinelt wrote: > Hi Ernst, > > > Here a little patch that changes the argv[0] of threads started with > > lcd4linux's thread.c to the thread name. > > Fine, good idea! > > Did you already commit? Did I give you CVS write access? Nope, doesn't seem like I have CVS write access. (I'm also not listed on the SF.net developer list for lcd4linux) > > a few more patches to the thread functions will follow shortly, I'm > > implementing some stuff for my "VFD4Linux" driver and will send patches > > for the generic parts I need during the progress. > > Patches are always welcome! > > > info("thread %s starting...", name); > > + if (thread_argc > 0) { > > + strncpy(thread_argv[0],name,strlen(thread_argv[0])); > > + } > > just curious: isn't there a problem if the new (thread) name is longer > than the "original" name, so your strncpy would overwrite things that > are better not overwritten? I thing I read something like this sometime > somewhere..... Thats why I used "strNcpy" with the original argv[0] length as limit. It won't overwrite data it shouldn't, but will truncate the threads name if its longer than the original binary name. To get longer names, one would have to do lots strange stuff, like reorganizing the layout of the entire argv array and possible the environment variables... too much work for a little cosmetic trick. Simply malloc'ing a new string and linking it into argv[0] unfortunately doesn't work. > > bye, Michael Greetings, /Ernst |
From: Michael R. <re...@eu...> - 2006-09-13 19:00:09
|
>> Did you already commit? Did I give you CVS write access? > > Nope, doesn't seem like I have CVS write access. (I'm also not listed on the > SF.net developer list for lcd4linux) Oh.. did you ever tell me your SF account name? I'll add you to the devel group. >>> + strncpy(thread_argv[0],name,strlen(thread_argv[0])); > Thats why I used "strNcpy" with the original argv[0] length as limit. > It won't overwrite data it shouldn't, but will truncate the threads name if > its longer than the original binary name. silly me... I always mix up src and dst with strcpy :-) bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
From: Ernst B. <e.b...@xe...> - 2006-09-13 19:27:42
|
On Wednesday 13 September 2006 21:18, Martin Hejl wrote: > >>>> + strncpy(thread_argv[0],name,strlen(thread_argv[0])); > >> > >> Thats why I used "strNcpy" with the original argv[0] length as limit. > >> It won't overwrite data it shouldn't, but will truncate the threads name > >> if its longer than the original binary name. > > > > silly me... I always mix up src and dst with strcpy :-) > > I didn't look at the context - but the thing that always bothered me > with (and kept me from using strncpy) is that if src is longer than > dest, the result is that dest is not terminated by \0 - unless I read > the manpage incorrectly: > > char *strncpy(char *restrict s1, const char *restrict s2, size_t n); > The strncpy() function shall copy not more than n bytes (bytes that > follow a null byte are not copied) from the array pointed to by > > s2 to the array pointed to by s1. > (...) > If there is no null byte in the first n bytes of the array pointed to > by s2, the result is not null-terminated > > Did I miss something? Well, usually that would be correct, but in this case, I'm overwriting an already NUL-terminated string with new data. strlen will return the length excluding the NUL char at the end of the original string, so, even in worst case, that NUL will stay where it is unmodified. /Ernst |
From: Martin H. <ma...@he...> - 2006-09-13 19:39:49
|
Hi Ernst, >> Did I miss something? > > Well, usually that would be correct, but in this case, I'm overwriting an > already NUL-terminated string with new data. strlen will return the length > excluding the NUL char at the end of the original string, so, even in worst > case, that NUL will stay where it is unmodified. Ah, right - I obviously missed the essential part. Thanks for clarifying what should have been obvious (I missed the part that the destination buffer is strlen(thread_argv[0])+1 bytes long, and is already \0 terminated) Martin |
From: Martin H. <ma...@he...> - 2006-09-13 19:19:09
|
Hi everybody, Michael Reinelt wrote: >>> Did you already commit? Did I give you CVS write access? >> Nope, doesn't seem like I have CVS write access. (I'm also not listed on the >> SF.net developer list for lcd4linux) > Oh.. did you ever tell me your SF account name? I'll add you to the > devel group. > >>>> + strncpy(thread_argv[0],name,strlen(thread_argv[0])); > >> Thats why I used "strNcpy" with the original argv[0] length as limit. >> It won't overwrite data it shouldn't, but will truncate the threads name if >> its longer than the original binary name. > > silly me... I always mix up src and dst with strcpy :-) I didn't look at the context - but the thing that always bothered me with (and kept me from using strncpy) is that if src is longer than dest, the result is that dest is not terminated by \0 - unless I read the manpage incorrectly: char *strncpy(char *restrict s1, const char *restrict s2, size_t n); The strncpy() function shall copy not more than n bytes (bytes that follow a null byte are not copied) from the array pointed to by s2 to the array pointed to by s1. (...) If there is no null byte in the first n bytes of the array pointed to by s2, the result is not null-terminated Did I miss something? Martin |