* passing arg of `merge_face_heights' makes integer from pointer without a cast
@ 2004-11-04 0:23 Andreas Schwab
2004-11-04 20:43 ` Richard Stallman
0 siblings, 1 reply; 7+ messages in thread
From: Andreas Schwab @ 2004-11-04 0:23 UTC (permalink / raw)
Cc: emacs-devel
I'm getting numerous warnings of the kind mentioned in the subject when
compiling xface.c. I can't see how that can work at all given that GCPRO
is passed a value that is actually not a Lisp_Object.
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."
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: passing arg of `merge_face_heights' makes integer from pointer without a cast
2004-11-04 0:23 passing arg of `merge_face_heights' makes integer from pointer without a cast Andreas Schwab
@ 2004-11-04 20:43 ` Richard Stallman
2004-11-04 21:16 ` Miles Bader
0 siblings, 1 reply; 7+ messages in thread
From: Richard Stallman @ 2004-11-04 20:43 UTC (permalink / raw)
Cc: emacs-devel, miles
passing arg of `merge_face_heights' makes integer from pointer
without a cast
Sender: emacs-devel-bounces+rms=gnu.org@gnu.org
X-Spam-Status: No, hits=0.0 required=5.0
tests=RCVD_IN_ORBS,USER_AGENT_GNUS_UA
version=2.55
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
I'm getting numerous warnings of the kind mentioned in the subject when
compiling xface.c. I can't see how that can work at all given that GCPRO
is passed a value that is actually not a Lisp_Object.
It makes no sense to GCPRO something that really contains a struct
named_merge_point *. In addition, this value isn't really used
in merge_face_heights, so why pass it at all?
That structure looks like something for which cons cells would work,
so why not use cons cells?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: passing arg of `merge_face_heights' makes integer from pointer without a cast
2004-11-04 20:43 ` Richard Stallman
@ 2004-11-04 21:16 ` Miles Bader
2004-11-05 15:01 ` Richard Stallman
0 siblings, 1 reply; 7+ messages in thread
From: Miles Bader @ 2004-11-04 21:16 UTC (permalink / raw)
Cc: Andreas Schwab, emacs-devel, miles
On Thu, Nov 04, 2004 at 03:43:29PM -0500, Richard Stallman wrote:
> That structure looks like something for which cons cells would work,
> so why not use cons cells?
Because these structures are allocated on the stack -- they are very temporary
and used extremely often.
-Miles
--
"Most attacks seem to take place at night, during a rainstorm, uphill,
where four map sheets join." -- Anon. British Officer in WW I
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: passing arg of `merge_face_heights' makes integer from pointer without a cast
2004-11-04 21:16 ` Miles Bader
@ 2004-11-05 15:01 ` Richard Stallman
2004-11-05 22:34 ` Miles Bader
0 siblings, 1 reply; 7+ messages in thread
From: Richard Stallman @ 2004-11-05 15:01 UTC (permalink / raw)
Cc: schwab, emacs-devel, miles
> That structure looks like something for which cons cells would work,
> so why not use cons cells?
Because these structures are allocated on the stack -- they are very temporary
and used extremely often.
If they are allocated in the stack, then it should be easy to
explicitly gcpro the Lisp_Object in each one. Just do that in the
frame that allocates the struct. Doesn't that do the job this
gcpro argument was intended to do?
Here's another idea.
How deep does this stack often get? Maybe just allocate a single
vector and use it as a stack. If it ever isn't big enough, replace it
with a vector twice as big. You can null out the whole vector at the
end of face merging.
Since this would be an ordinary Lisp vector, GC would handle it just
fine, it just needs a staticpro.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: passing arg of `merge_face_heights' makes integer from pointer without a cast
2004-11-05 15:01 ` Richard Stallman
@ 2004-11-05 22:34 ` Miles Bader
2004-11-06 15:19 ` Richard Stallman
0 siblings, 1 reply; 7+ messages in thread
From: Miles Bader @ 2004-11-05 22:34 UTC (permalink / raw)
Cc: schwab, emacs-devel, Miles Bader
On Fri, Nov 05, 2004 at 10:01:47AM -0500, Richard Stallman wrote:
> If they are allocated in the stack, then it should be easy to
> explicitly gcpro the Lisp_Object in each one. Just do that in the
> frame that allocates the struct. Doesn't that do the job this
> gcpro argument was intended to do?
That would probably be fine (I think there's only one place where it needs to
be done). The GCPRO argument to merge_face_heights can probably just be
deleted -- all other uses just pass Qnil.
-Miles
--
In New York, most people don't have cars, so if you want to kill a person, you
have to take the subway to their house. And sometimes on the way, the train
is delayed and you get impatient, so you have to kill someone on the subway.
[George Carlin]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-11-08 3:41 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-04 0:23 passing arg of `merge_face_heights' makes integer from pointer without a cast Andreas Schwab
2004-11-04 20:43 ` Richard Stallman
2004-11-04 21:16 ` Miles Bader
2004-11-05 15:01 ` Richard Stallman
2004-11-05 22:34 ` Miles Bader
2004-11-06 15:19 ` Richard Stallman
2004-11-08 3:41 ` Miles Bader
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).