Re: [Hla-stdlib-talk] [aoaprogramming] Re: File Append issue

[Nathan B. <eve...@ya...>]

Frank Kotler <fbk...@co...> wrote:      <<SNIP>>
  > 
> I agreed to set-up the SourceForge site for the library -- didn't say
> that I would fix the code! ;-)

Okay. I didn't mean that you had to fix it personally. Just a potential 
item for discussion.

  NB - Yes, a good place to start.
  
  <<SNIP>>
  
Question is, what's the "best" way for hlalib to handle this? One option 
- the current situation, apparently - is to simply not implement it in 
Linux either. Another option would be to implement it in Linux, and in 
Windows, provide a "sorry, only available in Linux" message.
   
  NB - *I* do not like that option.
   
"fileio.copy" and "fileio.move" do this to Linux users (last time I 
looked).
   
  NB - I did not know that.
   
   The most "full-featured" way (is that "best"?) would be to add 
the functionallity to the Windows version, too. As you say, it's easy 
enough to do.

  NB -  Now, I *like* that.  Any other votes?
  
Beyond this particular issue, it's a philosophical question. I'm apt to 
claim that "portable" necessarily implies "lowest common denominator". 
But "open for append" - and the "copy" and "move" functions, going the 
other way - are cases where we could bring the less-featured interface 
up to match the more-featured interface. Is this what we ("we" being HLA 
users, not necessarily including me) want to do?

  NB - I leave that up to Randy and/or the folks who join the project.
  
Does hlalib propose to provide a routine for "everything in the world 
you could possibly imagine"? It's already far more than "the minimum set 
of routines needed for portability". Is there an identifiable 
stopping-point, beyond which another feature is "one too many"?

  NB - One can *never* have _too much_ of something!  ;-)
  
There's a discussion on a.l.a. about library routines, and whether they 
should be concerned about "security junk". The idea (in one camp) being 
that it's the caller's job to "protect" any unsafe library routine, and 
"security junk" doesn't belong in a library routine. Recent versions of 
gcc yell at ya if you use "gets()" (but not "sprintf()" which is just as 
bad). I'm not aware of any buffer overruns in the current code, and I 
assume we're not supposed to introduce any. There are more sophisticated 
security issues, too. Do we have/want/need a "specification" on that?

  NB - Well, if the library is widely used -- plus, since HLA is aimed at beginners -- I think it should have a modicum of security built-in.
  
Another issue that appears in that thread involves "side effects". Is it 
okay to alter the original command line in the course of parsing the 
command line, for example?

  NB - My vote is for not altering anything like that.  What if you've got another thread going and it wants to look at the command line too?  We want it to see the original also, don't we?
  
Just some possible topics for discussion... Personally I'm apt to just 
start coding and see what it turns out to be. I'm told that you can get 
better results by deciding what you intend to do *before* you start. 
Might be worth a try. :)

Best,
Frank

NB -  Thanks for the start!
   
  Nathan.
   

 		
---------------------------------
Do you Yahoo!?
 Get on board. You're invited to try the new Yahoo! Mail Beta.