This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 16479 - InstanceDataObject.escape might not handle chars > 32767
Summary: InstanceDataObject.escape might not handle chars > 32767
Alias: None
Product: platform
Classification: Unclassified
Component: Data Systems (show other bugs)
Version: 3.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: Jesse Glick
Depends on:
Blocks: 17142
  Show dependency tree
Reported: 2001-10-11 20:21 UTC by Jesse Glick
Modified: 2008-12-22 15:48 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2001-10-11 20:21:08 UTC
Since assigning to char may treat them as negative. Check; fix if needed; apply
same fix to; write test if possible.
Comment 1 Jesse Glick 2001-10-19 01:33:57 UTC
See also anovak's 1.27: apparently '*' might be
unsafe as well.
Comment 2 mgarrison 2001-10-22 22:11:38 UTC
Jesse asked me to post the list of characters that cause trouble in  
OpenVMS file names.

The problem with OpenVMS filenames stems from the fact that, while 
the OpenVMS operating system will support files with special 
characters in them, the OpenVMS JVM hasn't gotten around to providing 
that support yet.

So, the list I am providing for you is not a list of what characters 
are dangerous on OpenVMS per se, but what characters are dangerous 
when using the current OpenVMS JVM.

I worry that if a workaround is provided in NetBeans for this 
problem, it will never get properly fixed in our JVM.  This makes the 
quality of our JVM less than acceptable, in my view.  So, while I do 
greatly appreciate your willingness to work around this, 
I want you to know that it isn't a requirement on our part.

I decided it was easier to describe the characters that are allowed 
in the filename, rather than the ones that cause problems.

So, here is the current OpenVMS JVM view:
Ignoring directory specifications, a filename on OpenVM is made up of 
2 parts, the name and the extension.  The format is


name and extension can be made up of the following characters

        0-9                 // digits
        _                    // underscore
        -                     // dash
        a-z,A-Z          // letters

directory names follow exactly the same rules, i.e.

        0-9                 // digits
        _                    // underscore
        -                     // dash
        a-z,A-Z          // letters

so, it's not much....

Comment 3 Jesse Glick 2001-10-23 10:32:07 UTC
Can there be directory names with an extension? File names without

I agree this is a pretty limiting character set. It is difficult to
think of a reasonable character escape mechanism that would not force
escapes to be used even for common characters like '_'.

Another potential factor is that changing the escape character to one
which was previously not escaped at all (true for all OpenVMS chars
BTW) is backward compatibility of old instance files: normal
characters in them might be incorrectly assumed to be the starts of
escape sequences.

Adjusting mechanisms according to OS is probably not reasonable
because of the need to make NB projects directly portable across
Comment 4 mgarrison 2001-10-23 13:41:05 UTC
Well, as far as directories having extensions...on OpenVMS, the full 
file specification looks like this:


So, directories cannot have "." in them because it is part of the 
directory specifier syntax.  So, no, there is no "extension" for a 
directory name.  However, the directory file itself has an extension 
of .DIR.  So from the above example, if you ldid a "cd device:[dir]" 
and then did an "ls" you would see a file named subdir1.DIR.

The extension on the filespec is optional.  On OpenVMS a file without 
an extension still has a "." on the end of it...for example


Our JVM translates OpenVMS filespecs into UNIX-like filespecs when 
necessary.  But the support for translating special characters from 
UNIX filespecs into OpenVMS filespecs hasn't been available.  That's 
what is being worked on now.  The actual work for this support is in 
our C runtime library (libc to you UNIX folks).

I suspect it will be available for us to test in the next couple of 
weeks.  But, then it must go through the red-tape of actually 
releasing it to customers on all the different OS versions.  This is 
where the time delay comes in for us.

One thing we're considering is to make beta versions of the C RTL 
available from our Compaq NetBeans website so that our customers can 
test NetBeans 3.3.

Comment 5 Jesse Glick 2001-10-30 20:34:41 UTC
Have a patch...
Comment 6 Jesse Glick 2001-10-30 20:57:11 UTC

committed   * Up-To-Date  1.28       
committed   * Up-To-Date  1.96       
committed   * Up-To-Date  1.14       

Meg, when you get hold of an improved OpenVMS JVM I would definitely
recommend you run the complete xtest unit test suite on it, which will
include the test I just added that verifies that the generated
filenames are in fact safe for the OS you are running the test on.

I filed #17142 that this should be a general utility method, Tor you
may want to add yourself to the CC of that as well.
Comment 7 Quality Engineering 2003-07-01 16:05:03 UTC
Resolved for 3.4.x or earlier, no new info since then -> verified
Comment 8 Quality Engineering 2003-07-01 16:24:54 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.