Re: Writing own source disk

On 05/06/2024 20:26, Keith Thompson wrote:

scott@slp53.sl.home (Scott Lurndal) writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Mikko <mikko.levanto@iki.fi> writes:

On 2024-06-04 00:35:25 +0000, Keith Thompson said:

[...]

#embed is of course handled at compile time.  It's very likely, but
still not quite guaranteed, that `#embed __FILE__` will be able to
access the source file.

>
An operating system might refuse to open an already opened file.
There is no good reason to refuse when all accesses are for read-only
but a supid operating system might think otherwise.

>
That seems unlikely, and would be a concern only if some real-world OS
actually behaved that way.

>
IIRC windows has some restrictions on when a file can be opened vis
a vis other processes also having it open.
>
But I don't do windows and my recollection could be faulty.

 My understanding is that there can be one writer or multiple readers.

Yes.  It's more restrictive than on *nix systems (also on directory deletion or renaming), but it's not unreasonable.

That wouldn't affect `#embed __FILE__`.  Allowing only one reader would
break a *lot* of functionality.
 

The only realistic issues I could imagine with "#embed __FILE__" is the possibility of directory handling (i.e., if you compiled it as "cc xxx/yyy.c", would __FILE__ expand to "yyy.c" or "xxx/yyy.c", and would the correct file then be found?) or if your source was from a pipe or shell redirection.  "cat xxx.c > gcc -x c -", for example.