[cc65] Re: CBM POSIX I/O w/o O_TRUNC ?

From: Oliver Schmidt <ol.sc1web.de>
Date: 2010-02-07 23:29:11

As there were no answers to my posting I presumed that everyting is
just as expected. However this doesn't seem to be the case at all...

> I want to change just the first few bytes of a longer file. From the
> POSIX docs (and my experience in other environments) learned that I
> can do so simply by omitting O_TRUNC (and O_CREAT) like this:
> int f = open("myfile", O_WRONLY);
> write(f, mybuffer, mysize);
> close(f);

1. As the code above didn't work I checked out the source code of the
CBM implementation of POSIX open(). It says:

; ... we cannot
; open a file for writing without creating it.
  cmp     #(O_WRONLY | O_CREAT)   ; Open for writing?
  bne     invflags        ; No: Invalid open mode

I didn't find any hint on this limitation the docs (if we don't
consider the source as THE docs) that O_WRONLY can't be used without
O_CREAT (and O_RDONLY can't be combined with O_WRONLY).

So changed the code above from

  int f = open("myfile", O_WRONLY);


  int f = open("myfile", O_WRONLY | O_CREAT);

2. Now the open() fails with error EEXIST. This surprised me very much
as O_EXCL wasn't set - and the POSIX spec seems to say that EEXIST is
only applicable with O_EXCL. Looking at the CBM open() code once more
I noticed that O_EXCL isn't checked at all - so I sort of assume that
the CBMs can in general only write to "new" files. If this should be
the case I don't understand two things:

a) Why doesn't the open() code require O_EXCL to be set in the same
way it requires O_CREAT to be set?

b) Why does the code check for O_TRUNC and O_APPEND if only "new"
files can be written?

In any case it would be great if there were some hints in the docs on
what the CBM implementation of the POSIX I/O calls can and what they

Thanks in advance for answers to my questions, Oliver
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Sun Feb 7 23:29:21 2010

This archive was generated by hypermail 2.1.8 : 2010-02-07 23:29:24 CET