openwall/john

Consistently (don't) split long source file lines

Open

#3 896 ouverte le 7 mai 2019

Voir sur GitHub
 (7 commentaires) (0 réactions) (1 assigné)C (1 997 forks)batch import
good first issuemaintenance/cleanupportability

Métriques du dépôt

Stars
 (8 833 stars)
Métriques de merge PR
 (Merge moyen 2j 4h) (1 PR mergée en 30 j)

Description

@jfoug's commit d89568a411a8ea2ba5feea944048d9d637f8a0ce split a long test vector that's now in openbsdsoftraid_variable_code.h into multiple lines. There are two issues with that:

  1. The split is through use of backslashes inside the string constant, whereas I think it'd be more reliable to close the string on one line and re-open it on the next (and let the compiler concatenate those partial strings) so that the behavior won't depend e.g. on lack of trailing whitespace.

  2. We've since got similarly long other lines into the same source file, which are not split, and even longer lines into other source files. So splitting just that one line makes no sense.

$ egrep -l '^.{4000}' *.[ch] 
agilekeychain_common_plug.c
bks_fmt_plug.c
diskcryptor_common_plug.c
dmg_common_plug.c
keystore_common_plug.c
openbsdsoftraid_variable_code.h
opencl_diskcryptor_aes_fmt_plug.c
opencl_electrum_modern_fmt_plug.c
opencl_pfx_fmt_plug.c
pfx_fmt_plug.c
$ egrep -l '^.{5000}' *.[ch] 
dmg_common_plug.c
keystore_common_plug.c
opencl_electrum_modern_fmt_plug.c
opencl_pfx_fmt_plug.c
pfx_fmt_plug.c

We should probably either un-split that one line or split all similarly long lines (and do it in the more reliable way I suggest above). It also makes sense to first un-split that one line for consistency, and then split all relevant lines in a separate commit/PR.

Guide contributeur