xpidl produces bogus Java file names

RESOLVED DUPLICATE of bug 384748

Status

Core Graveyard
Java to XPCOM Bridge
--
minor
RESOLVED DUPLICATE of bug 384748
11 years ago
4 years ago

People

(Reporter: Marcus Better, Assigned: jhp (no longer active))

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.7 (like Gecko) (Debian)
Build Identifier: 

When declaring multiple interfaces in the same IDL file and running "xpidl -m java", the generated file names for the Java interfaces are very strange. Each subsequent name gets appended to the previous one.

This was reported [1] for Xulrunner 1.8.1.6-1 on Debian, but the same code is in the Mozilla CVS.

I have made a patch that fixes this.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=435689


Reproducible: Always

Steps to Reproduce:
Create a file Test.idl with contents as follows:

~$ cat Test.idl
[scriptable,uuid(00000000-0000-0000-0000-000000000000)]
interface Iface1
{
};

[scriptable,uuid(00000000-0000-0000-0000-000000000001)]
interface Iface2
{
};

[scriptable,uuid(00000000-0000-0000-0000-000000000002)]
interface Iface3
{
};

~$ ./xpidl -m java Test.idl

Note that this is probably only triggered if the path to the IDL file doesn't contain a slash, i.e. it must be a plain filename.

Actual Results:  
~$ ls *java
?Iface1.java  ?Iface1.javaIface2.java  ?Iface1.javaIface2.javaIface3.java

The first character in the file names is something unprintable which
appears as "^C" in Emacs. And the subsequent filenames have been
concatenated to the previous one.


Expected Results:  
The file names should be "Iface1.java", "Iface2.java" and "Iface3.java".
(Reporter)

Comment 1

11 years ago
Created attachment 275009 [details] [diff] [review]
Correct the case when the filename doesn't contain a forward slash.

Besides doing the right thing with respect to filenames, this patch takes care not to overrun the filename buffer which could possibly happen with the old code.
(Assignee)

Comment 2

11 years ago
This was actually fixed in bug 384748.  However, that is just checked in to the trunk.  I need to check it in to the 1.8 branch.  Thanks.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 384748
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.