[ nedit-Bugs-682004 ] Problem with null characters

SourceForge.net noreply at sourceforge.net
Mon Mar 5 01:18:32 CET 2007


Bugs item #682004, was opened at 2003-02-07 00:44
Message generated for change (Comment added) made by yooden
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=111005&aid=682004&group_id=11005

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mark Geary (markgeary)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with null characters

Initial Comment:
Create a file with null characters.
Open it with Nedit.
Internaly, the null characters are represented by 
some other character--call it ^A.
Try to enter a real ^A by typing Meta-Ctrl-A.
The representation of null characters should be 
changed to something other than ^A, but it is not.

I can reproduce this bug with Nedit 5.3 on both VMS 
and HP-UX 11.



----------------------------------------------------------------------

>Comment By: Thorsten Haude (yooden)
Date: 2007-03-05 01:18

Message:
Logged In: YES 
user_id=119143
Originator: NO

Could someone please test this?

----------------------------------------------------------------------

Comment By: Thorsten Haude (yooden)
Date: 2006-09-17 17:13

Message:
Logged In: YES 
user_id=119143

I cannot even enter self-insert a control character the way
mark indicated, so I cannot test the patch.
Did someone else using a lot of binary data test the patch?

----------------------------------------------------------------------

Comment By: Mark Geary (markgeary)
Date: 2006-02-20 20:25

Message:
Logged In: YES 
user_id=706461

When a control code is self-inserted (as with ALT-CTRL-a, 
for example)
BufSubstituteNullChars() is not called.

If a control code is inserted with the "Edit->Insert Ctrl 
Code..."
menu item, controlDialogAP calls BufSubstituteNullChars() 
before
(indirectly, via XtCallActionProc()) calling insertStringAP
().

I suppose, then, that the fix for this bug is to add a call 
to
BufSubstituteNullChars() somewhere in the following call 
chain:

#0  0x6f6b8 in insert ()
#1  0x6d4a8 in BufInsert ()
#2  0x67ac4 in TextDInsert ()
#3  0x633c4 in simpleInsertAtCursor ()
#4  0x5e778 in TextInsertAtCursor ()

#5  0x6026c in selfInsertAP ()

#6  0x77d51fc0 in HandleActions () from /usr/lib/libXt.3
#7  0x77d52528 in HandleSimpleState () from /usr/lib/libXt.3
#8  0x77d52bfc in _XtTranslateEvent () from /usr/lib/libXt.3
#9  0x77d261f8 in XtDispatchEventToWidget () 
from /usr/lib/libXt.3
#10 0x77d27180 in _XtDefaultDispatcher () 
from /usr/lib/libXt.3
#11 0x77d27390 in XtDispatchEvent () from /usr/lib/libXt.3
#12 0x77d27a5c in XtAppMainLoop () from /usr/lib/libXt.3
#13 0x127c0 in main ()

I tried the following patch on today's development tarball. 
It appears
to fix the problem. I don't know whether it has undesirable
side-effects.

*** nedit-old/source/text.c     Fri Oct  8 17:55:51 2004
--- nedit/source/text.c Mon Feb 20 14:16:42 2006
***************
*** 37,42 ****
--- 37,43 ----
  #include "textDrag.h"
  #include "nedit.h"
  #include "calltips.h"
+ #include "../util/DialogF.h"
  
  #include <stdio.h>
  #include <stdlib.h>
***************
*** 2227,2232 ****
--- 2228,2234 ----
  
  static void selfInsertAP(Widget w, XEvent *event, String 
*args, Cardinal *nArgs)
  {   
+     WindowInfo *window = WidgetToWindow(w);
  #ifdef NO_XMIM
      static XComposeStatus compose = {NULL, 0};
  #else
***************
*** 2256,2261 ****
--- 2258,2270 ----
      TakeMotifDestination(w, e->time);
      chars[nChars] = '\0';
      
+     if (!BufSubstituteNullChars(chars, nChars, window-
>buffer))
+     {
+         DialogF(DF_ERR, window->shell, 1, "Error", "Too 
much binary data",
+                 "OK");
+         return;
+     }
+ 
      /* If smart indent is on, call the smart indent 
callback to check the
         inserted character */
      if (((TextWidget)w)->text.smartIndent) {


----------------------------------------------------------------------

Comment By: Thorsten Haude (yooden)
Date: 2006-02-05 13:31

Message:
Logged In: YES 
user_id=119143

Nope

----------------------------------------------------------------------

Comment By: Thorsten Haude (yooden)
Date: 2004-07-15 10:49

Message:
Logged In: YES 
user_id=119143

Someone? It wouldn't make sense to patch a solution if it
isn't a valid one for these cases.

----------------------------------------------------------------------

Comment By: Thorsten Haude (yooden)
Date: 2003-11-26 21:48

Message:
Logged In: YES 
user_id=119143

What I see: the cat thing gives me the null character, and I
see &lt;nul&gt; in NEdit. Ctrl-@ in NEdit gives me 021 (device
control 1), which NEdit displays as &lt;dc1&gt;. NEdit's menu
entry gives me &lt;nul&gt; of course. 

So is there a cononical list of stuff that should happen if
certain combinations of Ctrl-&lt;something&gt; is pressed?

----------------------------------------------------------------------

Comment By: Mark Geary (markgeary)
Date: 2003-11-26 21:34

Message:
Logged In: YES 
user_id=706461

On my unix box, I use `cat &gt; file' and type ctrl- at . In NEdit, 
on could use Edit-&gt;Insert_Ctrl_Code and enter `0'.


----------------------------------------------------------------------

Comment By: Thorsten Haude (yooden)
Date: 2003-11-26 20:48

Message:
Logged In: YES 
user_id=119143

I'm not sure I understand the problem. The representation
for a null character is &lt;nul&gt; here. I don't have a &lt;nul&gt;
key, what am I supposed to do to enter this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=111005&aid=682004&group_id=11005


More information about the Develop mailing list