[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110725000304.GA21181@openwall.com>
Date: Mon, 25 Jul 2011 04:03:04 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Plugin formats "released"
Jim -
On Sun, Jul 24, 2011 at 06:44:24PM -0500, JimF wrote:
> Not sure exactly what the differences are, but in sparc sed, the \+ did not
> do what we want it to do.
"+" matches one or more instances of the preceding item, "*" matches
zero or more instances. At least under GNU sed, "+" is considered an
extended regexp feature, so it needs either the "\" prefix or the "-r"
option to sed. My guess (unverified) is that Sun's sed implements "+"
under the standard regexp syntax, thus not requiring and not absorbing
the "\" before it.
> Are there any side effects, such as:
>
> struct fmt_main XXX=
> {
> }
>
> or something like that, causing issues?
The above won't work (no whitespace after the identifier name), but
that's on purpose and irrespective of this specific regexp change.
> In the above, there is no space
> between name and =, and nothing after the = char. I am not sure how sed
> will handle this one, in the way we have it.
The way I wrote the sed expression, it requires a space there, but does
not require the opening curly brace on the same line. This is the
strictest requirement that the existing files matched. Initially, I
tried requiring the curly brace on the same line as well, but a few
files did not match that syntax.
If you want to make the space before "=" optional, you may change:
sed -n 's/^\(struct fmt_main [^ ]*\) =.*/extern \1;/p' *_fmt_plug.c
to:
sed -n 's/^\(struct fmt_main [^ ]*\) *=.*/extern \1;/p' *_fmt_plug.c
In fact, to make the number of space characters elsewhere optional, we
could write:
sed -n 's/^\(struct *fmt_main *[^ ]*\) *=.*/extern \1;/p' *_fmt_plug.c
This uses two spaces followed by "*", which means that the first space
is required and the second one we need zero or more instances of. So
we require one or more in this way, without using the "+".
But I don't think we want any of those changes.
> The one thing we have to keep in mind, is that if the fmt_*.h files are not
> built properly, then you get no warning what so ever. Everything builds
> just fine. Even on sparc, when the files were being built 0 bytes long,
> everything 'appeared' normal, until I ran john, and only the base formats
> were there. Just an FYI to keep in mind, when producing the jumbo, to make
> sure everthing is there, and working.
Right. It'd be nice to have the build detect the count mismatch, but
let's revisit this later. I'd rather not spend time on a patch trying
to deal with this now. We have other priorities.
Thanks,
Alexander
P.S. I mentally apply s/sparc/Solaris/g to your messages. ;-) Clearly,
you're referring to Solaris and _not_ to SPARC. Solaris runs on more
than just SPARC, and systems other than Solaris run on SPARC.
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.
