Skip to content
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

Merged
merged 21 commits into from
Jun 30, 2021

Conversation

iguessthislldo
Copy link
Member

@iguessthislldo iguessthislldo commented Feb 21, 2019

Implement part of IDL4.2 Section 7.4.13 "Building Block Extended Data-Types" by implementing:

  • 7.4.13.4.4 "Integers restricted to holding 8-bits of information": int8 and uint8
    • New integer types that have to be distinguished from the existing octet and char types.
  • 7.4.13.4.5 "Explicitly-named Integer Types": int16, uint16, int32, uint32, int64, and uint64
    • Just aliases of the existing integer types

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"
@jwillemsen
Copy link
Member

Any updates on this PR, do we need to keep this open?

@iguessthislldo
Copy link
Member Author

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
@iguessthislldo iguessthislldo marked this pull request as ready for review June 13, 2021 03:49
@iguessthislldo iguessthislldo changed the title stdint-like integer types in IDLv4 IDLv4 Explicitly-named Integer Types Jun 13, 2021
@jwillemsen
Copy link
Member

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

@iguessthislldo
Copy link
Member Author

msvc doesn't compile and has some new warnings,

I can fix the warnings in AST_Expression.cpp, but for the error this says it's an I/O error:

    263>CustomBuild:
         D:\a\ACE_TAO\ACE_TAO/ACE\bin\tao_idl: Unable to rename temporary file "C:\Users\RUNNER~1\AppData\Local\Temp\tao-idlf_N2p6U3" to "C:\Users\RUNNER~1\AppData\Local\Temp\tao-idlf_N2p6U3.cpp": Input/output error
   263>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(241,5): error MSB8066: Custom build for 'AnySeq.pidl;Bounds.pidl;Dynamic.pidl;Dynamic_Parameter.pidl;ValueModifier.pidl;Visibility.pidl' exited with code 1. [D:\a\ACE_TAO\ACE_TAO\TAO\tao\AnyTypeCode\AnyTypeCode_Idl.vcxproj]
   263>Done Building Project "D:\a\ACE_TAO\ACE_TAO\TAO\tao\AnyTypeCode\AnyTypeCode_Idl.vcxproj" (default targets) -- FAILED.

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.

ACE/ace/CDR_Base.h Outdated Show resolved Hide resolved
TAO/TAO_IDL/fe/fe_lookup.cpp Show resolved Hide resolved
TAO/TAO_IDL/ast/ast_expression.cpp Outdated Show resolved Hide resolved
TAO/TAO_IDL/include/ast_expression.h Show resolved Hide resolved
TAO/tao/CDR.h Outdated Show resolved Hide resolved
TAO/TAO_IDL/be/be_helper.cpp Outdated Show resolved Hide resolved
TAO/TAO_IDL/be/be_helper.cpp Outdated Show resolved Hide resolved
TAO/TAO_IDL/include/ast_expression.h Show resolved Hide resolved
TAO/TAO_IDL/be/be_helper.cpp Outdated Show resolved Hide resolved
TAO/TAO_IDL/ast/ast_expression.cpp Outdated Show resolved Hide resolved
TAO/TAO_IDL/ast/ast_expression.cpp Outdated Show resolved Hide resolved
ACE/ace/CDR_Base.h Outdated Show resolved Hide resolved
#define ACE_CHAR_MAX 0x7F
#define ACE_CHAR_MIN -(ACE_CHAR_MAX)-1
#define ACE_OCTET_MAX 0xFF
#define ACE_INT8_MAX 0x7F
Copy link
Member

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

Copy link
Member Author

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
Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

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

Copy link
Member

@jwillemsen jwillemsen left a 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
Copy link
Member

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?

Copy link
Member

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
Copy link
Member

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

Copy link
Member Author

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?

Copy link
Member

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

Copy link
Member

@mitza-oci mitza-oci left a 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.

@iguessthislldo iguessthislldo merged commit 48f51b5 into DOCGroup:master Jun 30, 2021
@jwillemsen
Copy link
Member

@iguessthislldo Several new warnings in the https://buildlogs.remedy.nl/win_vs2019_tao_debug/index.html build, can you have a look?

@jwillemsen
Copy link
Member

Can you also check the Coverity scan results, we have fresh results, several new issues related to this PR

@iguessthislldo
Copy link
Member Author

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.

iguessthislldo added a commit to iguessthislldo/ACE_TAO that referenced this pull request Jul 8, 2021
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.
iguessthislldo added a commit to iguessthislldo/ACE_TAO that referenced this pull request Jul 9, 2021
Ported from DOCGroup#840 to ACE6/TAO2.
Also regenerated with Bison 3.7.6 at the same time like in
d581918 in
DOCGroup#1594
iguessthislldo added a commit to iguessthislldo/ACE_TAO that referenced this pull request Jul 9, 2021
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.
iguessthislldo added a commit to iguessthislldo/ACE_TAO that referenced this pull request Nov 9, 2021
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants