In article <[EMAIL PROTECTED]>,
Brian <[EMAIL PROTECTED]> writes:
> I very rarly run on MS, but here is the results...
>
> Yields 0d0d0a (binmode)
>
Ok, i think then all is explained. Lars's interpretation of how windows
reads something submitted as cr cr lf in http is the right one.
So what I think PGAS should do is
- fetch http input
- convert cr lf to \n (and lone lf to \n too)
- write the file in binmode to disk (since PGAS runs on unix this will
be ok anyways, but let's be pedantic)
- send the programs to the judges
1) inline in the mail (this is for ease of use in the cases where there
are no weird chars and because some MUA's want you to do extra
annoying work to get to an attachment)
2) attach the file *as a binary attachment* <- this is the key point
It's 2) that should really be run by the judges, though in general running
1) will work well fine, so they can do what has been done upto now in
general.
Problems with this approach:
- When viewing a 2) file on windows in certain editors you will see a
staircase effect (e.g. notepad), though many others will show a lone
lf as a newline (e.g. wordpad). The real danger might be if the judge
for some reason saves this file again and you run an editor that fixes
up lf to cr/lf and you then run it through the testprogram in binmode
(see next why)
- the testprogram normally reads in textmode (and we want that to stay
the default since most users write their code in text-mode). However, to
get the counting right, a 2) style file should be counted in binmode.
In general the difference should not matter, since in textmode a lone
lf becomes \n anyways, so riunning a 2) style file in textmode will almost
always give the same result. However, in the rare case that the user had an
intentianal cr \n, it will get eaten (same with cr cr \n)
So i think the testprogram should also get a change: have an option (-b ?)
where it does the counting by opening the file in binmode. In general it
won't matter at all if a judge uses -b or not, but when testing a binary
attachment it should in principle have been given, and matters in the
cases with the \r \n. It's probably best to also have a warning for if
the testprogram sees cr \n after reading to avoid accidents.
Hopefully this should handle all cases, won't need any special buttons
on PGAS (except the already discussed general "unescape" one), should
in general not change the way judges work and still allow easy and
os-independant handling of the weird cases.
Anyone see flaws ?
