hand may be tedious and error-prone. Portable cross-language signatures will require detailed understanding of both languages, which a programmer may lack. Integrating two or more programming languages into a single executable relies upon knowing how to interface the function calls, argument list and global data structures so the symbols match in the object code during linking. Byte alignment can be a source of data corruption if memory boundaries between the programming languages are different. Each language may also structure data differently. 6.46.2 Cross reference MISRA C 2012: 1.1 MISRA C++ 2008: 1-0-2 6.46.3 Mechanism of failure When the library and the application in which it is to be used are written in different languages, the specification of signatures is complicated by inter-language issues. As used in this vulnerability description, the term library includes the interface to the operating system, may be specified only for the language used to code the operating system itself. In this case, any program written in any other language faces the inter-language interoperability issue of creating a fully-functional signature. When the application language and the library language are different, then the ability to specify signatures according to either standard may not exist, or be very difficult. Thus, a translator-by-translator solution may be needed, which maximizes the probability of incorrect signatures (since the solution must be recreated for each translator pair). Incorrect signatures may or may not be caught during the linking phase. 6.46.4 Applicable language characteristics This vulnerability description is intended to be applicable to languages with the following characteristics: Languages that do not specify how to describe signatures for subprograms written in other languages. 6.46.5 Avoiding the vulnerability or mitigating its effects Software developers can avoid the vulnerability or mitigate its ill effects in the following ways: Use tools to create the signatures. Avoid using translator options or language features to reference library subprograms without proper signatures. 6.46.6 Implications for standardization In future standardization activities, the following items should be considered:
hand may be tedious and error-prone. Portable cross-language signatures will require detailed understanding of both languages, which a programmer may lack. Integrating two or more programming languages into a single executable relies upon knowing how to interface the function calls, argument list and global data structures so the symbols match in the object code during linking. Byte alignment can be a source of data corruption if memory boundaries between the programming languages are different. Each language may also structure data differently. 6.46.2 Cross reference MISRA C 2012: 1.1 MISRA C++ 2008: 1-0-2 6.46.3 Mechanism of failure When the library and the application in which it is to be used are written in different languages, the specification of signatures is complicated by inter-language issues. As used in this vulnerability description, the term library includes the interface to the operating system, may be specified only for the language used to code the operating system itself. In this case, any program written in any other language faces the inter-language interoperability issue of creating a fully-functional signature. When the application language and the library language are different, then the ability to specify signatures according to either standard may not exist, or be very difficult. Thus, a translator-by-translator solution may be needed, which maximizes the probability of incorrect signatures (since the solution must be recreated for each translator pair). Incorrect signatures may or may not be caught during the linking phase. 6.46.4 Applicable language characteristics This vulnerability description is intended to be applicable to languages with the following characteristics: Languages that do not specify how to describe signatures for subprograms written in other languages. 6.46.5 Avoiding the vulnerability or mitigating its effects Software developers can avoid the vulnerability or mitigate its ill effects in the following ways: Use tools to create the signatures. Avoid using translator options or language features to reference library subprograms without proper signatures. 6.46.6 Implications for standardization In future standardization activities, the following items should be considered:
ISO-IECJTC1-SC22-WG23_N0548-tr24772-1-draft-edits-after-meeting-35-20150326.docx