The elpelele problem (was: Re: Sfront patches for Visual C)

From: Richard Dobson (rwd@cableinet.co.uk)
Date: Wed Aug 25 1999 - 16:03:59 EDT


I dunno, I eat my greens, go to college, read lots of books, and
eventually I launch myself into the public domain pretending that I
almost know what I am talking about, and announce with deep gravitas
that Visual C++ has bugs.

Well, maybe it does, but not this one. I wander around the code thinking
of something else entirely, and I spot something in sfront.c that
suddenly rings a forlorn bell of ashamed recognition. I type just one
character into one line, recompile, and, Hey Presto, sfront accepts all
of elpelele.mid, and creates a file that goes on to generate a splendid
46-point-something megabyte rendering of El Pelele that could only be
improved by the full Bosendorfer sample set.

The character in question is a 'b', and it went in this line of
sfront.c:

        midifile = fopen(argv[i],"rb");

This, of course, ensures the file is opened in binary mode, so that
bytes which happen to be quasi-EOF don't throw the next best thing to
the Millenium bug.

What I now want to know, is why it works without the 'b' under all the
other compilers, gcc included? Does the ANSI standard matter, anyway?

I should recover my sang-froid enough to post a revised sfront32.zip on
my website later this evening...

Richard Dobson

 
Richard Dobson wrote:
>
> Yes, it runs smooth as anything in linux, so it has to be a fault in
> VC++. One up to gcc!
>

-- 
Test your DAW with my Soundcard Attrition Page!
http://wkweb5.cableinet.co.uk/rwd (LU: 23rd August 1999)
CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 14th June 1999)



This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:28 EDT