Re: [Hla-stdlib-talk] [aoaprogramming] Re: File Append issue
Brought to you by:
evenbit
From: Nathan B. <eve...@ya...> - 2006-06-26 04:19:50
|
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. |