Very hot commit, continue reading here:

This is a test commit using buffers large enough to handle both passwords and salts up to length 256.
It requires changes to the kernel code, which is not included in here.
It also requires some of the host code to be modified. Before we're going to modify kernel code to support the larger lengths I want to be
sure of:
1. Host code modification is ok (no overflows or underflows)
2. Passwords and Salts are printed correctly to status, outfile, show, left, etc.
3. Performance does not change (or only very minimal)
This is not a patch that supports actual cracking both passwords and salts up to length 256, but it can not fail anyway.
If if it does, there's no reason to continue to add support for both passwords and salts up to length 256.

include/types.h

@@ -673,8 +673,8 @@ typedef enum user_options_map
 
 typedef struct salt
 {
-  u32 salt_buf[16];
-  u32 salt_buf_pc[16];
+  u32 salt_buf[64];
+  u32 salt_buf_pc[64];
 
   u32 salt_len;
   u32 salt_len_pc;
@@ -838,7 +838,7 @@ typedef struct hashconfig hashconfig_t;
 
 typedef struct pw
 {
-  u32 i[16];
+  u32 i[64];
 
   u32 pw_len;
 
@@ -854,20 +854,20 @@ typedef struct bf
 
 } bf_t;
 
+typedef struct comb
+{
+  u32  i[64];
+
+  u32  pw_len;
+
+} comb_t;
+
 typedef struct bs_word
 {
   u32  b[32];
 
 } bs_word_t;
 
-typedef struct comb
-{
-  u32  i[8];
-
-  u32  pw_len;
-
-} comb_t;
-
 typedef struct cpt
 {
   u32    cracked;
@@ -885,18 +885,6 @@ typedef struct plain
 
 } plain_t;
 
-typedef struct wordl
-{
-  u32  word_buf[16];
-
-} wordl_t;
-
-typedef struct wordr
-{
-  u32  word_buf[1];
-
-} wordr_t;
-
 #include "ext_OpenCL.h"
 
 typedef struct hc_device_param