-
Notifications
You must be signed in to change notification settings - Fork 380
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IDLv4 Explicitly-named Integer Types #840
Conversation
uint16, uint32, uint64, int16, int32, int64 from IDL 4.2 section 7.4.13.4.5 "Explicitly-named Integer Types" WIP uint8/int8 from IDL4.2 section 7.4.13.4.4 "Integers restricted to holding 8-bits of information"
Any updates on this PR, do we need to keep this open? |
I don't see a reason to close it as I plan to come back to it someday and it also keeps the work visible to someone who might be interested. If it's an issue of time there are older PRs. |
And a bunch of fixes to get it to (sorta) work.
- Add uint8 and int8 to ACE and TAO serialization - Refactor parts of AST_Expression to also cover uint8 and int8
New test should be in TAO/bin/tao_orb_tests.lst, msvc doesn't compile and has some new warnings, will review when the checks are all ok |
I can fix the warnings in
I don't know the cause of this particular error, but if there is chance for the temporary file to problematic on Windows, it would be fixed by avoiding using a temporary file in #1357. |
#define ACE_CHAR_MAX 0x7F | ||
#define ACE_CHAR_MIN -(ACE_CHAR_MAX)-1 | ||
#define ACE_OCTET_MAX 0xFF | ||
#define ACE_INT8_MAX 0x7F |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should convert these to constexpr
at some point
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should, but I'd like that to be later because I don't want to make this harder to backport than it already is.
@@ -0,0 +1,58 @@ | |||
#ifndef TAO_BASIC_TYPES_IDLV4_H |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not put these in Basic_Types.h
and in the CORBA
namespace, I think we should support CORBA::Int8
without the requirement that the user includes this file, makes it much easier to use this construct which is also much clear in application code. For TAOX11 we could use this also without a special include and a namespace using.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
int8 is not a CORBA type (it has no Typecode, Any, IfR, DII, DSI, shouldn't be used for remote calls...).
For this whole group of type names, we wanted to make it explicit that these are different - tao_idl with default arguments will not accept them, they're not "peers" of the other names.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, we could keep Int8/UInt8 in this file, but the others are just typedefs which could be used without problems. That would enable TAOX11 to easily use these internally without a special include
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't introduce a new CORBA::IDLv4
namespace
@@ -791,6 +807,18 @@ class ACE_Export ACE_InputCDR | |||
ACE_CDR::Octet &ref_; | |||
}; | |||
|
|||
struct ACE_Export to_int8 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this really required, isn't int8_t a distinct type itself?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(u)int*_t
are typedefs, probably at least one is the same as the one used for ACE_CDR's Octet, etc.
@@ -60,6 +60,12 @@ project(TAO_Core_idl) : tao_versioning_idl_defaults, gen_ostream, install, pidl_ | |||
WStringSeq.pidl >> AnyTypeCode/WStringSeqA.h AnyTypeCode/WStringSeqA.cpp | |||
} | |||
|
|||
IDL_Files { | |||
idlflags += -Sci -Gse -Gata --idl-version 4 | |||
Int8Seq.pidl >> AnyTypeCode/Int8SeqA.h AnyTypeCode/Int8SeqA.cpp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
New Int8SeqA/UInt8SeqA needs to be added to AnyTypeCode
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not in scope. Can I just remove those parts of the line?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are the files generates but empty? Then just add them, we shouldn’t have generated files which we don’t compile
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still needs some CI fixes and to resolve @jwillemsen's comment about AnyTypeCode. But the review itself is good to go.
f32e89c
to
354b698
Compare
@iguessthislldo Several new warnings in the https://buildlogs.remedy.nl/win_vs2019_tao_debug/index.html build, can you have a look? |
Can you also check the Coverity scan results, we have fresh results, several new issues related to this PR |
Yes, I will look into both, but for the warnings I don't think I will be able to tell if there are any warnings I need to fix outside the explicit_ints test. |
DOCGroup#840 Because the main set of issues in `coerce_value` was caused by applying the existing pattern, the issues caused by the existing code should also be fixed.
Ported from DOCGroup#840 to ACE6/TAO2. Also regenerated with Bison 3.7.6 at the same time like in d581918 in DOCGroup#1594
DOCGroup#840 Because the main set of issues in `coerce_value` was caused by applying the existing pattern, the issues caused by the existing code should also be fixed.
Backport of DOCGroup#1715 Fixes DOCGroup#1713 and adds some regression tests for constant expressions. Also tried to do some more cleanup and minor fixes related to DOCGroup#840.
Implement part of IDL4.2 Section 7.4.13 "Building Block Extended Data-Types" by implementing:
int8
anduint8
octet
andchar
types.int16
,uint16
,int32
,uint32
,int64
, anduint64