Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 09 Apr 2015 19:47:04 +0300
From: Alexander Cherepanov <ch3root@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Coding Style

On 2015-04-09 18:58, Solar Designer wrote:
> On Thu, Apr 09, 2015 at 08:58:42PM +0800, Kai Zhao wrote:
>> Even though
>> Kernel style states that "Never break user-visible strings such as printk
>> messages even it exceeds column 80" , the checkpatch.pl can't find this
>> problem, since the situation maybe complex. I think it would be better to
>> manually review these strings.
>
> FWIW, while I understand the rationale behind this rule, I dislike it.
>
> It looks like I'm in the minority, so I won't object to this rule in
> jumbo, but I'm not eager to introduce it in core.

I haven't really thought this through and I don't yet have a strong 
opinion on this. I just thought that Frank's idea got positive feedback.

But I don't quite understand what we are talking about specifically. 
What are our options?

For the example that was posted earlier in this thread I'd prefer the 
following solution:

--- a/src/common-opencl.c
+++ b/src/common-opencl.c
@@ -1733,8 +1733,8 @@ void opencl_find_best_gws(int step, unsigned long 
long int max_run_time,
                     (buffer_size * kpc * 1.1 >
                      get_max_mem_alloc_size(gpu_id)))) {
                         if (options.verbosity > 4)
-                               fprintf(stderr, "Hardware resources "
-                                       "exhausted\n");
+                               fprintf(stderr,
+                                   "Hardware resources exhausted\n");
                         break;
                 }

Is this what you dislike?

-- 
Alexander Cherepanov

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.