Microsoft newlines
Would it be possible to recognize the Windows cr/nl conventions, and with a kiss-of-kindness, blow them away?
Linux vi (symlink to vim), recognizes this line ending style, and treats it as white space.
When I got bizarre errors from the compiler, it took me awhile to realize I was building code from a "vfat" mounted Windows filesystem which used the convention.
Our single source directories are built on lots of platforms, including Windows.I would prefer to reduce the number of compilers in our development, which makes Sun Studio attractive for the Linux platform.
I haven't done exhaustive tests, but I think gcc and g++ handle this transparently.
Thanks ...
[703 byte] By [
dickdunbar] at [2007-11-26 8:30:33]
# 1
Hello,
I want to say that in the past I had success in compiling Fortran 90 source files with the carriage returns in them with SS10. What sort of errors are you getting?
I've always kept my files with just LF's, and the vast majority of modern text editors on windows (with the exception of notepad) didn't have a problem. When I come across a file with both CR and LF, I've always used a utility called "dos2unix" on them; it's bundled with Solaris and a number of Linux distros.
Also, if you're collaborated on project, most SCM's are CR/LF independent, so for cvs users they can check in and out code remotely from all platforms and it should be handled automagically.
# 2
We have no fortran anywhere in our product; this is a C/C++ issue.
The error messages are totally bogus and misleading.
I didn't keep the source around, but the most puzzling had to do with preprocessor statements:
#if ....
Gets diagnosed with bad white space ... leading one to think the compiler only supported "#if".
We use clearcase, and yes ... there are options to do translation in and out of clearcase, but when you start moving files around, these newlines creep into the code ... using ftp with ascii translation, for example.
I'm also aware of dos2unix, but those utilities have side-effects ... like changing the date, which affects make's ability to know what to build. I had to write my own dos2unix to eliminate a lot of that stuff.
And, this source is set R/O, so you can't just start nibbling away at it with dos2unix.
Beyond the recognizable .c and .h files, there is source that is built on the fly with yacc / flex and the like. If those source files have cr/lf, it propagates into the generated source.
And by "modern editors", would you include Microsoft Visual Studio in that mix?This is a big team of developers ... I don't get to call the shots on what tools they use (or I'd be shot).
I'm resourceful ... I can make this problem go away for myself with heroic measures and tenacity, but to be clear, I'm asking Sun to make a simple change to the compiler to make this problem disappear.
I think it would make the compiler more widely acceptable.
It's a silly, avoidable nuisance.
