RE: Bug report: Compile with Microsoft and Intel compiler

[Jerker Bäck]

> > I have still not solved the file time macros. There is something wrong
> > there.
> I need to see the expansion of those macros to be able to help you
> figure it out.  Can you produce such an expansion (it should be a
> simple matter of invoking the compiler to produce a preprocessed
> source)?

Uh? This is a completely new thing for me. When trying this (switch /P) I
got .i files (ie file.i). I don't know if this will help:

extern unsigned long file_timestamp_cons (char const *, time_t, int);
extern unsigned long file_timestamp_now (int *);
extern void file_timestamp_sprintf (char *p, unsigned long ts);
extern unsigned long f_mtime (struct file *file, int search);

I can send you these files - OK?

> As I said earlier, I need to see the full prototypes of all these
> functions as they appear in the Microsoft headers.  Then I will write
> the Windows version of unistd.h and ask you to try that.
See new separate mail

> Are we sure there's no way of forcing MSC to set __STDC__ to a
> non-zero value without disabling the extensions?  Perhaps there's a
> compiler switch with that effect?
> If not, then I guess we will have to use your solution, although I'd
> like to avoid that.

No, I did that once when trying port e2fsprogs (for fixing errors on ext2
volumes inside NT). The whole thing went into a mess. I think MS did the
right thing to disable __STDC__. I mean, there is good reason for this
solution.

> > > No, no, no, the compiler is right here: this is actually a bug, we
> > > cannot use st.st_mtime without calling stat first.  Please try the
> > > following patch:
> Did you try that patch, and did it work?
Working on a new build

> We could do that, but you show _fdopen, not fdopen.  Are there
> prototypes for fdopen (without the leading underscore) as well, and if
> so, on what header?
Yes, <stdio.h> (B,MS)

> Okay, but then please change all the places where exit_code is used to
> unsigned long.
?? What do you mean?