Cannot declare constants of typedef'ed type

RESOLVED FIXED in M16

Status

()

P3
normal
RESOLVED FIXED
20 years ago
10 years ago

People

(Reporter: alecf, Assigned: mike+mozilla)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

20 years ago
I can't do this:

typedef  long nsMsgRuleActionType;

and then put in an interface:
const nsMsgRuleActionType nsMsgFilterActionNone=0;

even though nsMsgRuleActionType is a long.
I get:
nsIMsgFilter.idl:42: Warning: const decl 'nsMsgFilterActionNone' was not of type
short or long, ignored

That's kind of lame...
(if I can't have enums, at least give me this)
(Reporter)

Updated

20 years ago
OS: Linux → All
Hardware: PC → All
(Reporter)

Comment 1

20 years ago
I know jband will want to have input on this

Comment 2

20 years ago
I think that this is a limitation we can live with. The way some of the code
is structured (esp. the xpidl_typelib.c) this looks like a pain to support. If
it gets fixed then it has to get fixed for all code generators. *And* it has to
be limited to the types that resolve down to the useful types that we can
support on all mappings - int16, uint16, int32, and uint32.

FWIW... alecf, I don't think that you really do your users a service by trying
to make it look like a C++ enum type when it isn't. You're not getting C++
enum type safely here , so why try to make it look like you are? These are xpcom
interfaces and the implementations need to do runtime bounds checking anyway for
continued safety as the code matures.

I think there are more inmportant things to fix, but I've been overruled before
:)

It is worth noting that shaver has code in the xpidl_typlib.c to try to supports
*lots* of types for constants. But most don't map into useful types for C++
class static constants that we can generate into .H files. I foolishly '#if 0'ed
the code out rather than deleting it. Please no one try to revive it.
(Reporter)

Comment 3

20 years ago
heh, well I'm making one more pass at the enum argument on mozilla.xpcom... I
was hoping this was a cheap solution..

I was hoping it was as simple as changing some code that might look like

if (typeof(ident) != long && typeof(ident) != short) then...

to

if (resolved_typeof(ident) != long && resolved_typeof(ident) != short) then...

and then storing it in the typelib as the resolved type.

Again, I'm not trying to change the behavior of XPConnect at runtime, just the
generated C++ headers.

Comment 4

20 years ago
*** Bug 8992 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 5

19 years ago
*** Bug 12601 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M12
(Assignee)

Comment 6

19 years ago
Marking as assigned.
(Assignee)

Updated

19 years ago
Target Milestone: M12 → M14
(Assignee)

Comment 7

19 years ago
This is an enhancement, and doesn't need to be on dogfood or m12 radar; shifting
to m14.
(Assignee)

Comment 8

19 years ago
Enhancement.  Kicking out a few milestones.
Target Milestone: M14 → M16
(Assignee)

Comment 9

19 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Reporter)

Comment 10

19 years ago
oh thanks! I forgot about this and had gotten in the habit of just working 
around it. 

Updated

10 years ago
Component: xpidl → XPCOM
QA Contact: mike+mozilla → xpcom
You need to log in before you can comment on or make changes to this bug.