Welcome, Guest
You have to register before you can post on our site.

Username
  

Password
  





  Underlying type of character constants and \"plain char
Posted by: Shane Swenson - 15-11-2006, 12:40 AM - Forum: 6.10 Arithmetic Type Conversions - Replies (4)

We're wondering if rule 10.1 applies to character constants and the \"plain char\" type, and, if so, what their underlying types are. For example,

Code:
char_t c1 = 'a';
char_t c2 = 'abc';
From the discussion in 6.10.4, we expect that the underlying types of 'a' and 'abc' are 8 bit signed and 32 bit signed, respectively, on a target with 8 bit chars.

The underlying types of c1 and c2 are less clear. We could treat \"plain char\" similarly to signed char or unsigned char based on the implementation's signedness of \"plain char\", or from the discussion following rules 6.1 and 6.2, we could deduce that \"plain char\" is distinct from signed char and unsigned char with respect to rule 10.1.

If rule 10.1 applies to character constants, we expect that the assignment to c2 violates rule 10.1 because it probably requires a conversion of the character constant to a narrower type. If the \"plain char\" type is unsigned on the target system, the assignment to c1 could be considered as violating rule 10.1 because it requires a conversion from a signed type to an unsigned type.

If the \"plain char\" type is considered distinct from the signed char and unsigned char types, both assignments would violate rule 10.1 unless the underlying type of a character constant is also \"plain char\", though this also seems problematic since, for example, the plain char type usually can't represent the value 'abc'.

What are the Committee's positions on these issues?

Print this item

  18.4 Unions shall not be used...
Posted by: rahul_mishra - 13-11-2006, 12:58 PM - Forum: 6.18 Structures and Unions - Replies (1)

Is it that unions can be declared or defined but not used? i.e.; Do we need to flag a violation even on the declaration or definition of the union? or is it only on the usage of it.

Print this item

  Rules 11.4 and 11.5: addressing only explicit cast ?
Posted by: lv - 19-10-2006, 12:06 PM - Forum: 6.11 Pointer Type Conversions - Replies (1)

Theses both rules (11.4 and 11.5) prevents against bad casting between pointers.


In my understanding, these both rules are applicable for explicit and implicit cast: The problematic is the same for explicit or implicit cast.


The understanding of my MISRA-checker-tools is that these rules address only explicit cast (these rules give only explicit cast example, and anywhere implicit cast is mentioned).
And this pointer implicit cast is not covered by another MISRA rule (Rules 10.1 and 10.2 don't address pointers cast but only integer and float implicit casts.)

Could you confirm which understanding is the good one?

Thanks in advance.

Print this item

  11.2 Interpretation
Posted by: elmar - 16-10-2006, 06:54 AM - Forum: 6.11 Pointer Type Conversions - Replies (1)

With rule 11.2,

\"Conversions shall not be performed between a pointer to object and any type other than an integral type, another pointer to object type or a pointer to void\"

my understanding of the term

\"another pointer to object type\"

is, that for example code like

int* Source;
long* Target;
Target = (long*)Source;

doesn't violate this rule (but at least violates rule 11.4);
but our misra checker tool's interpretation of this rule is more like

\"another pointer to same object type\"

therefore it emits a misra violation for code structures like the one mentioned above.

To help me out, could you please tell me which interpretation is right?

Thanks in advance,
elmar

Print this item

  unnamed members of a structure
Posted by: rahul_mishra - 13-10-2006, 04:37 AM - Forum: 6.18 Structures and Unions - Replies (1)

Please let me know \"How do we access an unnamed member of a structure\"?

Its quite natural to use bitfields as unnamed members of a structure especially for padding. But, how do we access those unnamed members. Do we have to increment the pointer to access it? if yes, please illustrate it with an example.

Print this item

  12.4 and Non-Returning Functions
Posted by: gs - 03-10-2006, 01:33 PM - Forum: 6.12 Expressions - Replies (1)

Hi,
12.4 prohibits side-effects on the right hand side of '&&' or '||'. What if, on the right hand side, I place a function with no side-effects, provided it returns, but which does contain side-effects if it does not return (e.g., an assertion which writes to a log file of some sort)? Is such a function allowed on the right hand side of the logical operators?

Print this item

  8.5 and a C99 Extension
Posted by: gs - 03-10-2006, 01:26 PM - Forum: 6.8 Declarations and Definitions - Replies (1)

Hi,
I use 'inline' within my code. Not wanting to go into any details, let us just suffice it to say I feel sufficient reason exists for me to do so. Does 8.5 apply to inline functions? Does the use of 'inline' supercede the restriction of 0 function definitions per header?

Print this item

  64 bit data types?
Posted by: mhabermann - 22-09-2006, 12:05 PM - Forum: 6.6 Types - Replies (1)

Hello!

Rule 6.3 of MISRA-C lists the typedefs for uint64_t and int64_t, which I believe are not used anymore in the standard and should be disallowed by C90.

Can you confirm that uint64_t and int64_t datatypes are not allowed?


Best Regards

Michael

Print this item

  18.1 All structure or union types shall be complete at...
Posted by: srogers - 18-09-2006, 12:16 PM - Forum: 6.18 Structures and Unions - Replies (1)

Quote:18.1 All structure or union types shall be complete at the end of a translation unit.
A complete declaration of the structure or union shall be included within any translation unit that refers to that structure.

If my interpretation of this rule is correct then it prohibits the use of opaque pointers. (I wish to use these to hide the contents of structures, so that access is only via certain functions.)

Was the prohibition of opaque pointer use deliberate? If so what are the concerns?

Print this item

  Date for Technical Clarification Misra c:2004
Posted by: Hammer - 31-07-2006, 10:46 AM - Forum: General Questions - No Replies

Hello. I have some open qusetions on the forum and am also interested in some of the other open questions anout MISRA C: 2004.

I have heard that a TC will be written or already has been written to clarify some of these topics.

If possible it would be great if you could provide an estimated date that this will me made available.

Thanks a lot

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,172
» Latest member: jeongsang kim
» Forum threads: 998
» Forum posts: 2,752

Full Statistics

Online Users
There are currently 228 online users.
» 0 Member(s) | 226 Guest(s)
Bing, Google

Latest Threads
Rule 6.2.1: non-inline co...
Forum: 4.6 Basic concepts
Last Post: cgpzs
22-11-2024, 10:11 AM
» Replies: 0
» Views: 38
Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: stephanmuench
21-11-2024, 01:12 PM
» Replies: 0
» Views: 51
A18-9-4
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
23-10-2024, 12:04 PM
» Replies: 2
» Views: 401
A8-4-5: are partial moves...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
22-10-2024, 02:03 PM
» Replies: 1
» Views: 339
model information blocks ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:27 PM
» Replies: 1
» Views: 4,460
MISRA AL SLSF - Rule 043I
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:11 PM
» Replies: 1
» Views: 8,876
MISRA AC EC guidelines
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:21 AM
» Replies: 4
» Views: 15,526
News on future releases
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:05 AM
» Replies: 1
» Views: 5,708
Signal naming convention ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 07:57 AM
» Replies: 1
» Views: 7,260
Rule 7.0.2: operator cons...
Forum: 4.7 Standard conversions
Last Post: karos
14-10-2024, 08:52 PM
» Replies: 2
» Views: 452