At 20:39 28.07.03 +0200, Sven Neumann wrote:

Hi,

you've added a new file gimpwin32-io.h. Seems like a good idea but I'm not sure if this header is supposed to be installed or not.

I'm uncertain if it really should be installed or not, especially as nothing gets installed when I compile The Gimp or any plug-ins ...

Though I'd rather like this header not be used (necessary) at all but it appeared to be better than just copy an pasting some missing defines once more. But it seemed there was something I don't understand :

2003-07-27 Henrik Brix Andersen

* app/base/tile-swap.c: re-added fallback definitions for _O_BINARY and _O_TEMPORARY

Are there other platforms which do miss these defines? Which one? [If there are and the header should nake up some general lossage it definitely should _not_ be called gimpwin32-io.h.]

I definitely don't want it to be installed on win32 only. For now I did the following changes to clean up your commit:

2003-07-28 Sven Neumann

* libgimpbase/Makefile.am (EXTRA_HEADERS): added gimpwin32-io.h.

I still don't understand of enough automake, just guessing EXTRA_HEADERS =? install it (in /usr/include or prefix) EXTRA_DIST =? have it in the tar file (where it definitely should be to keep the source compileable cros platform.

* libgimpbase/gimpdatafiles.c: properly include the new header.

However I feel that since you are using the header from a plug-in, it seems like it's generally useful and should probably be installed so it can be used from third-party plug-ins as well. Perhaps the file should even be included from libgimpbase.h ?

Having it to be in libgimbase.h looks wrong to me cause it is wrapping win32 system headers which probably should not be included everywhere : "Don't include headers in headers ..."

Hans

-------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert

On Tue, 2003-07-29 at 00:30, Hans Breuer wrote:

2003-07-27 Henrik Brix Andersen

* app/base/tile-swap.c: re-added fallback definitions for _O_BINARY and _O_TEMPORARY

Are there other platforms which do miss these defines? Which one? [If there are and the header should nake up some general lossage it definitely should _not_ be called gimpwin32-io.h.]

Removing the fallback definitions broke compilation on at least one platform, namely GNU/Linux which doesn't define _O_BINARY and/or _O_TEMPORARY. Most likely other unix-like platforms where affected as well.

Simon Budig digged a bit in the archives of gimp-developer and came up with the following URL:

http://lists.xcf.berkeley.edu/lists/gimp-developer/1999-September/000013.html

Hopefully the above link clarifies things a bit, else we may need Tor to explain why the extra flags are needed for the call to open() on win32.

Sincerely, ./Brix

Henrik Brix Andersen writes:
> Removing the fallback definitions broke compilation on at least one > platform, namely GNU/Linux which doesn't define _O_BINARY and/or > _O_TEMPORARY. Most likely other unix-like platforms where affected as > well.

Since Unix systems don't distinguish between "binary" and "text" modes for file I/O, there is no O_BINARY (or _O_BINARY) on them. As for O_TEMPORARY that isn't needed either, as the traditional, elegant, Unix method is to unlink the temporary file while still keeping it open.

(And even if the functionality of those flags was needed on Unix, the names wouldn't have the leading underscore. It is a bit strange by Microsoft (well, what isn't...) to hide all the Unixish stuff they provide in their C library with a leading underscore, purportedly in order not to pollute the ANSI C namespace. As I see it, if you include non-ANSI headers like (or on Unix) in your code, you accept not to have a clean ANSI C namespace any longer. And, most traditional Windows programs include anyway, which pollutes the namespace like a 300 kg gorilla, with apparently no restriction at all on on what kind of identifiers it introduces.)

--tml