On 09/25/11 02:30, Bruno Haible wrote:
> It's good and normal programming style to add 'inline' in front of
> all static functions that are only used once in the compilation unit.
This is not a style that I'm familiar with or comfortable with.
It reminds me of people putting "register" in front of
Paul Eggert wrote:
> >> * Why does dup2.c need to use 'inline'?...
> >
> > Do you know the optimizing behaviour of MSVC, or are you making assumptions?
>
> It's the other way around, no? If we don't know the optimizing
> behavior then we should omit "inline".
I disagree. It's good and normal
On 09/24/11 03:38, Bruno Haible wrote:
> But while doing so, we shouldn't throw the Autoconf principle overboard.
> This means, we have to exerce judgement about which bugs can possibly occur
> on other platforms as well, and let the fixes of Windows platforms also
> benefit the Unix platforms, wi
On 09/24/11 04:53, Bruno Haible wrote:
> the desire to minimize the number of files did not allow the code to be
> structured in a good way.
Yes, of course. Keeping the number of files small is just one
constraint among many, and is often overridden by other constraints.
> It is more important
Hi Paul,
> I briefly looked at the more recent changes you installed, and have
> some further comments and suggestions and a couple of patches.
>
> * Why two files, msvc-inval.h and msvc-nothrow.h?
> Would it be simpler to have just one file?
> Is it likely that a package would want one
Hi Paul,
Paul Eggert wrote:
> > Gnulib uses the "all workarounds for function foo() in file foo.c" approach
> > since the beginning, and has been working very well with that.
>
> I think this can work, but still, we should make it easy for
> non-Windows programmers to see which part of foo.c is f
On 09/19/11 14:15, Bruno Haible wrote:
> Gnulib uses the "all workarounds for function foo() in file foo.c" approach
> since the beginning, and has been working very well with that.
I think this can work, but still, we should make it easy for
non-Windows programmers to see which part of foo.c is f
Bastien ROUCARIES wrote:
> Moreover _get_osfhandle (fd) should be render safe globally. May be we
> should create a module ?
I think a separate .h file is best for this one.
This fixes a number of test suite failures.
2011-09-23 Bruno Haible
New module 'msvc-nothrow'. Makes _get_os
Paul Eggert wrote:
> > I'm not objecting to this MSVC stuff if it's put inside areas that are
> > "#ifdef _WIN32" or are otherwise clearly marked so that they are for
> > Windows only, and which the rest of us can safely ignore. But the
> > style used in dup2.c is cluttering code that is otherwise
> New module 'msvc-inval'.
> * lib/msvc-inval.h: New file.
> * lib/msvc-inval.c: New file.
There was still a compilation error, relating to EXCEPTION_EXECUTE_HANDLER and
EXCEPTION_CONTINUE_SEARCH. This fixes it:
2011-09-23 Bruno Haible
msvc-inval: Fix compilation er
Paul Eggert wrote:
> Emacs doesn't need to have a dummy msvc-inval.h file.
You're missing the point. I have explained that you can create a replacement
for this file in a single-line Makefile statement.
I want the module description to contain this:
Include:
#include "msvc-inval.h"
not this
Paul Eggert wrote:
> On 09/19/11 14:37, Bruno Haible wrote:
> > Is this code (with a #if and two extra functions) really easier to
> > understand
> > than what we have in lib/dup2.c now?
>
> I find it easier to understand, because I can safely ignore
> the stuff that's inside the "#if MSVC ..." b
Paul Eggert wrote:
> Emacs doesn't indent code properly when
> those macros are used. For example, if I put the cursor at the start
> of the next line and type TAB, Emacs indents the next line by two more
> than it should. If I put a semicolon after DONE_MSVC_INVAL, Emacs
> indents properly.
Ind
On 09/19/11 14:15, Bruno Haible wrote:
> I hope you can choose among these three solutions.
How about a 4th solution? It's modeled on your b.2)
c) You store no additional file in Emacs' VCS. Just one addition to
configure.ac or aclocal.m4:
AH_VERBATIM([
#define TRY_MSVC
On 09/19/2011 04:37 PM, Paul Eggert wrote:
For example, it's not reasonable to replace code like this:
return dup2 (a, b);
with code like this:
TRY_MSVC_INVAL
{
return dup2 (a, b);
}
CATCH_MSVC_INVAL
{
errno = EBADF;
return -1;
}
DONE_MSVC_I
On 09/19/11 14:37, Bruno Haible wrote:
> Is this code (with a #if and two extra functions) really easier to understand
> than what we have in lib/dup2.c now?
I find it easier to understand, because I can safely ignore
the stuff that's inside the "#if MSVC ..." brackets.
On 09/19/11 14:15, Bruno H
On 09/19/11 14:37, Bruno Haible wrote:
>DONE_MSVC_INVAL
>
> But what's the point of that semicolon?
I don't know what Bastien's point was, but one problem that I'm having
with those macros is that Emacs doesn't indent code properly when
those macros are used. For example, if I put the cursor
Bastien ROUCARIES wrote:
> why not
> #else
> # define TRY_MSVC_INVAL if (1)
> # define CATCH_MSVC_INVAL else do
> # define DONE_MSVC_INVAL while(0)
> #endif
This would be needed if we wanted the user to write
DONE_MSVC_INVAL;
instead of
DONE_MSVC_INVAL
But what's the point of that s
> The approach has the big advantage that you can step through the code in a
> debugger,
And that syntax coloring editors (like vim, emacs, kate) don't get confused.
> and that the entire block expands into a single statement.
I need to realize this promise:
2011-09-19 Bruno Haible
Hi Paul,
> I also have some qualms about C macros that expand to series of tokens
> with unbalanced braces.
The approach has the big advantage that you can step through the code in a
debugger, and that the entire block expands into a single statement.
(The original approach from gdb-7.2/gdb/excep
Hi Paul,
> This patch protects the dup2() calls in gnulib.
>
> ... I suspect there will be similar problems with printf, close, etc.
Yes, I suspect the idiom used in dup2.c will be used ca. 20 times in gnulib.
> I can't achieve this omission by invoking
> gnulib-tool --avoid=msvc-inval, becau
On Mon, Sep 19, 2011 at 7:34 AM, Paul Eggert wrote:
> On 09/18/11 01:36, Bruno Haible wrote:
>
> This patch protects the dup2() calls in gnulib.
>
> This change has some problems with GNU Emacs, and I suspect there will
> be similar problems with printf, close, etc. so let's try to get see
> if w
On 09/18/11 01:36, Bruno Haible wrote:
This patch protects the dup2() calls in gnulib.
This change has some problems with GNU Emacs, and I suspect there will
be similar problems with printf, close, etc. so let's try to get see
if we can fix these problems with dup2 first.
Emacs has a separate
> The newer runtime libraries of MSVC no longer return error codes from
> functions like printf(), close(), dup2(), _get_osfhandle(), when you pass
> an invalid format string or invalid file descriptor.[1][2]
>
> No, they invoke a so-called "invalid parameter handler" which exists once per
> proce
> The newer runtime libraries of MSVC no longer return error codes from
> functions like printf(), close(), dup2(), _get_osfhandle(), when you pass
> an invalid format string or invalid file descriptor.[1][2]
This patch protects the dup2() calls in gnulib.
2011-09-18 Bruno Haible
dup
The newer runtime libraries of MSVC no longer return error codes from
functions like printf(), close(), dup2(), _get_osfhandle(), when you pass
an invalid format string or invalid file descriptor.[1][2]
No, they invoke a so-called "invalid parameter handler" which exists once per
process (i.e. it'
26 matches
Mail list logo
