Please fix it if you can. In my code I have resorted to forcing a delete of
these files before running again.

Original Message:
-----------------
From:  ramsdell@mitre.org (John D. Ramsdell)
Date: 30 Sep 2003 09:45:15 -0400
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:3101] Read-only files in Windows


I notice that wxCSound generates read-only files on Windows.  It uses
the CSound API, and the generated files seem to be opened in
filopen.c.  Does anyone have a patch for this problem?  I hesitate to
jump in as I found the following comment in filopen.c at line number
109:

/**
* Changed file permissions so that re-entrant versions of Csound
* can overwrite files without need for manual deletion.
* Still doesn't seem to work...
*/

John


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

"gogins@pipeline.com"  writes:

> Please fix it if you can. In my code I have resorted to forcing a
> delete of these files before running again.

I can't stand the way things are, so I'll patch this soon if I hear
nothing from anyone else.  The odd thing is the code I would expect to
see would use

    int open(const char *pathname, int flags, mode_t mode);

with 

    flags = O_CREAT|O_WRONLY|O_TRUNC

and 
    
    mode = S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH,

but some of the calls to open in the file filopen.c omit the third
argument.  Curious.  Are there platforms that do not support the three
argument version of open?  What is the story with the following set of
machines?

    defined(mac_classic) || defined(SYMANTEC) || defined(WIN32)

My IEEE POSIX Std 1003.1-1988 book states clearly that when flags
contains O_CREAT, open is required to be used in the three argument
form. 

John

My version of 4.23 Winsound doesn't create read-only files. I have no 
idea at this distance if I hacked anything.

These are all low-level calls, and not part of ANSCI C as such (POSIX is 
a quite different beast, and relatively little of Windows, at least, is 
POSIX compliant, so I hear); so they do tend to exhibit greater or 
lesser differences across platforms. In a unix system, the third 
argument enables the programmer to set permissions acording to the 
standard ownership flags (rwx * owner/group/others). Windows just offers 
a single global read/write permission. As you rightly say, it is 
required only with _O_CREAT. The ifdefs are supposed to ensure the right 
combination is used, including the third arg.

My guess is that something is amiss with the mass of preprocessor ifdefs.

That said, the symbol MSVC (duuno where that came from! :-) )
needs to be replaced with _MSC_VER, which is the standard ID for Visual 
C++.

Richard Dobson





John D. Ramsdell wrote:
> "gogins@pipeline.com"  writes:
> 
> 
>>Please fix it if you can. In my code I have resorted to forcing a
>>delete of these files before running again.
> 
> 
> I can't stand the way things are, so I'll patch this soon if I hear
> nothing from anyone else.  The odd thing is the code I would expect to
> see would use
> 
>     int open(const char *pathname, int flags, mode_t mode);
> 
> with 
> 
>     flags = O_CREAT|O_WRONLY|O_TRUNC
> 
> and 
>     
>     mode = S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH,
> 
> but some of the calls to open in the file filopen.c omit the third
> argument.  Curious.  Are there platforms that do not support the three
> argument version of open?  What is the story with the following set of
> machines?
> 
>     defined(mac_classic) || defined(SYMANTEC) || defined(WIN32)
> 
> My IEEE POSIX Std 1003.1-1988 book states clearly that when flags
> contains O_CREAT, open is required to be used in the three argument
> form. 
> 
> John
> 
> 

I think the explanation for the filopen.c code for compilations
satisfying

   defined(mac_classic) || defined(SYMANTEC) || defined(WIN32)

is simply someone misunderstood the macros, and erroneously dropped
the mode specifier for that case.  You may have noticed that Java
provides no preprocessor, and C++ provides features that greatly
reduce the need for a preprocessor.  I think this is an example of why
language designers are moving away from preprocessors.  Another
example is mididevice.c.  Who knows what that code does?

In any event, after testing, I patched the sources in the csound
module as follows:

sh-2.05b$ ../sfcvs diff -u
ramsdell@cvs.csound.sourceforge.net's password:

cvs server: Diffing .
Index: cs.h
===================================================================
RCS file: /cvsroot/csound/csound/cs.h,v
retrieving revision 1.3
diff -u -r1.3 cs.h
--- cs.h	18 Sep 2003 14:43:20 -0000	1.3
+++ cs.h	1 Oct 2003 10:08:30 -0000
@@ -838,7 +838,7 @@
 #endif
 
 #include "prototyp.h"
-#ifdef FLTK_GUI
+#if defined FLTK_GUI || defined WX_GUI
 #define printf csoundMessage0
 extern void csoundMessage0(const char *, ...);
 extern void err_printf(char *, ...);
Index: filopen.c
===================================================================
RCS file: /cvsroot/csound/csound/filopen.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 filopen.c
--- filopen.c	30 May 2003 14:28:21 -0000	1.1.1.1
+++ filopen.c	1 Oct 2003 10:08:30 -0000
@@ -119,7 +119,7 @@
 #endif
 #elif defined(mac_classic) || defined(SYMANTEC) || defined(WIN32)
 #define RD_OPTS  O_RDONLY | O_BINARY
-#define WR_OPTS  O_TRUNC | O_CREAT | O_WRONLY | O_BINARY
+#define WR_OPTS  O_TRUNC | O_CREAT | O_WRONLY | O_BINARY, 0644
 #elif defined DOSGCC
 #define RD_OPTS  O_RDONLY | O_BINARY, 0
 #define WR_OPTS  O_TRUNC | O_CREAT | O_WRONLY | O_BINARY, 0644
Index: mididevice.c
===================================================================
RCS file: /cvsroot/csound/csound/mididevice.c,v
retrieving revision 1.4
diff -u -r1.4 mididevice.c
--- mididevice.c	2 Sep 2003 13:09:33 -0000	1.4
+++ mididevice.c	1 Oct 2003 10:08:30 -0000
@@ -109,7 +109,7 @@
      static port_id gMidiInPort = B_ERROR;
 #elif defined(mac_classic)
 
-#elif !defined(DOSGCC) && !defined(__WATCOMC__)&& !defined(LATTICE) && !defined(WIN32) && !defined(SYMANTEC) && !defined(__EMX__)
+#elif !defined(DOSGCC) && !defined(__WATCOMC__)&& !defined(LATTICE) && !defined(WIN32) && !defined(SYMANTEC) && !defined(__EMX__) && !defined(LOSE_MIDI_TTY)
 #    if defined(__MACH__)
 #      define USE_OLD_TTY 1
 #    endif
@@ -386,7 +386,7 @@
           }
       }
 # endif /* HAVE_BSD_SGTTY_H */
-#elif !defined(__BEOS__) && !defined(mac_classic)
+#elif !defined(__BEOS__) && !defined(mac_classic) && !defined(LOSE_MIDI_TTY)
 # if !defined(DOSGCC) && !defined(__WATCOMC__) && !defined(LATTICE) && !defined(WIN32) && !defined(__EMX__)
       ioctl(rtfd, TIOCGETP, &tty);           /* for other machines      */
       tty.sg_ispeed = INBAUD;                /*   set baud rate         */
cvs server: Diffing CsoundVST
cvs server: Diffing CsoundVSTWin
cvs server: Diffing OSC-Kit
cvs server: Diffing OSC-Kit/send+dump
cvs server: Diffing anal
cvs server: Diffing anal/adsyn
cvs server: Diffing anal/convol
cvs server: Diffing anal/lpc
cvs server: Diffing anal/pvoc
cvs server: Diffing cscofils
cvs server: Diffing pyrun
cvs server: Diffing util1
cvs server: Diffing util1/cscore
cvs server: Diffing util1/scot
cvs server: Diffing util1/sortex
cvs server: Diffing util2
cvs server: Diffing util2/dnoise.dir
cvs server: Diffing util2/envext
cvs server: Diffing util2/exports
cvs server: Diffing util2/mixer
cvs server: Diffing util2/mkgraph
cvs server: Diffing util2/pvlook.dir
cvs server: Diffing util2/scale.dir
cvs server: Diffing util2/sndinfo
sh-2.05b$

Richard Dobson  writes:

> My version of 4.23 Winsound doesn't create read-only files. I have no
> idea at this distance if I hacked anything.

Winsound is compiled with preprosessor settings that avoid this
problem.

John

Bad John.  I just noticed the existence of the file ChangeLog that I
have failed to use.  I've added notes describing the accumulation of
the changes I've made so far, with the exception of eliminating stray
carriage returns in fgens.c and dnoise.c.

2003-10-01  John D. Ramsdell  

	* filopen.c (WR_OPTS): Added mode for file open for compilations
	that satisfy defined(mac_classic) || defined(SYMANTEC) ||
	defined(WIN32).

	* cs.h: Added preprocessor symbol USE_CSOUND_YIELD, which when
	defined, defines POLL_EVENTS as csoundYield.  Also added
	preprocessor symbol WX_GUI, which when defined, defines printf to
	be csoundMessage0 as does FLTK_GUI.

	* mididevice.c (OpenMIDIDevice): Added preprocessor symbol
	LOSE_MIDI_TTY, which when defined, ensures no tty is declared.

	* load_opcodes.c: Added preprocessor symbol LOSE_LOAD_LIBRARY,
	which when defined, adds stubs for csoundOpenLibrary,
	csoundCloseLibrary, and csoundGetLibrarySymbol.

John

Thee macros are not used where a C or C++ construction would be better 
from a purist programming-aesthetic point of view, they are there to 
deal with cross-platform and cross-compiler differences, which is an 
entirely different problem. The only alternative is to  use alternative 
versions of the same file, for different platforms and different 
compilers. We already do this in some cases - for graphics and audio 
support, for example, and can probably do more, as you hint (e.g dump 
mididevice.c and move to PortMidi); but where the differences are 
relativly slight, it seems preferable to have just the one file, with a 
few #ifdefs, than multiple versions of the same file, with only a few 
differences between them. In the  majority of cases, we don't need to 
modify the preprocessor-dependent code, but only the common code.

Richard Dobson


John D. Ramsdell wrote:
>>...   You may have noticed that Java
> provides no preprocessor, and C++ provides features that greatly
> reduce the need for a preprocessor.  I think this is an example of why
> language designers are moving away from preprocessors.  Another
> example is mididevice.c.  Who knows what that code does?
> 

Richard Dobson  writes:

> Thee macros are not used where a C or C++ construction would be better
> from a purist programming-aesthetic point of view, ...

Just to be clear, I was not advocating a change to the sources.  I was
pointing out that the use of #define obscured the bug I corrected,
which was also not detected by the compiler.  These kinds of problems
have motivated programming language designers to abandon
preprocessors.  For C, and C++, we're stuck with them.

John