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

[Frank K. <fbk...@co...>]

evenbitnb wrote:
> --- In aoa...@ya..., Frank Kotler <fbkotler@...> wrote:
> 
>>Randall Hyde wrote:
>>
>>>I take it you're programming under Windows. "a" is defined only in
> 
> Unix, 
> 
>>>apparently:
>>> 
>>>#if( @global:os.win32 )
>>>
>>> const
>>>  r := $8000_0000; // Open file for reading.
>>>  w := $4000_0000; // Open file for writing.
>>>  rw := r | w;  // Open file for reading and writing.
>>>   
>>>#elseif( @global:os.linux )
>>> const
>>>   r := 0;    // Open file for reading.
>>>   w := 1;    // Open file for writing.
>>>   rw := 2;    // Open file for reading and writing.
>>>   a := 3;    // Open file for append (write)
>>>
>>>#endif
>>
>>Implemented anywhere? I'm looking at fileio/fopen.hla...
>>
> 
>   {{SNIP}}
> 
>>Nathan! Nathan! We may have a live one! :)
>>
> 
> 
> 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.

> Don't know about appending a file on Linux, but for Windows, IIRC, it
> depends on a parameter that you pass to CreateFile.  One way, if it
> sees the file already exists, then it gives you an error; the other
> way, it opens the file... probably just adjust the current position to
> the end of the file to make sure that anything written gets appended.

To be honest, I didn't realize that "O_APPEND" existed on Linux until I 
read this question - but it does...

On my old 8-bit Atari, "open for append" was an option. In dos, and 
apparently 'doze, no. We have to open the file, and then seek to the end 
of it. I imagine that's exactly what "O_APPEND" does, somewhere in the 
bowels of the kernel code. Just a "convenience function" that Linux 
provides... and Windows doesn't(?). Usually it's the other way around.

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. 
"fileio.copy" and "fileio.move" do this to Linux users (last time I 
looked). 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.

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?

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"?

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?

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?

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