The CRLF and paths bit is most probably due to the fact that I do my diff/merge/dev work on Win32/64 boxes mostly - that's where all my toolkit sits anyway; hadn't realized your patch was that picky. When I do it on a *nix box, I always run 'patch -l' which doesn't complain; when code looks a real mess, there's always uncrustify - the savior for supplicants of disparate coding standards.
Those [i_a] bits are my markers in our local code base so I know which edits are mine when doing a (manual) merge with 'vanilla' CVS HEAD. Yes, I know there are smarter systems around, but I've been 'tracking' OpenSSL for almost a decade and tools available to me haven't always been smart enough to ensure I didn't lose local edits across upgrades. And drilling down the RCS database for every edit isn't fun nor fast like that. So marking has become a habit by now. Often accompanied with a short text about the 'why' or related info. Sorry, wasn't meant to be bothersome to you. Hm. So this means I'd better do a double-buffered process there: kick the edits over to the UNIX box into the fresh OpenSSL tree, erase the comments and pull a diff for those. Post, rinse (refresh OpenSSL base tree) & repeat. On Wed, May 26, 2010 at 8:28 PM, Stephen Henson via RT <[email protected]>wrote: > This (and several other) patches contain DOS CRLF EOLs and file names > (backslash separator). What are those [i_a] bits in comments as well? > > It would be appreciated if they had Unix LF EOL and path names so > patches can be applied cleanly without having to be manually edited. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: [email protected] mobile: +31-6-11 120 978 --------------------------------------------------
