Narrowing conversion of 'int' value to 'short' is not allowed here - c++11

Recently I upgraded my SourcePro to 2021 Version and during RCB setup when it prompts me to select C++ dialect, I selected the only option available i.e. C++14. After the setup I started compiling Tuxedo code and currently facing the following errors in multiple files say about 200-250 files in my Tuxedo project, and below are the details of my Solaris OS and the compiler.
uname -a:
SunOS nzdrb12z 5.11 11.4.40.107.3 sun4v sparc sun4v non-global-zone
cc -V:
cc: Studio 12.6 Sun C 5.15 SunOS_sparc 2017/05/30
Error:
app/sdasup/home/mhp/source/develop/bc/include/bcIControlBlock.h", line
34: Error: Narrowing conversion of 'int' value to 'short' is not
allowed here.
"/app/sdasup/home/mhp/source/develop/bc/include/bcIPControlBlockTran.h",
line 48: Error: Narrowing conversion of 'int' value to 'short' is not
allowed here.
"/app/sdasup/home/mhp/source/develop/bc/include/bcIPConnectionParam.h",
line 44: Error: Narrowing conversion of 'int' value to 'short' is not
allowed here.
"/app/sdasup/home/mhp/source/develop/bc/include/bcMwServicesGuid.h",
line 15: Error: Narrowing conversion of 'int' value to 'short' is not
allowed here.
"/app/sdasup/home/mhp/source/develop/bc/include/bcMwServicesGuid.h",
line 34: Error: Narrowing conversion of 'int' value to 'short' is not
allowed here.
"/app/sdasup/home/mhp/source/develop/bc/include/bcMwServicesGuid.h",
line 36: Error: Narrowing conversion of 'int' value to 'short' is not
allowed here.
"/app/sdasup/home/mhp/source/develop/bc/include/bcMwServicesGuid.h",
line 41: Error: Narrowing conversion of 'int' value to 'short' is not
allowed here.
"/app/sdasup/home/mhp/source/develop/bc/include/bcMwServicesGuid.h",
line 45: Error: Narrowing conversion of 'int' value to 'short' is not
allowed here.
Suppose I chose the first error message file to open bcIControlBlock.h and the line number 34 points to the following code,
DEFINE_GUID(IID_IAbcIControlBlock, 0xc7645022, 0x93e9, 0x11d1, 0x9d, 0x90, 0x0, 0x0, 0xf6, 0x4e, 0x16, 0x6a);
when searched for the Macro it has following definition,
#define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \
EXTERN_C const GUID name \
= { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } }
As a workaround I tired the following to solve it,
DEFINE_GUID(IID_IAbcIControlBlock, 0xc7645022, (short)0x93e9, 0x11d1, 0x9d, 0x90, 0x0, 0x0, 0xf6, 0x4e, 0x16, 0x6a);
Albeit it works fine I am very doubtful on the approach I followed to resolve the issue. However changing multiple files seems to be painful.
Quesitons:
Is the workaround solution correct?
If so then how it can be made more general to change it at one place than multiple files?
If not what is best approach to resolve so that it wont break anything further?
Thanks in advance.

Ideally, all GUID fields should be declared unsigned (see for instance this Microsoft documentation). But some languages (Java, for instance) don't support unsigned integers. So it looks like your C++ GUID structure was defined by a Java programmer.
If you can change the definition of GUID, do that. If not, I am afraid you are going to have to apply your (short) cast to all occurrences of the DEFINE_GUID macro (unless your compiler has some way of disabling this error, as suggested in the comments to your original post). Java programmers have to do this all the time.

Related

How to correct Knapsack compiling error MiniZinc?

What can I do for correcting errors in the following program
item= record( int: id, profit, weight);
set of item: All_Items ;
int :Max_Capacity;
var set of item: Selected_Items;
I have the following code for solving knapsack in MiniZinc, but it has many errors.
constraint sum([holds(X in Selected_Items)*X.weight | X in All_Items])=< Max_Capacity;
constraint Selected_Items >= All_Items;
maximize
sum([holds(S in Selected_Items)*S.profit |S in All_Items]);
Errors List
Compiling knapsack1.mzn
C:/Program Files/MiniZinc IDE (bundled)/examples/knapsack1.mzn:3.7-12:
item= record( int: id, profit, weight);
^^^^^^
Error: syntax error, unexpected record
C:/Program Files/MiniZinc IDE (bundled)/examples/knapsack1.mzn:11.45:
constraint sum([holds(X in Selected_Items)*X.weight | X in All_Items])=< Max_Capacity;
^
Error: syntax error, unexpected $undefined, expecting ]
C:/Program Files/MiniZinc IDE (bundled)/examples/knapsack1.mzn:15.1-8:
maximize
^^^^^^^^
Error: syntax error, unexpected maximize, expecting end of file
Process finished with non-zero exit code 1
Finished in 89msec
Although MiniZinc currently does not contain any record-types (read struct like types), they are a possibility for the future. To prevent breaking models in the future, the word record is therefore already a reserved keyword and can not be used in as an identifier in your model. Changing the name from record to something else will fix your problem.

bpf_asm returns single ' on compile

I am new to Berkeley Packet Filter . I am trying to learn how to hand roll my own bpf code and then compile it using the bpf_asm. I am working on ubuntu 16.04 with kernel 4.4.0-137. I have downloaded the source code and I am working my way through the recommended reading, in Documentation/networking, specifically [filter.txt][1]. I have install binutils, built and installed bpf_asm located in tools/net using the provided makefile. Everything to this point appears to have gone okay. When I run bpf_asm -c bpf_example the program produces a single ' mark to standard out. The code I am trying to compile is the sample code provided in Documentation/networking/filter.txt I am including it here for completeness.
ld [4] /* offsetof(struct seccomp_data, arch) */
jne #0xc000003e, bad /* AUDIT_ARCH_X86_64 */
ld [0] /* offsetof(struct seccomp_data, nr) */
jeq #15, good /* __NR_rt_sigreturn */
jeq #231, good /* __NR_exit_group */
jeq #60, good /* __NR_exit */
jeq #0, good /* __NR_read */
jeq #1, good /* __NR_write */
jeq #5, good /* __NR_fstat */
jeq #9, good /* __NR_mmap */
jeq #14, good /* __NR_rt_sigprocmask */
jeq #13, good /* __NR_rt_sigaction */
jeq #35, good /* __NR_nanosleep */
bad: ret #0 /* SECCOMP_RET_KILL_THREAD */
good: ret #0x7fff0000 /* SECCOMP_RET_ALLOW */
The output that is mentioned in filter.txt is
$ ./bpf_asm -c foo
{ 0x28, 0, 0, 0x0000000c },
{ 0x15, 0, 1, 0x00000806 },
{ 0x06, 0, 0, 0xffffffff },
{ 0x06, 0, 0, 0000000000 },
However, my output is
./bpf_asm -c bpf_example
'
I am clearly messing something up. Can someone point out what I have overlooked, provide suggestions for things to try, or provide additional literature supplementary to filter.txt?
Thank you.
Edit
After reading the code more carefully I found that bpf_exp.y was invoking yyerror. With a message "lex unknown character", which I find somewhat strange since I yanked the text from filter.txt directly into a new file. Playing with bpf_exp.l I found some strange behavior in the production for ., which is used to catch any output that is not caught by the rest of the lexer and output an error. Commenting those out... which is probably a terrible idea, I was able to produce bpf output. However, it isn't equivalent to what filter.txt suggests as the output. It does however contain the same number of lines as the bpf that was input and after running it through the bpf_dbg program I recovered the same output that I input. Is this program no longer maintained? Or I am still not using it correctly? Furthermore, it would seem very difficult for the input bpf program in filter.txt to be output as the suggested program since I don't believe the parser has any sort of optimization for the output code. Hence it would seem like it needs to have the same number of line. Is that a correct assumption?

Fortran error #5082: Syntax error, found IDENTIFIER when expecting one of: <END-OF-STATEMENT> ;

I am "making" a code.
The compilation with make fails producing this error
mpif90 -mkl -O3 -no-prec-div -fpp -openmp -xHost -DMPI -DEFTCOSMOMC -module ReleaseEFTMPI -IReleaseEFTMPI/ -c equations_EFT.f90 -o ReleaseEFTMPI/equations_EFT.o
equations_EFT.f90(267): error #5082: Syntax error, found IDENTIFIER 'EFTCAMBINITIALCONDITIONS' when expecting one of: <END-OF-STATEMENT> ;
module subroutine EFTCAMBInitialConditions( y, EV, tau )
--------------------------^
equations_EFT.f90(267): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: ( % [ . = =>
module subroutine EFTCAMBInitialConditions( y, EV, tau )
----------------------------------------------------------------^
equations_EFT.f90(271): error #6786: This is an invalid statement; an END [MODULE] statement is required.
end subroutine EFTCAMBInitialConditions
--------^
equations_EFT.f90(271): error #6758: This name is invalid; if a name is present, it must match the corresponding interface body name. [EFTCAMBINITIALCONDITIONS]
end subroutine EFTCAMBInitialConditions
-----------------------^
equations_EFT.f90(268): error #6457: This derived type name has not been declared. [EVOLUTIONVARS]
type(EvolutionVars) EV
-----------------^
equations_EFT.f90(269): error #6683: A kind type parameter must be a compile-time constant. [DL]
real(dl) :: y(EV%nvar)
-----------------^
equations_EFT.f90(269): error #6535: This variable or component must be of a derived or structure type [EV]
real(dl) :: y(EV%nvar)
--------------------------^
equations_EFT.f90(269): error #6460: This is not a field name that is defined in the encompassing structure. [NVAR]
real(dl) :: y(EV%nvar)
-----------------------------^
equations_EFT.f90(269): error #6223: A specification expression is invalid. [NVAR]
real(dl) :: y(EV%nvar)
-----------------------------^
equations_EFT.f90(270): error #6683: A kind type parameter must be a compile-time constant. [DL]
real(dl) :: tau
-----------------^
equations_EFT.f90(269): error #6279: A specification expression object must be a dummy argument, a COMMON block object, or an object accessible through host or use association [EV]
real(dl) :: y(EV%nvar)
--------------------------^
compilation aborted for equations_EFT.f90 (code 1)
I attach the snippet from equations_EFT.f90
interface
module subroutine EFTCAMBInitialConditions( y, EV, tau )
type(EvolutionVars) EV
real(dl) :: y(EV%nvar)
real(dl) :: tau
end subroutine EFTCAMBInitialConditions
end interface
Is there something wrong in this snippet? It is strange because this is distributed software, but I have literally just followed the instruction to make the code.
The code of the question is an example of using submodules, a feature newly introduced into Fortran in the 2008 revision. To compile this code you will need a compiler which understands this concept.
The GNU and Intel compilers are examples of such, but you will need an appropriate version.

CLR IL-significance of square bracket on .locals init

I am trying to generate a dynamic assembly using Reflection & Emit in .NET. I am getting an error, "Common Language Runtime detected an invalid program." I created another program which has the functionality I want using hard-coded types. The functionality I am trying to write will ultimately use dynamic types, but I can use ILDasm to see the IL I need to generate. I am comparing the IL I am generating with the IL which the compiler generates. In the .locals init declaration of one method I see there is an extra item in the compiler-generated code,
compiler-generated:
.locals init ([0] class [System.Core]System.Linq.Expressions.ParameterExpression CS$0$0000,
[1] class [System.Core]System.Linq.Expressions.ParameterExpression[] CS$0$0001)
mine:
.locals init (class [System.Core]System.Linq.Expressions.ParameterExpression V_0,
class [System.Core]System.Linq.Expressions.ParameterExpression[] V_1)
I don't understand the significance of the "[0]" and "[1]" in the compiler-generated code. Can anyone tell me what it means?
As a more general question, I can follow most ILDasm output without too much trouble. But every so often I run across a problematic expression. For instance, in this line from ILDasm
callvirt instance class [EntityFramework]System.Data.Entity.ModelConfiguration.EntityTypeConfiguration`1<!!0> [EntityFramework]System.Data.Entity.DbModelBuilder::Entity<class DynamicEdmxTrial.HardFooAsset>()
the "!!0" probably refers to the generic type of the Entity<>, but I don't know for sure, and I wonder if there is a key to ILDasm output that would explain its more obscure output to me.
The specification is freely available here. It takes a little getting used to, but most details are easily found once you figure out the structure.
!! is listed in II.7.1 Types:
Type ::= | Description | Clause
‘!’ Int32 | Generic parameter in a type definition, | §II.9.1
| accessed by index from 0 |
| ‘!!’ Int32 | Generic parameter in a method | §II.9.2
| definition, accessed by index from 0 |
...
In other words, inside a method that C# would call f<T, U>(), !!0 would be T, and !!1 would be U.
However, the [0] is a good question. The spec does not seem to address it. The .locals directive is described in II.15.4.1.3 The .locals directive, which lists the syntax as
MethodBodyItem ::= ...
| .locals [ init ] ‘(’ LocalsSignature ‘)’
LocalsSignature ::= Local [ ‘,’ Local ]*
Local ::= Type [ Id ]
There is nothing that seems to allow [0] there unless it is part of a Type, and Type does not allow anything starting with [ either. My guess is that this is an undocumented peculiarity specific to Microsoft's implementation, intended to help the human reader see that location 0 is local variable CS$0$0000, for when the generated instructions access local variables by index.
Experimenting with ILAsm shows that this is exactly what it means. Taking a simple C# program:
static class Program {
static void Main() {
int i = 0, j = 1;
}
}
and compiling and then disassembling it (csc test.cs && ildasm /text test.exe >test.il) shows:
....
.locals init (int32 V_0,
int32 V_1)
IL_0000: nop
IL_0001: ldc.i4.0
IL_0002: stloc.0
IL_0003: ldc.i4.1
IL_0004: stloc.1
IL_0005: ret
....
Modifying the .locals to
.locals init ([0] int32 V_0, [0] int32 V_1)
gives a useful warning message:
test.il(41) : warning : Local var slot 0 is in use
And indeed, declaring variables of different types, then reordering them using [2], [1], [0], assembling and immediately disassembling the result, shows that the variables got reordered.

Compiling OpenMCU in Linux (Fedora12)

I am tring to compile OpenMCU in fedora 12. Since the orignal project was compiled in VC++, it has some compatiility issues with gcc.
I am using gcc 4.4.4 and febora 12.
The error shows somehting like this.
In file included from mcu.h:84,
from main.cxx:56:
filemembers.h:123: error: ISO C++ forbids declaration of ‘deque’ with no type
filemembers.h:123: error: typedef name may not be a nested-name-specifier
filemembers.h:123: error: expected ‘;’ before ‘<’ token
filemembers.h:124: error: ISO C++ forbids declaration of ‘FilenameList’ with no type
filemembers.h:124: error: expected ‘,’ or ‘...’ before ‘&’ token
In file included from mcu.h:84,
from main.cxx:56:
filemembers.h:149: error: ‘FilenameList’ does not name a type
make: *** [obj_linux_x86_r/main.o] Error 1
when checked in the source code of that perticular file it was something like this...
class ConferenceFileMember : public ConferenceMember
{
PCLASSINFO(ConferenceFileMember, ConferenceMember);
public:
ConferenceFileMember(Conference * conference, const PFilePath & _fn, PFile::OpenMode mode);
*typedef std::deque<PFilePath> FilenameList; //Line 123..*
ConferenceFileMember(Conference * conference, const FilenameList & _fns, PFile::OpenMode mode);
~ConferenceFileMember();
void Unlisten();
Seems to be a simple syntax issue. Can someone help me in this regards?
Thanx in advance..
Looks like std::deque is not defined. Did you #include <deque>?

Resources