November 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [BUG] with non-ascii characters in dir names 25 years, 5 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > No, you're surely wrong. :-) Seriously, stat(), open() and > interruptible_open() do so-called Mule-encapsulation, which means that > it is safe to call them with XSTRING_DATA. Woops. Something for "the Mule coding" section. This also means it is wrong to call open with a native encoding filename isn't it? > That taken into account, I don't think things are nearly as bad as you > make them out to be. I could be wrong, though. I hope you are right. Jan

1 participants
0 comments

Re: [BUG] with non-ascii characters in dir names 25 years, 5 months

Jan Vroonhof

Didier Verna <verna(a)inf.enst.fr> writes: Note that the same change as needed to fix your bug needs to apply to the the NT version was well. Note that top that file claims the function has been MULE-ized. > You're right, this corrects the bug. This brings me a question that > might be stupid, but isn't it likely that most use of XSTRING_DATA > through the code will be bogus in the same fashion[1]? Probably. MULE is totally broken this regard. I looked at a few of them and most of them indeed look bogus. bolzano:vroonhof/cvs/xemacs-20/src> grep XSTRING_DATA *.c | wc -l 424 :-( I am wondering. Suppose we were to redefine XSTRING_DATA such that it always used 'raw-text' or maybe even 'binary' as the coding system would that help? > about the coding system ? I mean take the same function, unix_create_process, > where the environement is massively copied for the child to be forked. What > should we do about it ? You mean the arguments etc.. Do we really want 'process-argument-coding-system' (this can also be a lisp list op coding systems such that the n-th item is used as a coding sytem for the n-th argument) en 'environment-variable-coding-system', domain-or-host-name-coding-system. :-( Jan

5 participants
4 comments

Re: [BUG] with non-ascii characters in dir names 25 years, 5 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > I haven't checked on it further but that one is bound to be wrong. > These are also suspect > > frame-x.c:1350: strcpy (dnd_data + dnd_len - 1, (CONST char *)XSTRING_DATA (XCAR (run))); > frame-x.c:1365: dnd_data = (char *)XSTRING_DATA (data); That's fairly new code written by Oliver Graf. > These ones are surely wrong: > > fileio.c:1731: else if (stat ((CONST char *) XSTRING_DATA (newname), &out_st) < 0) > fileio.c:1734: ifd = interruptible_open ((char *) XSTRING_DATA (filename), O_RDONLY | OPEN_BINARY, 0); > fileio.c:1773: ofd = open( (char *) XSTRING_DATA (newname), No, you're surely wrong. :-) Seriously, stat(), open() and interruptible_open() do so-called Mule-encapsulation, which means that it is safe to call them with XSTRING_DATA. That taken into account, I don't think things are nearly as bad as you make them out to be. I could be wrong, though. > The one in Fopen_database is clearly wrong also. Also the database > keys are in XEmacs internal incoding. Was that intended? The database code is un-Muleized, I think. > P.P.S. FSF Emacs makes of the lisp allocator to allocate the > strings. Therefore they do not need alloca. However it seems to > create a new buffer for each filename it needs to convert! Gag. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth

1 participants
0 comments

Re: New version of htmlize.el 25 years, 5 months

Hrvoje Niksic

Colin Rafferty <craffert(a)ms.com> writes: > This looks great. Too bad Netscape sucks. W3 showed my colors > beautifully. Netscape 4.06 gives me no colors at all. > > I am unhappy. Set `htmlize-output-type' to `font', and you'll probably get all the colors. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Satellite Safety Tip #14: If you see a bright streak in the sky coming at you, duck.

2 participants
1 comments

Re: New version of htmlize.el 25 years, 5 months

Neal D. Becker

>>>>> "Colin" == Colin Rafferty <craffert(a)ms.com> writes: Colin> colors. Anyway, I don't need that, since I can just look at the file Colin> in font-lock-mode. If you can look at in in font-lock mode, you didn't need htmlize in the first place :)

1 participants
0 comments

Re: [BUG] with non-ascii characters in dir names 25 years, 5 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > XSTRING_DATA is exactly what the name says, dereferencing Lisp_Object > to struct Lisp_String, and then dereferencing it to a Bufbyte pointer. > It adhering to all the normal XEmacs naming conventions. XSTRING_DATA > (logically) returns a Bufbyte pointer, which should cries for > conversion when used on the outside. However it seems to be common practise to just cast it to a (char *). Grepping for char \*)[ ]*XSTRING_DATA still has 223 hits most them probably very correct code. However may be I am going mad but I do not get the feeling that almost all are correct, for instance [randomly taken from igrepping for the above expression]. glyphs.c:1798: result = XpmReadFileToData ((char *) XSTRING_DATA (name), &data); I haven't checked on it further but that one is bound to be wrong. These are also suspect frame-x.c:1350: strcpy (dnd_data + dnd_len - 1, (CONST char *)XSTRING_DATA (XCAR (run))); frame-x.c:1365: dnd_data = (char *)XSTRING_DATA (data); These ones are surely wrong: fileio.c:1731: else if (stat ((CONST char *) XSTRING_DATA (newname), &out_st) < 0) fileio.c:1734: ifd = interruptible_open ((char *) XSTRING_DATA (filename), O_RDONLY | OPEN_BINARY, 0); fileio.c:1773: ofd = open( (char *) XSTRING_DATA (newname), The one in Fopen_database is clearly wrong also. Also the database keys are in XEmacs internal incoding. Was that intended? Anyway that was just a random sample of things I checked. May be it should be reassuring that I can spot most of these from the grep output but somehow it isn't. > People who hack XEmacs should know what they are doing. However there is still a lot of old pre-MULE code lying around. MULE changed the meaning of XSTRING_DATA and there is no way of telling somebody looked at the code to make sure it was correct. Especially given the fact that since our internal coding is a superset of ascii it will work OK most of the time. > If they > don't, renaming XSTRING_DATA to something else won't help one bit. What I mean is that renaming XSTRING_DATA forces one to look at every use of it once. i.e. any use of XSTRING_BUFBYTE or any other new name makes it immediately clear that particular piece of code was looked at and found to be correct. I.e. you replace subtle breakage (XSTRING_DATA no longer ascii) by explicit breakage (undefined macro) forcing one to look at the code. This technique is used by Linus in his kernel and I think it works well (and he does get a lot of flak for it sometimes). > > I am not advocating doing this now but I have the feeling this > > should be done sometime and that why this particular number of > > XSTRING_DATA's look scary. > > Why does it look scary? Yes, you spotted an actual bug, and yes, the > patch for it is trivial. It looks scary because I have the feeling there are a lot more of these to be found. It looks scary because a lot these problems are in code that was supposed to be looked over already (somehow I think file-system-coding came after Ben's checks). I also think most these problems in new code comes from people cut&pasting old buggy code (i.e. process-nt vs process-unix). > But what's the problem with the normal, non-buggy XSTRING_DATA's in > the code? They are indistinguishable from the buggy ones. As to comments about the "Coding for MULE section" I think there must be something about when converting TO external strings. You won't crash XEmacs with it but you will create subtle problems. Jan P.S. On a related matter. In buffer.h You may wonder why this is written in this fashion and not as a function call. With a little trickery it could certainly be written this way, but it won't work because of those DAMN GCC WANKERS who couldn't be bothered to handle alloca() properly on the x86 architecture. (If you put a call to alloca() in the argument to a function call, the stack space gets allocated right in the middle of the arguments to the function call and you are unbelievably hosed.) */ Is this still the case? For instance m/intel386.h defines #ifdef __GNUC__ /* GCC's alloca() is semi-broken. See lisp.h. This brokenness has been confirmed under both Linux and NetBSD. It may also exist on non-Intel architectures. */ #define BROKEN_ALLOCA_IN_FUNCTION_CALLS #endif however no nuch define is used anywhere in the code. P.P.S. FSF Emacs makes of the lisp allocator to allocate the strings. Therefore they do not need alloca. However it seems to create a new buffer for each filename it needs to convert! Jan

1 participants
0 comments

Re: New version of htmlize.el 25 years, 5 months

Colin Rafferty

Hrvoje Niksic writes: > Colin Rafferty <craffert(a)ms.com> writes: >> This looks great. Too bad Netscape sucks. W3 showed my colors >> beautifully. Netscape 4.06 gives me no colors at all. >> >> I am unhappy. > Set `htmlize-output-type' to `font', and you'll probably get all the > colors. Which works perfectly in Netscape, but now w3 (4.0pre.14) doesn't do colors. Anyway, I don't need that, since I can just look at the file in font-lock-mode. I am happy! -- Colin

1 participants
0 comments

XEmacs Bug Tracking system up and running? 25 years, 5 months

Gunnar Evermann

maybe I just missed something, here. Is the XEmacs bug tracking system (http://cvs.xemacs.org/XEmacs-bugs) actually up and running? I found an *amazing* number (139) of nice and interessting new (at least to me) bug reports in the incoming folder there. Apparently an automatic message is send out to the people reporting the bugs (basically 'we are working on it'), but are we *really* working on it?? Who will do the sorting into categories and stuff? I'd be very interessted to help handling these reports, if any help is needed... Gunnar

2 participants
1 comments

Re: New version of htmlize.el 25 years, 5 months

Colin Rafferty

Hrvoje Niksic writes: > My newsserver is ＠#$＠#$＠#, so I have no idea if my submissions to > gnu.emacs.sources et al. really reached anyone. Anyway, here is the > latest and greatest version of htmlize.el. I would like to hear your > comments. This looks great. Too bad Netscape sucks. W3 showed my colors beautifully. Netscape 4.06 gives me no colors at all. I am unhappy. -- Colin

2 participants
1 comments

Re: New version of htmlize.el 25 years, 5 months

Peter Gieser

I am using Netscape 4.07 for AIX and it displays the htmlize'd stuff beautifully. Great program. Pete Colin Rafferty <craffert(a)ms.com> wrote: > Hrvoje Niksic writes: > > > My newsserver is ＠#$＠#$＠#, so I have no idea if my submissions to > > gnu.emacs.sources et al. really reached anyone. Anyway, here is the > > latest and greatest version of htmlize.el. I would like to hear your > > comments. > > This looks great. Too bad Netscape sucks. W3 showed my colors > beautifully. Netscape 4.06 gives me no colors at all. > > I am unhappy. -- Peter Gieser, Ph.D. Phone: (352) 392-5198 #306 POG Statistical Office FAX: (352) 392-8162 104 North Main Street #600 Email: pete(a)pog.ufl.edu Gainesville, FL 32601 Web: www.stat.ufl.edu/personnel/faculty.html * Send me email to receive my PGP public key *

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta November 1998