In message <98f571de-f47e-6259-f1ac-792ebed3ed54@xxxxxxxxxx> on Thu, 27 Dec 2018 10:12:34 +0100, Jakob Bohm <jb-openssl@xxxxxxxxxx> said: > On 24/12/2018 19:08, Richard Levitte wrote: > > In message <3fc4d543-d71a-8c22-566a-d902c4f7da03@xxxxxxxxx> on Mon, 24 > > Dec 2018 13:17:51 +0100, Gisle Vanem <gisle.vanem@xxxxxxxxx> said: > > > >> Richard Levitte wrote: > >> > >>>> I experimented some more. I figured the "auto" does not work. > >>>> But this works: > >>>> perl crypto\aes\asm\aesni-x86_64.pl nasm > tmp-file.s > >>>> diff tmp-file.s crypto\aes\aesni-x86_64.asm > >>>> > >>>> No diffs. > >>>> > >>>> Why does the the generation of .asm-files be so damn hard to > >>>> figure out? Some cmd-line help to show what "auto" does would > >>>> be nice. > >>> The "auto" flavor takes note of the output file extension. .asm vs .s > >>> in this case. > >> Thank, but it was a typo in my 1st email. The correct command was > >> with a redirect: > >> set ASM=nasm > >> f:\util\StrawberryPerl\perl\bin\perl crypto\aes\asm\aesni-x86_64.pl > >> auto > tmp-file.s > > That isn't a correct use of the script. All of the assembler perl > > scripts expect the output file as last argument, and the x86_64 ones > > do look at the output file and determines that if the extension is > > '.asm', nasm assembler is expected, otherwise you will get gas > > assembler. So if you redirect, the result is, mildly put, undefined. > > > > Thank you, though... it is time the assembler stuff gets documented, > > and I think I'm in a fairly good position to do so. I will not > > promise that it will happen fast, but it is in my backlog. > As a trivial (and easily audited first patch) perhaps make the > common code error out with a usage message to STDERR if the > command line makes no sense (no output file, wrong argument > count, auto with unrecognized file extension). Ideally this > would be in the common perl module(s), not in individual > assembler files. Ideas differ from one person to another, and there are ideas on flexibility based on intimate knowledge of these modules that are contrary to the more strict interpretation you desire. Also, and we've argued this back and forth quite a bit, there's the idea of the modules being usable without dependence on other modules (apart from the xlate module that they pipe to). These modules have worked this way for quite a while (apart from standardising on having the last argument be the output file at all times, that actually varied between assembler modules before 1.1.0), and while I agree with you that these modules are a bit too flexible (please take note of this before thinking that I'm arguing against you!), changing them need to be done carefully. > Remember that keeping every patch easily audited by the wider > community is essential to the trustworthiness of OpenSSL, the > great reformatting a while back was a major mistake in this > regard. Regarding the great reformatting, this may be argued 'til hell freezes over. One of the things we considered was that the old source format was arcane, didn't exist anywhere else, and wasn't even well supported by the project team members (there was code inserted in more common formats, most often the usual 4 space indent BSD format). The current format has much better recognision and is easy to support in editors and current formatters. So as "mistake" goes, keeping the old source code format could have been regarded as one just as much. Cheers, Richard -- Richard Levitte levitte@xxxxxxxxxxx OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
