[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Cvs-cvs] Changes to ccvs/windows-NT/filesubr.c
From: |
Conrad T. Pino |
Subject: |
RE: [Cvs-cvs] Changes to ccvs/windows-NT/filesubr.c |
Date: |
Wed, 21 Sep 2005 12:17:27 -0700 |
Hi Derek,
> From: Derek Price
>
> Conrad T. Pino wrote:
>
> >H:\cvs-1.12>grep -dn TMPDIR_ENV *.h
> >File src\cvs.h:
> >258 #define TMPDIR_ENV "TMPDIR" /* Temporary directory */
> >
> >That's not a value ever likely to be defined on Windows. IMO the Windows
> >value should be "TMP" given the Win32 API documentation we've seen.
>
> That's why I suggested the wrapper function lookup TMPDIR_ENV on UNIX
> and call the Windows gettemppath() function on Windows.
>
> src/filesubr.c:
>
> char *get_system_temp_dir (void)
> {
> return xstrdup (getenv (TEMPDIR_ENV));
> }
>
> windows-NT/filesubr.c:
>
> char *get_system_temp_dir (void)
> {
> return xstrdup (gettemppath());
> }
>
> Then, replace the call to getenv in main.c with a call to
> get_system_temp_dir.
Thank you. How about calling it "cvs_system_temp_dir" instead?
> >This looks pretty easy except Microsoft's "mkdir" has only 1 argument
> >and we pick up another "mbsinit" linker error from another module.
> >See below for compiler output.
>
> What about a rpl_mkdir wrapper in windows-NT/filesubr.c like:
>
> #undef mkdir
> extern int mkdir (const char *pathname); /* or include Windows header
> with mkdir decl */
> int rpl_mkdir (const char *pathname, mode_t mode)
> {
> mkdir (pathname);
> /* chmod (pathname)? */
> }
The ability to "#define mkdir rpl_mkdir" requires either "mkdir"
does not exist OR have no prototype OR "mkdir" and "rpl_mkdir" have
the same arguments. Neither is true in this case.
We already have "wnt_mkdir" found in "windows-NT/mkdir.c" file and
it's prototype is in "windows-NT/config.h" file.
Microsoft prototypes "mkdir" in <direct.h> which is included from
"lib/system.h" (#if HAVE_DIRECT_H) and "windows-NT/unistd.h" file.
Doing "#define mkdir wnt_mkdir" creates a conflict because macro
substitution occurs during <direct.h> processing and the compiler
sees multiple "wnt_mkdir" prototypes with differing arguments.
I've tested "#undef HAVE_DIRECT_H" versus "#define HAVE_DIRECT_H 1"
and there's no difference in warnings nor errors. That being so we
might avoid errors because "lib/system.h" doesn't process <direct.h>
file.
Then inside "windows-NT/unistd.h" we could try:
#ifdef something
#error something already defined!
#endif
#ifdef mkdir
#define something mkdir
#undef mkdir
#endif
#include <direct.h>
#ifdef something
#define mkdir something
#undef something
#endif
The alternative is dropping "#include <direct.h>" and hand writing
prototypes which we've discusssed and rejected before.
> >I checked for "fdopen" function and VC6 has one.
> >
> >Should "cvs_temp_file" stay in the "filesubr.c" module?
>
> Not if you can use lib/mkstemp.c. If you can, I think we should be able
> to move cvs_temp_file into src/subr.c and share it.
IMO we're close to compiling "lib/mkstemp.c" and "lib/tempname.c" files.
> Regards,
Ditto,
> Derek
Conrad
- Re: [Cvs-cvs] Changes to ccvs/windows-NT/filesubr.c, Derek Price, 2005/09/20
- RE: [Cvs-cvs] Changes to ccvs/windows-NT/filesubr.c, Conrad T. Pino, 2005/09/20
- Re: [Cvs-cvs] Changes to ccvs/windows-NT/filesubr.c, Derek Price, 2005/09/20
- RE: [Cvs-cvs] Changes to ccvs/windows-NT/filesubr.c, Conrad T. Pino, 2005/09/20
- Re: [Cvs-cvs] Changes to ccvs/windows-NT/filesubr.c, Derek Price, 2005/09/20
- RE: [Cvs-cvs] Changes to ccvs/windows-NT/filesubr.c,
Conrad T. Pino <=
- Re: [Cvs-cvs] Changes to ccvs/windows-NT/filesubr.c, Derek Price, 2005/09/21
- RE: [Cvs-cvs] Changes to ccvs/windows-NT/filesubr.c, Conrad T. Pino, 2005/09/22
- Re: [Cvs-cvs] Changes to ccvs/windows-NT/filesubr.c, Derek Price, 2005/09/22