> Date: Sat, 8 Jun 2002 22:10:46 +0000 (UTC) > From: [EMAIL PROTECTED] (Ton Hospel) > > In article <[EMAIL PROTECTED]>, > Lars Henrik Mathiesen <[EMAIL PROTECTED]> writes: > I disagree slightly. It was unfair to people who had thought of > using \0. It was only fair inside the group of people using \0. > And then only if they used it equally often.
Luckily it turned out not to decide any places in the end. > > Now if some golfer had had the time to fake up the HTTP [...] > > If only I'd known, I'd have done exactly that. but I had understood > that binary 0 would in fact be simply refused. That might also have been the outcome, I wasn't the only referee. > > Now we actually had some sightings of the CR/NL issue as well, with > > some submissions that only worked in Linux if I stripped ^M from the > > ends of lines inside strings, and one other that only worked if I > > _left_ the ^M on the end of the flags line. The latter problem quickly > > disappeared as the submitter changed his method, but both point to a > > possible Windows/Linux incompatibility. > > Actually it's a browser bug. newlines in text fields MUST be sent > as cr/lf. It's in the standard. And that was what all the browsers did --- even though the programs might not have had any crs in the editor window they were pasted from. > But by default you should take what's in the text field, replace > cr lf by \n and store in a file. Did you read all I wrote? There were submissions that would stop working if that was done. Since they worked on Windows, and when moved to Unix without changing the newlines, there is an OS issue. > Now perl actually has a weird rule that \r before \n is in fact > dropped by the parser. Which is how perl works and has nothing to do > with transfer issues. Except that it does not always work --- most of the time, leaving cr/lf inside strings worked just fine, but in a few examples there'd be spurious cr's in the output on Linux, and changing cr lf to lf in a string would make it work. Possibly a Perl bug, but the issue exists. On this course, I don't think anyone was trying to have literal carriage returns in their programs, so \r\r\n isn't that relevant --- but it's still an issue if you do newline canonicalization on Unix: \r\r\n from browser -> \r\n when stored -> \n when parsed -> \n when printed, but \r\r\n from browser -> \r\r\n when stored -> \r\n when parsed -> \r\r\n when printed on Windows (textmode assumed). Right? What I'm really after is a way to ensure that the referees won't have to test on both Windows and Unix. The 'correct' way would probably be to specify (and checked by submit.cgi) that the program as sent must have CR/LF newlines, which will be stored as-is on Windows, and as LF only on Unix --- and the same goes for newlines in input files and expected output, of course. If it then fails on one platform, it's rejected under the rule that says that solutions must work everywhere. I think that's the same as you're saying, in fact. But it would be good to know when there can actually be a difference, so approval doesn't depend on which ref does the testing. Flag -F at line end is one such case, literal cr at line end might be another. Lars Mathiesen (U of Copenhagen CS Dep) <[EMAIL PROTECTED]> (Humour NOT marked)
