| Message ID | 1429190974-19730-1-git-send-email-mike.holmes@linaro.org |
|---|---|
| State | New |
| Headers | show |
On 04/16/2015 04:29 PM, Mike Holmes wrote: > We have an 80 char limit that is frequently an issue for strings and we > just accept that we ignore the warning. > > Allow split strings so that there is a valid alternative > Thus the following example becomes a legal alternative to the > 80 chars > warning. > > printf("\nThread %u (id=%d core=%d) had %u sync_failures" > " in %u iterations\n", thread_num, > ..... > The reason to have an exception for printed strings length is to have them in one line to be searchable in a codebase. In this example grep'ing for 'sync_failures in' won't find this string.
On 16 April 2015 at 09:41, Taras Kondratiuk <taras.kondratiuk@linaro.org> wrote: > On 04/16/2015 04:29 PM, Mike Holmes wrote: > >> We have an 80 char limit that is frequently an issue for strings and we >> just accept that we ignore the warning. >> >> Allow split strings so that there is a valid alternative >> Thus the following example becomes a legal alternative to the > 80 chars >> warning. >> >> printf("\nThread %u (id=%d core=%d) had %u sync_failures" >> " in %u iterations\n", thread_num, >> ..... >> >> > The reason to have an exception for printed strings length is to have > them in one line to be searchable in a codebase. > > In this example grep'ing for 'sync_failures in' won't find this string. > As with Google you just take a portion of the string if you really have an issue. I rarely include syntactic elements in a search, in the same way that if you search for this string verbatim with he specific thread id, core and number of failures set in the actual string seen on stdout you would not find the code either.
On 04/16/2015 04:50 PM, Mike Holmes wrote: > > > On 16 April 2015 at 09:41, Taras Kondratiuk <taras.kondratiuk@linaro.org > <mailto:taras.kondratiuk@linaro.org>> wrote: > > On 04/16/2015 04:29 PM, Mike Holmes wrote: > > We have an 80 char limit that is frequently an issue for strings > and we > just accept that we ignore the warning. > > Allow split strings so that there is a valid alternative > Thus the following example becomes a legal alternative to the > > 80 chars > warning. > > printf("\nThread %u (id=%d core=%d) had %u sync_failures" > " in %u iterations\n", thread_num, > ..... > > > The reason to have an exception for printed strings length is to have > them in one line to be searchable in a codebase. > > In this example grep'ing for 'sync_failures in' won't find this string. > > > As with Google you just take a portion of the string if you really have > an issue. > > I rarely include syntactic elements in a search, in the same way that if > you search for this string verbatim with he specific thread id, core and > number of failures set in the actual string seen on stdout you would not > find the code either. I can't agree. - As with Google the longer string you can specify the more precise results you will get. - It is usually valid to assume that all numeric information in error message is not a part of format string, so you start search with substring which contains only words or you can wildcard numbers.
On 16 April 2015 at 15:50, Mike Holmes <mike.holmes@linaro.org> wrote: > > > On 16 April 2015 at 09:41, Taras Kondratiuk <taras.kondratiuk@linaro.org> > wrote: > >> On 04/16/2015 04:29 PM, Mike Holmes wrote: >> >>> We have an 80 char limit that is frequently an issue for strings and we >>> just accept that we ignore the warning. >>> >>> Allow split strings so that there is a valid alternative >>> Thus the following example becomes a legal alternative to the > 80 chars >>> warning. >>> >>> printf("\nThread %u (id=%d core=%d) had %u sync_failures" >>> " in %u iterations\n", thread_num, >>> ..... >>> >>> >> The reason to have an exception for printed strings length is to have >> them in one line to be searchable in a codebase. >> >> In this example grep'ing for 'sync_failures in' won't find this string. >> > The above format string would better be expressed as printf("\nThread %u (id=%d core=%d) had %u sync_failures in " "%u iterations\n", thread_num, E.g. break at a formatting directive. But grepping using regular expressions ("had .* sync_failures in .* iterations") would still fail. So allowing for lines (with strings) longer than 80 chars is preferable. > As with Google you just take a portion of the string if you really have an > issue. > > I rarely include syntactic elements in a search, in the same way that if > you search for this string verbatim with he specific thread id, core and > number of failures set in the actual string seen on stdout you would not > find the code either. > > -- > Mike Holmes > Technical Manager - Linaro Networking Group > Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp > >
diff --git a/.checkpatch.conf b/.checkpatch.conf index 9076410..a063213 100644 --- a/.checkpatch.conf +++ b/.checkpatch.conf @@ -2,3 +2,4 @@ --strict --ignore=NEW_TYPEDEFS --ignore=DEPRECATED_VARIABLE +--ignore=SPLIT_STRING
We have an 80 char limit that is frequently an issue for strings and we just accept that we ignore the warning. Allow split strings so that there is a valid alternative Thus the following example becomes a legal alternative to the > 80 chars warning. printf("\nThread %u (id=%d core=%d) had %u sync_failures" " in %u iterations\n", thread_num, ..... Signed-off-by: Mike Holmes <mike.holmes@linaro.org> --- .checkpatch.conf | 1 + 1 file changed, 1 insertion(+)