USE_LSB_TAG and MS-DOS

USE_LSB_TAG and MS-DOS

[Eli Zaretskii]

For whom it may concern: I've checked in a change to lisp.h that
disables the use of USE_LSB_TAG in the MS-DOS port.  USE_LSB_TAG was
turned on by a recent change in lisp.h because the MS-DOS build uses
the GNU malloc and GCC, but that caused temacs to crash with SIGABRT
during loadup when it performed the first GC.

If Stefan, or someone else who understand the intricacies of
USE_LSB_TAG and what it demands from the underlying platform, wishes
to help me debug this, in the hope that we will learn something
interesting about other platforms where USE_LSB_TAG could fail, I'll
be glad to dig deeper into the reasons for the crash.  Otherwise, I
don't have resources to debug this myself, and I don't see any
catastrophe to leave the MS-DOS port with the 256-MB max buffer size.
(FWIW, I suspect that stack alignment has something to do with the
crash, but I didn't look into this deep enough to be sure.)

Btw, the way DECL_ALIGN and USE_LSB_TAG are defined on lisp.h doesn't
leave any elegant way for specific platforms to turn that off without
cluttering lisp.h with ugly OS-specific #ifdef's.  Perhaps we should
devise a cleaner way.

Re: USE_LSB_TAG and MS-DOS

[Jason Rumney]

"Eli Zaretskii" <eliz@gnu.org> writes:

> For whom it may concern: I've checked in a change to lisp.h that
> disables the use of USE_LSB_TAG in the MS-DOS port.  USE_LSB_TAG was
> turned on by a recent change in lisp.h because the MS-DOS build uses
> the GNU malloc and GCC, but that caused temacs to crash with SIGABRT
> during loadup when it performed the first GC.

The Windows build was also crashing there, but I didn't think it used
GNU malloc, so I wasn't expecting Stefan's code to be enabled.

> Btw, the way DECL_ALIGN and USE_LSB_TAG are defined on lisp.h doesn't
> leave any elegant way for specific platforms to turn that off without
> cluttering lisp.h with ugly OS-specific #ifdef's.  Perhaps we should
> devise a cleaner way.

Definitely, if we cannot fix the problems on those plaforms.

Re: USE_LSB_TAG and MS-DOS

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Date: Sat, 15 May 2004 16:10:46 +0100
> 
> The Windows build was also crashing there, but I didn't think it used
> GNU malloc

Didn't think earlier, or still don't think?  (I presume the former,
since nt/config.nt does define GNU_MALLOC.)

> so I wasn't expecting Stefan's code to be enabled.

I guess a MinGW build would enable it, as it uses GCC.

Re: USE_LSB_TAG and MS-DOS

[Jason Rumney]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> From: Jason Rumney <jasonr@gnu.org>
>> Date: Sat, 15 May 2004 16:10:46 +0100
>> 
>> The Windows build was also crashing there, but I didn't think it used
>> GNU malloc
>
> Didn't think earlier, or still don't think?  (I presume the former,
> since nt/config.nt does define GNU_MALLOC.)

I hadn't had time to check it :-)

It turns out my problems were caused by the fact that none of the C
files depend on lisp.h, so I had a mix of USE_LSB_TAG and old.

After make clean, I run into other compilation problems in w32heap.c
and w32proc.c due to VALMASK no longer being defined, but if I
temporarily comment those lines out, compilation and dumping
succeeds, but when running Emacs I end up with a hideous yellow
background and a black background for the toolbar, so something is
still not right.

Re: USE_LSB_TAG and MS-DOS

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 17 May 2004 09:13:43 +0100, Jason Rumney <jasonr@gnu.org> said:

> but when running Emacs I end up with a hideous yellow background and
> a black background for the toolbar, so something is still not right.

I've encountered a similar situation when I was porting image support
to Mac (cyan background instead of yellow one).  That is because there
is a mixup of Lisp_Object and another type in a color lookup function.

  x_to_w32_color is defined as:

    COLORREF
    x_to_w32_color (colorname)

  But in w32_defined_color:
    register Lisp_Object tem;

    tem = x_to_w32_color (color);

Maybe you will find such cases by specifying -DUSE_LISP_UNION_TYPE in
compilation.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: USE_LSB_TAG and MS-DOS

[Jason Rumney]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> Maybe you will find such cases by specifying -DUSE_LISP_UNION_TYPE in
> compilation.

Thanks for the tip. I uncovered dozens of such bugs, and now I am
seeing normal colors again.

Re: USE_LSB_TAG and MS-DOS

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Date: Mon, 17 May 2004 09:13:43 +0100
> 
> It turns out my problems were caused by the fact that none of the C
> files depend on lisp.h, so I had a mix of USE_LSB_TAG and old.

Yes, a known problem; I hit that at first as well.

> After make clean, I run into other compilation problems in w32heap.c
> and w32proc.c due to VALMASK no longer being defined, but if I
> temporarily comment those lines out, compilation and dumping
> succeeds, but when running Emacs I end up with a hideous yellow
> background and a black background for the toolbar, so something is
> still not right.

Is this in a MinGW build or MSVC build?

Re: USE_LSB_TAG and MS-DOS

[Jason Rumney]

Eli Zaretskii wrote:

> Is this in a MinGW build or MSVC build?

MinGW. MSVC definitely shouldn't have the new code enabled, as it uses 
GCC specific extensions.

Re: USE_LSB_TAG and MS-DOS

[Stefan Monnier]

> For whom it may concern: I've checked in a change to lisp.h that
> disables the use of USE_LSB_TAG in the MS-DOS port.  USE_LSB_TAG was
> turned on by a recent change in lisp.h because the MS-DOS build uses
> the GNU malloc and GCC, but that caused temacs to crash with SIGABRT
> during loadup when it performed the first GC.

Can you compile with ENABLE_CHECKING and try again?
And give me a backtrace?

> Btw, the way DECL_ALIGN and USE_LSB_TAG are defined on lisp.h doesn't
> leave any elegant way for specific platforms to turn that off without
> cluttering lisp.h with ugly OS-specific #ifdef's.  Perhaps we should
> devise a cleaner way.

It was devised in the hope that it will only be turned on where it's safe.
Obviously, that's not the way it works, but at least it *should* work that
way, so I think we're just hitting a bug.
After all, all we need is to make sure pointers are multiples of 8.
GNU malloc guarantees that AFAIK for malloced objects and DECL_ALIGN allows
to get the same guarantee for static objects, so if we have both the only
reasonf ro USE_LSB_TAG to fail is a bug, right?


        Stefan

Re: USE_LSB_TAG and MS-DOS

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: 16 May 2004 19:40:23 -0400
> 
> Can you compile with ENABLE_CHECKING and try again?
> And give me a backtrace?

Will try to do that soon.

By ``backtrace'' you meant a C-level backtrace inside GDB, yes?

> After all, all we need is to make sure pointers are multiples of 8.
> GNU malloc guarantees that AFAIK for malloced objects and DECL_ALIGN allows
> to get the same guarantee for static objects, so if we have both the only
> reasonf ro USE_LSB_TAG to fail is a bug, right?

Perhaps so, but, being unsure I know enough about the alignment
issues, I bother.  For example, is stack alignment an issue?  And what
about the default alignment used by GCC for code and data?  I also
need to check whether the __attribute__((__align__)) thingy is
supported and does TRT in the DJGPP (a.k.a. MS-DOS) port of GCC.

There was also talk about using memalign.  I didn't follow that thread
closely, so I don't remember: is that relevant in any way to the case
in point?

Re: USE_LSB_TAG and MS-DOS

[Stefan Monnier]

>> Can you compile with ENABLE_CHECKING and try again?
>> And give me a backtrace?

> Will try to do that soon.
> By ``backtrace'' you meant a C-level backtrace inside GDB, yes?

Yes.

>> After all, all we need is to make sure pointers are multiples of 8.
>> GNU malloc guarantees that AFAIK for malloced objects and DECL_ALIGN allows
>> to get the same guarantee for static objects, so if we have both the only
>> reasonf ro USE_LSB_TAG to fail is a bug, right?
> Perhaps so, but, being unsure I know enough about the alignment
> issues, I bother.  For example, is stack alignment an issue?

It shouldn't.  The only places where I change the alignemnt are where I use
DECL_ALIGN and in pure_alloc.  In both cases the alignment should be
increased ather than decreased, so it shouldn't cause any problem.
Barring any bug, that is (of course).

> And what about the default alignment used by GCC for code and data?
> I also need to check whether the __attribute__((__align__)) thingy is
> supported and does TRT in the DJGPP (a.k.a. MS-DOS) port of GCC.

ENABLE_CHECKING should give you those answers pretty quickly since it
checks that pointers are properly aligned before tagging them to make
Lisp_Objects.

> There was also talk about using memalign.  I didn't follow that thread
> closely, so I don't remember: is that relevant in any way to the case
> in point?

No, the code is currently not using memalign.  The use of memalign would
only be for cases where malloc is not known to return
multiple-of-8 pointers.


        Stefan

Re: USE_LSB_TAG and MS-DOS

[Miles Bader]

On Mon, May 17, 2004 at 12:22:15PM -0400, Stefan Monnier wrote:
> No, the code is currently not using memalign.  The use of memalign would
> only be for cases where malloc is not known to return
> multiple-of-8 pointers.

We should be very careful though -- because historically things like memalign
were implemented as dumb wrappers around malloc, they can behave very badly;
here's what the GNU Libc manual says:

      With the GNU library, you can use `free' to free the blocks that
   `memalign', `posix_memalign', and `valloc' return.  That does not work
   in BSD, however--BSD does not provide any way to free such blocks.

I think memalign should only be used for specific system types where we know
it's implemented in a reasonable manner.

-Miles
-- 
We have met the enemy, and he is us.  -- Pogo

Re: USE_LSB_TAG and MS-DOS

[Stefan Monnier]

> We should be very careful though -- because historically things like memalign
> were implemented as dumb wrappers around malloc, they can behave very badly;
> here's what the GNU Libc manual says:

As I said, the code doesn't use memalign.
Also by `memalign' I actually mean `posix_memalign' which has no known
broken implementation (but is recent and only part of a non-core element of
POSIX, so it's missing from several systems).
We already use `posix_memalign' actually, when available, to get the
multiple-of-1024 alignment used for cons_blocks (I introduced this when
I got rid of the markbit).


        Stefan

Re: USE_LSB_TAG and MS-DOS

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: 17 May 2004 12:22:15 -0400
> 
> >> Can you compile with ENABLE_CHECKING and try again?
> >> And give me a backtrace?
> 
> > Will try to do that soon.
> > By ``backtrace'' you meant a C-level backtrace inside GDB, yes?
> 
> Yes.

I found the villain: dos-unsupported-char-glyph was being initialized
with a literal numerical value instead of going thru make_number.

Thanks for your support.

Btw, is pure[] usage supposed to go up when USE_LSB_TAG is in effect?
AFAICS, it went from 977KB to 1019KB with almost no changes in Lisp
files since the previous build.

Re: USE_LSB_TAG and MS-DOS

[Andreas Schwab]

"Eli Zaretskii" <eliz@gnu.org> writes:

> Btw, is pure[] usage supposed to go up when USE_LSB_TAG is in effect?
> AFAICS, it went from 977KB to 1019KB with almost no changes in Lisp
> files since the previous build.

Could be due to the increased alignment requirements on 32 bit platforms,
although the difference looks a bit high.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: USE_LSB_TAG and MS-DOS

[Stefan Monnier]

> I found the villain: dos-unsupported-char-glyph was being initialized
> with a literal numerical value instead of going thru make_number.

>From the ChangeLog text it seems that cmpiling with USE_LISP_UNION_TYPE
would have caught that eons ago.

> Btw, is pure[] usage supposed to go up when USE_LSB_TAG is in effect?
> AFAICS, it went from 977KB to 1019KB with almost no changes in Lisp
> files since the previous build.

There is likely to be an increase of about "2bytes * nb objects" due to the
additional alignment constraint.  Actually, most objects have a size that's
a multiple of 8, so the extra alignment should only happen after allocating
an array or a string, so it's probably more like "2b * nb arrays-or-strings".


        Stefan


PS: Reminds me I have a local hack to save space for small strings and pure
    strings where the string data is placed at the end of the string object
    rather than going through an indirection.  This saves 4bytes per pure
    string (about 70KB in my case IIRC).  And it saves 8 bytes per string of
    3bytes or less (on 32bit machines) and of 7bytes or less (on 64
    machines).  Strings of 3bytes or less account for almost half of all the
    strings ever allocated, IIRC.

Re: USE_LSB_TAG and MS-DOS

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: 18 May 2004 11:13:47 -0400
> 
> >From the ChangeLog text it seems that cmpiling with USE_LISP_UNION_TYPE
> would have caught that eons ago.

Probably.  Alas, I have no resources to do such experiments with the
DOS port, unless I have a specific bug and a good reason to believe
that some non-standard switch will help me find it.

(I did compile with ENABLE_CHECKING, as you suggested, but that didn't
help to hunt this specific bug, as Emacs crashed in precisely the same
place as before.  I then used GC debugging techniques described in
etc/DEBUG to find that Emacs was marking dos-unsupported-char-glyph
and barfed when it saw 127 as a cdr of a cons cell.)

Anyway, having to look for this bug was an ample punishment, as it was
I who introduced dos-unsupported-char-glyph years ago, and its
incorrect initialization is my bad.

> > Btw, is pure[] usage supposed to go up when USE_LSB_TAG is in effect?
> > AFAICS, it went from 977KB to 1019KB with almost no changes in Lisp
> > files since the previous build.
> 
> There is likely to be an increase of about "2bytes * nb objects" due to the
> additional alignment constraint.  Actually, most objects have a size that's
> a multiple of 8, so the extra alignment should only happen after allocating
> an array or a string, so it's probably more like "2b * nb arrays-or-strings".

Hmm... the last garbage-collect that is run at the end of `loadup'
says:

  ((48784 . 10021) (10244 . 0) (543 . 60) 69410 144160 (48 . 16) (17 . 12) (4927 . 1814))

4900 strings is far too few to explain 40KB growth of pure storage, so
where else is the extra storage coming from?

(Should PURESIZE's value be enlarged when USE_LSB_TAG is in effect?)

Re: USE_LSB_TAG and MS-DOS

[Stefan Monnier]

>> From the ChangeLog text it seems that cmpiling with USE_LISP_UNION_TYPE
>> would have caught that eons ago.

> Probably.  Alas, I have no resources to do such experiments with the
> DOS port, unless I have a specific bug and a good reason to believe
> that some non-standard switch will help me find it.

USE_LISP_UNION_TYPE is only useful when compiling, so doing such a compile
every once in a while can be handy.  It's definitely more useful in
connection with USE_LSB_TAG since int/Lisp_Object mixups are not as
harmless as they were before.

> (I did compile with ENABLE_CHECKING, as you suggested, but that didn't
> help to hunt this specific bug, as Emacs crashed in precisely the same
> place as before.

That's right.  ENABLE_CHECKING won't catch Lisp_Object/int mixups as well.
I was thinking the problem had to do with alignment in which case
ENABLE_CHECKING is often helpful.

> Hmm... the last garbage-collect that is run at the end of `loadup'
> says:

>   ((48784 . 10021) (10244 . 0) (543 . 60) 69410 144160 (48 . 16) (17 . 12) (4927 . 1814))

> 4900 strings is far too few to explain 40KB growth of pure storage, so
> where else is the extra storage coming from?

Hmm... that's indeed not right.
But wait, GC will only report about non-pure objects.


        Stefan

Re: USE_LSB_TAG and MS-DOS

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: 18 May 2004 15:12:37 -0400
> 
> > Hmm... the last garbage-collect that is run at the end of `loadup'
> > says:
> 
> >   ((48784 . 10021) (10244 . 0) (543 . 60) 69410 144160 (48 . 16) (17 . 12) (4927 . 1814))
> 
> > 4900 strings is far too few to explain 40KB growth of pure storage, so
> > where else is the extra storage coming from?
> 
> Hmm... that's indeed not right.
> But wait, GC will only report about non-pure objects.

Okay, I will look again.

Re: USE_LSB_TAG and MS-DOS

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: 18 May 2004 15:12:37 -0400
> 
> > Hmm... the last garbage-collect that is run at the end of `loadup'
> > says:
> 
> >   ((48784 . 10021) (10244 . 0) (543 . 60) 69410 144160 (48 . 16) (17 . 12) (4927 . 1814))
> 
> > 4900 strings is far too few to explain 40KB growth of pure storage, so
> > where else is the extra storage coming from?
> 
> Hmm... that's indeed not right.
> But wait, GC will only report about non-pure objects.

I hacked alloc.c to report pure strings and vectors, and found out
that there were 21K of them.  So I guess that does explain a 40KB
growth of pure storage use.

Re: USE_LSB_TAG and MS-DOS

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: 16 May 2004 19:40:23 -0400
> 
> > Btw, the way DECL_ALIGN and USE_LSB_TAG are defined on lisp.h doesn't
> > leave any elegant way for specific platforms to turn that off without
> > cluttering lisp.h with ugly OS-specific #ifdef's.  Perhaps we should
> > devise a cleaner way.
> 
> It was devised in the hope that it will only be turned on where it's safe.
> Obviously, that's not the way it works, but at least it *should* work that
> way, so I think we're just hitting a bug.
> After all, all we need is to make sure pointers are multiples of 8.
> GNU malloc guarantees that AFAIK for malloced objects and DECL_ALIGN allows
> to get the same guarantee for static objects, so if we have both the only
> reasonf ro USE_LSB_TAG to fail is a bug, right?

I still think we should have an easy way to force or disable use of
LSB tags.  lisp.h already checks MAC_OSX for that, which is not nice
IMHO.

How about if USE_LSB_TAG's value will tell this, viz

  - if USE_LSB_TAG is defined to a non-zero value, always use LSB tags
  - if it is zero, don't use them
  - if it's undefined, lisp.h will use the current method to define
    it to either zero or 1

With this setup, Mac OSX could #define USE_LSB_TAG 1 in its config
file, and be done with that.

Re: USE_LSB_TAG and MS-DOS

[Stefan Monnier]

> I still think we should have an easy way to force or disable use of
> LSB tags.

We can add a NO_LSB_TAG.  I don't find it's worth the trouble, but don't
let that discourage you from installing such a change.

> lisp.h already checks MAC_OSX for that, which is not nice IMHO.

I don't know how to better check for "the malloc library distributed with
Mac OS X".

> How about if USE_LSB_TAG's value will tell this, viz
>   - if USE_LSB_TAG is defined to a non-zero value, always use LSB tags
>   - if it is zero, don't use them
>   - if it's undefined, lisp.h will use the current method to define
>     it to either zero or 1

Sounds good as well.


        Stefan

Re: USE_LSB_TAG and MS-DOS

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: 16 May 2004 19:40:23 -0400
> 
> > Btw, the way DECL_ALIGN and USE_LSB_TAG are defined on lisp.h doesn't
> > leave any elegant way for specific platforms to turn that off without
> > cluttering lisp.h with ugly OS-specific #ifdef's.  Perhaps we should
> > devise a cleaner way.
> 
> It was devised in the hope that it will only be turned on where it's safe.
> Obviously, that's not the way it works, but at least it *should* work that
> way, so I think we're just hitting a bug.
> After all, all we need is to make sure pointers are multiples of 8.
> GNU malloc guarantees that AFAIK for malloced objects and DECL_ALIGN allows
> to get the same guarantee for static objects, so if we have both the only
> reasonf ro USE_LSB_TAG to fail is a bug, right?

I still think we should have an easy way to force or disable use of
LSB tags.  lisp.h already checks MAC_OSX for that, which is not nice
IMHO.

How about if USE_LSB_TAG's value will tell this, viz

  - if USE_LSB_TAG is defined to a non-zero value, always use LSB tags
  - if it is zero, don't use them
  - if it's undefined, lisp.h will use the current method to define
    it to either zero or 1

With this setup, Mac OSX could #define USE_LSB_TAG 1 in its config
file, and be done with that.

Re: USE_LSB_TAG and MS-DOS

[Michael Mauger]

Below is a patch for the W32 MinGW (GCC) build with USE_LSB_TAG enabled.

There were a couple of references to VALMASK which didn't make sense with
USE_LSB_TAG.  There were also a couple of color functions that returned
W32 COLORREFs but treated the return value as Lisp_Int objects.  (Thanks
to YAMAMOTO Mitsuharu for pointing us in the right direction.)

I'm now building and using the USE_LSB_TAG emacs on W32 without obvious
problems.

Please review and apply if acceptable.

2004-05-18  Michael Mauger  <mmaug@yahoo.com>

	* emacs/src/w32fns.c (w32_color_map_lookup): Return Lisp_Object,
	not COLORREF.
	(x_to_w32_color): Return Lisp_Object, not COLORREF.
	* emacs/src/w32proc.c (create_child) [USE_LSB_TAG]: Don't mask
	out upper bits of pid.
	* emacs/src/w32heap.c (init_heap) [USE_LSB_TAG]: Don't check
	address range.


Index: emacs/src/w32heap.c
===================================================================
RCS file: /c/cvsroot/emacs/emacs/src/w32heap.c,v
retrieving revision 1.23
diff -u -r1.23 w32heap.c
--- emacs/src/w32heap.c	1 Sep 2003 15:45:57 -0000	1.23
+++ emacs/src/w32heap.c	18 May 2004 18:14:04 -0000
@@ -245,6 +245,7 @@
 	  exit (1);
 	}

+#ifndef USE_LSB_TAG
       /* Ensure that the addresses don't use the upper tag bits since
 	 the Lisp type goes there.  */
       if (((unsigned long) data_region_base & ~VALMASK) != 0)
@@ -252,6 +253,7 @@
 	  printf ("Error: The heap was allocated in upper memory.\n");
 	  exit (1);
 	}
+#endif

       data_region_end = data_region_base;
       real_data_region_end = data_region_end;
Index: emacs/src/w32proc.c
===================================================================
RCS file: /c/cvsroot/emacs/emacs/src/w32proc.c,v
retrieving revision 1.56
diff -u -r1.56 w32proc.c
--- emacs/src/w32proc.c	1 Sep 2003 15:45:57 -0000	1.56
+++ emacs/src/w32proc.c	18 May 2004 18:31:13 -0000
@@ -366,8 +366,10 @@
   if (cp->pid < 0)
     cp->pid = -cp->pid;

+#ifndef USE_LSB_TAG
   /* pid must fit in a Lisp_Int */
   cp->pid = (cp->pid & VALMASK);
+#endif

   *pPid = cp->pid;

Index: emacs/src/w32fns.c
===================================================================
RCS file: /c/cvsroot/emacs/emacs/src/w32fns.c,v
retrieving revision 1.232
diff -u -r1.232 w32fns.c
--- emacs/src/w32fns.c	14 May 2004 17:37:26 -0000	1.232
+++ emacs/src/w32fns.c	18 May 2004 18:15:19 -0000
@@ -828,7 +828,7 @@
     return Qnil;
 }

-COLORREF
+Lisp_Object
 w32_color_map_lookup (colorname)
      char *colorname;
 {
@@ -847,7 +847,7 @@

       if (lstrcmpi (SDATA (tem), colorname) == 0)
 	{
-	  ret = XUINT (Fcdr (elt));
+	  ret = Fcdr (elt);
 	  break;
 	}

@@ -910,7 +910,7 @@
 }


-COLORREF
+Lisp_Object
 x_to_w32_color (colorname)
      char * colorname;
 {
@@ -970,7 +970,7 @@
 	      if (i == 2)
 		{
 		  UNBLOCK_INPUT;
-		  return (colorval);
+		  return (make_number (colorval));
 		}
 	      color = end;
 	    }
@@ -1023,7 +1023,7 @@
 	      if (*end != '\0')
 		break;
 	      UNBLOCK_INPUT;
-	      return (colorval);
+	      return (make_number (colorval));
 	    }
 	  if (*end != '/')
 	    break;
@@ -1064,7 +1064,7 @@
 	      if (*end != '\0')
 		break;
 	      UNBLOCK_INPUT;
-	      return (colorval);
+	      return (make_number (colorval));
 	    }
 	  if (*end != '/')
 	    break;

Re: USE_LSB_TAG and MS-DOS

[Stefan Monnier]

> 2004-05-18  Michael Mauger  <mmaug@yahoo.com>
> 
> 	* emacs/src/w32fns.c (w32_color_map_lookup): Return Lisp_Object,
> 	not COLORREF.
> 	(x_to_w32_color): Return Lisp_Object, not COLORREF.
> 	* emacs/src/w32proc.c (create_child) [USE_LSB_TAG]: Don't mask
> 	out upper bits of pid.
> 	* emacs/src/w32heap.c (init_heap) [USE_LSB_TAG]: Don't check
> 	address range.

Thank you.  Those problems were fixed by Jason yesterday,



        Stefan

Re: USE_LSB_TAG and MS-DOS

[Jason Rumney]

Michael Mauger <mmaug@yahoo.com> writes:

> Below is a patch for the W32 MinGW (GCC) build with USE_LSB_TAG enabled.

Please check if I have missed anything that you found in the more
substantial changes I installed over the last two days.

Re: USE_LSB_TAG and MS-DOS

[Michael Mauger]

--- Jason Rumney <jasonr@gnu.org> wrote:
> Michael Mauger <mmaug@yahoo.com> writes:
> 
> > Below is a patch for the W32 MinGW (GCC) build with USE_LSB_TAG
> enabled.
> 
> Please check if I have missed anything that you found in the more
> substantial changes I installed over the last two days.

It looks good.  

I'm behind a firewall so I've been dependent on the nightly snapshots and
thus a day or two behind.  Thanks for your efforts.

-- Michael