TYPE CAST question. : C

May 17, 2008 11:34am pdt

1. Infinity08 232,821
2. evilrix 124,801
3. jkr 68,534
4. ozo 48,635
5. josgood 26,525
6. itsmeand... 22,659
7. jaime_ol... 19,280
8. Kdo 18,780
9. sunnycoder 17,740
10. fridom 17,093
11. Gurudenis 7,180
12. hielo 6,200
13. angelIII 6,080
14. duncan_roe 6,000
15. ravenpl 5,590

1. sunnycoder 804,283
2. Infinity08 765,680
3. Kdo 745,278
4. jkr 679,296
5. ozo 390,943
6. grg99 296,356
7. PaulCaswell 295,931
8. brettmjo... 182,528
9. jaime_ol... 174,952
10. ankuratvb 157,866
11. evilrix 154,666
12. itsmeand... 151,125
13. fridom 147,697
14. imladris 137,967
15. cwwkie 129,383

04.08.2008 at 03:30PM PDT, ID: 23306521

	[x] Attachment Details

[x]

The Solution Rating System

With so many solutions, how can you tell which solutions are most likely to help you and which ones are not? To provide you with a tool to use, we rate our solutions based on various elements that most accurately determine if a solution is a quality solution. To explain what factors affect the solution rating, here are the elements we take into consideration when formulating our solution rating.

The Grade of the Solution
The Zone Rank of the Expert Providing the Solution
The Number of Author and Expert Comments
The Number of Experts Contributing
The Feedback of the Community

Your Input Matters
Because of the way the system is set up, the most important variable in this equation is you. As a member of Experts Exchange, you are able to cast your vote on the quality of the solutions in regard to how complete, accurate, helpful and easy to understand each solution is. When you provide your feedback, each rating is adjusted accordingly. So, if you see a solution that has a poor rating that you think is a good solution, let us know by rating it. As you do, the rating will be adjusted and will become more accurate for other members of our site.

If you have any suggestions that you would like to make for our rating system, please ask a question in the Suggestions Zone of Community Support.

Thank you!

5.6

TYPE CAST question.

Zone: C Programming Language

Tags: C

Hello,

Assume you have a simple array of char as myarr[2] = {1,0}

by doing a type cast from char to int using *(int*) myarr[0] sometimes I get 1 and sometimes I get a very big negative number. Why it works fine when it is in
main() body but same function won't work properly in a user-defined function?

Thanks.
Deleted by modus_operandi, no points refunded: 5/13/2008 6:57:24 AM

Start your free trial to view this solution

Question Stats

Zone: Programming

Question Asked By: akohan

Solution Provided By: ozo

Participating Experts: 5

Solution Grade: A

Translate:

Loading Advertisement...

Microsoft

Internet Protocols
Applications

Development
OS

Hardware
Windows Security

Apple

Operating Systems
Hardware

Programming
Networking

Software

Internet

Search Engines
File Sharing
WebTrends / Stats
Spy / Ad Blockers

Web Browsers
New Net Users
Web Development
Chat / IM

Anti Spam
Web Servers
Anti-Virus
Email Clients

Gamers

Tips
Online / MMORPG
Puzzle
Emulators

Action / Adventure
Role Playing
Consoles
Game Programming

Strategy
Sports
Misc
Computer Games

Digital Living

Hardware
New Net Users
New Users

Software
Digital Music
Gaming World

Home Security
Apple
Networking Hardware

Virus & Spyware

Vulnerabilities
IDS
Encryption
Anti-Virus

Operating Systems Security
Software Firewalls
WebApplications
Cell Phones

Operating Systems
Internet
Hardware Firewalls

Hardware

Handhelds / PDAs
Displays / Monitors
Components
Networking Hardware

Peripherals
Laptops/Notebooks
Storage
Servers

Desktops
New Users
Misc
Apple

Software

System Utilities
Industry Specific
Network Management
Photos / Graphics
Page Layout
VMWare
Misc
Web Development

OS
CYGWIN
Voice Recognition
Message Queue
Quality Assurance
Security
Firewalls
MultiMedia Applications

Development
Database
Office / Productivity
Business Management
OS/2 Apps
Server Software
Internet / Email

ITPro

OS
Storage
Encryption
Operating Systems Security
Apple Hardware
Laptops & Notebooks
Servers
Networking Hardware
Peripherals

Devices
Displays / Monitors
WebTrends / Stats
Search Engines
Firewalls
WebApplications
IDS
Vulnerabilities
Email Clients

File Sharing
Spy / Ad Blockers
Web Browsers
Web Servers
Networking
Anti-Virus
Chat / IM
Anti Spam

Developer

Web Servers
Web Browsers
Game Programming
Dev Tools
Industry Specific
Office / Productivity

Database
CYGWIN
Web Development
Search Engines
File Sharing
WebTrends / Stats

Programming
Content Management
Application Servers
Protocols

Storage

Removable Backup Media
Storage Technology
Servers

Grid
Remote Access
Backup / Restore

Misc
Hard Drives

Miscellaneous
Security
Development
Linux
VMWare

MainFrame OS
Unix
Apple
OS / 2
AS / 400

BeOS
Microsoft
VMS / OpenVMS

Database

Oracle
Miscellaneous
MySQL
Software
Sybase
Contact Management
PostgreSQL
Data Manipulation
Clarion
InterSystems Cache

Siebel
MUMPS
OLAP
SQLBase
SAS
GIS & GPS
4GL
Berkeley DB
DB2
Informix

Interbase / Firebird
FoxPro
Reporting
LDAP
Filemaker Pro
MS SQL Server
dBase
MS Access

Security

Misc
Web Browsers
Software Firewalls
Operating Systems Security
File Sharing

Spy / Ad Blockers
Vulnerabilities
WebApplications
IDS
Anti-Virus

Encryption
Anti Spam
Email Clients
VPN
Chat / IM

Programming

Editors IDEs
Installation
Handhelds / PDAs
Multimedia Programming
System / Kernel

Algorithms
Game
Signal Processing
Project Management
Open Source

Database
Misc
Languages
Processor Platforms
Theory

Web Development

Scripting
Blogs
Web Servers
Software
Search Engines
Web Graphics
Images

Internet Marketing
Images and Photos
Components
Document Imaging
Web Languages/Standards
Illustration
WebApplications

Fonts
WebTrends / Stats
Authoring
Digital Camera Software
Miscellaneous

Networking

Protocols
Apple Networking
Network Management
Message Queue
Application Servers
Content Management
File Servers
Email Servers
Misc
Java Editors & IDEs

Wireless
Networking Hardware
Backup / Restore
System Utilities
ISPs & Hosting
Web Servers
Storage Technology
Removable Backup Media
Servers
Broadband

Grid
OS / 2
Novell Netware
Unix Networking
Windows Networking
Security
Telecommunications
Operating Systems
Linux Networking

Other

Community Advisor
Lounge
Community Support
New Net Users

Philosophy / Religion
Math / Science
Miscellaneous
URLs

Expert Lounge
Politics
Puzzles / Riddles

Community Support

Suggestions
New to EE
New Topics
Community Advisor

CleanUp
Announcements
General

Feedback
Input
EE Bugs

04.08.2008 at 03:36PM PDT, ID: 21310252

Rank: Sage

Infinity08:

You can't do a typecast like that. Can you show the exact code you're using, because *(int*) myarr[0] will most likely crash.

What is it that you're trying to do ?

04.08.2008 at 03:36PM PDT, ID: 21310253

Rank: Wizard

ozo:

Do you mean *( (int *)myarr )

04.08.2008 at 03:49PM PDT, ID: 21310326

akohan:

Hi Infinity,

Ok, this is not my code. I just ran into this small code and I was asked why it causes different results. I think since the array has char data type and int (4 bytes) so compiler is expecting to see 4 bytes so it goes beyond 1 and sometimes retuns a random number which leads to a number out of range.
I tried it. as long as I use two bytes for the array I get a big number but when I increase the size of array from 2 to 4 it works fine and returns 1.

This is what I'm getting:

Convert chas to int = 2052063233
2nd convert 2050490369

But the person gets once 1 and once a big number (negative)

Regards.

                       
                                int main()
{
 
   char twoc[2]={1,0};
   
   printf("\nConvert char to int = %d\n\n", *(int*)twoc);
   printf("\n2nd convert %d\n\n", char2int());
   
   return 0;
}
 
int char2int(void)
{
   char c[2]={1,0};
 
   return (*(int*)c);
}

Open in New Window

04.08.2008 at 03:49PM PDT, ID: 21310332

akohan:

Hello Ozo,

Yes, you are right. that is the right syntax.

04.08.2008 at 04:00PM PDT, ID: 21310401

Rank: Wizard

ozo:

if sizeof(int) > 2 the result will be undefined, since you don't know what is at c[2]
even if sizeof(int)==2 the result will be implementation defined, since it could depend on the byte order representation of ints

Accepted Solution

04.08.2008 at 04:08PM PDT, ID: 21310450

akohan:

but why it works fine but the same statement in a different function returns wrong value?

04.08.2008 at 04:12PM PDT, ID: 21310466

Rank: Wizard

ozo:

when the result is undefined, you cannot depend on it getting the "right" value, and you cannot depend on it getting the "wrong" value.
in practice, it probably depends on whether whatever happened to be stores next to the arrays contained 0

Assisted Solution

04.08.2008 at 11:52PM PDT, ID: 21312358

Gurudenis:

myarr[2] = {1,0} has a size of two bytes. Now, when casting a pointer to a two-byte array, you must cast it so something that is two bytes long at most. However, int is 4 bytes long, so you happen to read the two bytes in myarr and another two bytes of some unknown memory data past the end of the array. Of course you end up with unexpected numbers. To correct the code:
1) either use short instead of int (short has 2 bytes)
2) or use a 4-byte array, like myarr[4] = {1,0,0,0};

04.08.2008 at 11:58PM PDT, ID: 21312390

Rank: Sage

Infinity08:

>> int is 4 bytes long

>> (short has 2 bytes)

Not necessarily. It depends on the system you compiled the code on.

What ozo said here is correct :

http://www.experts-exchange.com/Programming/Languages/C/Q_23306521.html#a21310401

04.09.2008 at 12:03AM PDT, ID: 21312411

Gurudenis:

Yup, you're right, Infinity08. But the idea of my comment was to explain what was happening because we all know int is 4 bytes on most systems. Assuming sizeof(int)!=4 would really make the explanation harder to understand, that's all.

04.09.2008 at 04:45AM PDT, ID: 21313816

Rank: Guru

evilrix:

>> we all know int is 4 bytes on most systems
We don't know this at all and to assume so is dangerous and will, at best, result in non-portable code! Specifically, the standard states, "A plain int object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header <limits.h>)." This is all you know about the size of an int.

If your code must make this assumption then you can enforce this at compile time using static asserts (either something home-grown or something like BOOST_STATIC_ASSERT).

It should also be noted that when casting from one pointer type to another the only safe operation you can perform is to cast back to the original type and any other operation is, at best, undefined. To this fact ozo and Infinity08 have already eluded.

04.09.2008 at 07:44AM PDT, ID: 21315425

Gurudenis:

2 evilrix:
You will no doubt have noticed that akohan indicated their level of proficiency in C Programming Language as "Beginner on this subject". While I'm well aware of the Standard and its position regarding the size of integer type, it would be really hard to explain the answer to the original question if I had to say things that (as we both know perfectly well) probably will not affect akohan's code that is being discussed in this particular thread. And even if sizeof(int)!=4 on akohan's PC, this will soon become obvious as a result of their comments, but by default, especially when discussing a beginner's question, it's usually assumed that int is a 4-byte type and the Earth is round (technically Earth is a geoid, but what if Copernicus tried to explain that to the public? He'd be burnt twice). Therefore, I only tried to make things understandable by omitting a detail that would or would not surface later.

>> result in non-portable code
Does the original question sound to you like portability is the most important immediate concern? To me, it sounded like akohan wondered what was going on in this code, which is exactly what the answer was about.

PS. Which modern platforms can you think of that have sizeof(int)!=4 ? What is the probability of akohan or anyone else working on one of them?

04.09.2008 at 08:14AM PDT, ID: 21315793

Rank: Guru

evilrix:

akohan seeks understanding and by providing imprecise answers you risk misunderstanding, IMO that's worse than not understanding! The standard is explicit about not defining types to have any specific size and to suggest otherwise is misleading.

The answers given by ozo and Infinity08 collectively provide no misleading information or assumptions and correctly identify that this code is non-portable and the behavior cannot be guaranteed to be consistent or safe.

04.09.2008 at 09:26AM PDT, ID: 21316495

Rank: Sage

Infinity08:

>> probably will not affect akohan's code that is being discussed in this particular thread.

Except that it DID affect his code, as the code he posted assumes that an int is 2 bytes wide. So, talking about the width of an int is relevant, and indeed necessary to explain the behavior he was witnessing.

I don't think the width of an int is a "detail", especially in a question like this, so I don't think omitting it adds to the clarity of the answer. In fact, it will create a false understanding, which will inevitably cause problems later on.

04.09.2008 at 09:35AM PDT, ID: 21316587

Gurudenis:

By giving a detailed fully blown technically correct standard-compliant answer, you risk not being understood at all when the question was asked by someone who feels they do not have firm understanding of the subject. An answer that is plain right on 99.9% modern systems is better than an answer that is true for 100% systems but simply not understandable by the target audience.

I used to be a C++ teacher. Imagine me explaining things in dull terms of the Standard - I'd have lost my job sooner than I'd say "A plain int object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header <limits.h>)".