On Thursday, October 26, 2000 1:26 AM, Guido Gonzato [SMTP:[EMAIL PROTECTED]]
wrote:
> er... it won't compile with gcc without changes... you forgot to add
#ifdef
> _MSVC to all sources but abc2ps.c.
Hmmm, don't know how I missed all those the first time I searched for
"process.h" -- must have had a typo in the search string. Interesting that
GCC for Cygwin didn't catch it even with the -Wall flag. I don't really
trust windoze ports of unix stuff, I guess I'm going to have to look into
building a Linux box again.
> No real problem tho. Another little thing
> that ought to be fixed is the "gets" thing, which really makes gcc angry.
> From the gets(3) man page:
>
> Never use gets(). Because it is impossible to tell with-
> out knowing the data in advance how many characters gets()
> will read, and because gets() will continue to store char-
> acters past the end of the buffer, it is extremely danger-
> ous to use. It has been used to break computer security.
> Use fgets() instead.
This is one of those cases where you have to really understand what's going
on, rather than slavishly follow well-meant but not necessarily "good"
advice from whoever wrote the man page. Yes, gets() can be misused, but
that doesn't mean it should *never* be used.
gets() is only used in one place (in the original abc2ps code, at that).
Where it is used is in the interactive function and it is used to get user
input to select tunes. The buffer is 500+ characters, and it's *highly*
unlikely that the user is going to enter more characters than that. If
they should, the only thing that will happen is that the program will
crash. The only time there would be a security problem is if gets() was
being used in a login process or other security-sensitive code. Even then,
any security problem is really in the underlying operating system and not
in the application. Any operating system that allows access beyond a
user's permissions just because a program crashed has a SERIOUS security
problem but it's NOT the fault of the application that crashed! In other
words, gets() in this instance has a slim chance of causing a problem, and
any problem that it does cause is not a security concern. I suspect that
the security problem mentioned in the man page is probably a carry over
from very early unix systems that were riddled with security issues.
Most importantly, changing this to scanf is NOT acceptable in this instance
[I seem to recall your mentioning you'd replaced gets() with scanf() in a
previous post]. Scanf stops reading a string on whitespace, and in this
instance we want to read to the end of a line, allowing the user to select
multiple tunes using whitespace delimiters. Michael designed this function
so that it cleverly uses the command-line parsing code to interpret the
user input in interactive mode.
How about following the man page advice and using fgets()? Well, that can
be made to work but it unnecessarily complicates the code. gets() strips
the trailing newline, while fgets() doesn't. (Thanks K&R. See, Bill
Gate's boys weren't the first to introduce oddball inconsistencies
seemingly intended solely to trip up programmers!) That means that if we
switch to fgets() we also have to provide additional code to detect and
strip a newline character, and that may be further complicated if we want
to ensure cross-platform compatibility. So, put simply, in this case I
think gets() is the best solution, which is probably why Michael used it to
begin with.
I did add some comments to the code, explaining the above.
> > I implemented M:none. You have the choice of having M:none display
"none,"
> > "free," "free" over "meter," or "fm." I have no formal music training
--
> > if there is something else that really should be displayed let me know
and
> > I'll add an option for it.
>
> another option should be simply not to display a thing; it shouldn't be
hard
> to implement...
Actually, it's very easy and I initally set this up to do just that. Then
I realized that there were two problems. First, no time signature
generally means 4/4 time, at least in all the music books I have. Second,
it would certainly be a problem in the case of meters that change in the
middle of a tune. If you're changing from some meter to free meter in the
middle of a tune you have to print *something*, right?
I can offer it as an option though. Next time I upload the code
&&FreeMetStyle 4 will cause it to output nothing. It'll be up to the user
to use that option intelligently, though ;-)
John Atchley
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
