Index
> High Level Languages > Need help in C (Pointers and References)Goto page 1, 2 Next |
| Author |
|
|
dancho 13 Nov 2012, 17:33
There are 2 ways to acces registers by C compiler/linker ( PellesC in this case ), by
1.) inline assembler , or by 2.) separated assembled module linked to main file so 1.example : Code: #include <stdio.h> int main() { int temp=0x10; __asm { mov eax,temp mov ax,word[temp] mov al,byte[temp] } return 0; } and for the 2.example just assemble asm file as mscoff and link it with main file , btw PellesC has assembler too , masm style , try it... |
|||
13 Nov 2012, 17:33 |
|
|
AsmGuru62 13 Nov 2012, 22:12
hmmm... I am not sure if you answered the exact question which was asked.
|
|||
|
13 Nov 2012, 22:12 |
|
|
Overflowz 13 Nov 2012, 22:22
AsmGuru62 is right, I know already inline ASM, but I need the same syntax in C.
for example (how I imagine code) Code: char simple[] = "Apple"; char *sample = *simple; --- is equal tu mov eax,byte[simple] I don't understand pointers and references in C.. |
|||
|
13 Nov 2012, 22:22 |
|
|
pabloreda 14 Nov 2012, 00:10
in 32bits compiler (GCC)
Code: 1) mov eax,[ptr] int a,*ptr a=*ptr; 2) mov ax,word[ptr] short w; w=*(short*)ptr 3) mov al,byte[ptr] char c; c=*(char*)ptr |
|||
|
14 Nov 2012, 00:10 |
|
|
dancho 14 Nov 2012, 08:56
uf yeah sorry Overflowz , I overlooked word translate,
my bad... |
|||
|
14 Nov 2012, 08:56 |
|
|
Overflowz 14 Nov 2012, 12:30
Thank you pabloreda, now I understand how it works
@dancho you already gave me useful information, thank you  |
|||
|
14 Nov 2012, 12:30 |
|
|
f0dder 15 Nov 2012, 00:17
Also, slight nit-pick: there's no "references" in C, that's a C++ feature... and they behave differently from pointers in syntactical (sugar) as well as functional ways.
And furthermore: you can access, say, *(mypointer + 42) - the offset part is in multiples of the pointer base type, though, and not a simple byte-offset as an assembly programmer would probably expect. It's probably a bit more logical if you realize that "*(mypointer + 42)" is the same as "mypointer[42]". |
|||
|
15 Nov 2012, 00:17 |
|
|
farrier 15 Nov 2012, 04:56
Overflowz,
This site has helped me: http://www.codeproject.com/Articles/7042/How-to-interpret-complex-C-C-declarations farrier _________________ Some Assembly Required It's a good day to code! U.S.Constitution; Bill of Rights; Amendment 1: ... the right of the people peaceably to assemble, ... The code is dark, and full of errors! |
|||
|
15 Nov 2012, 04:56 |
|
|
rugxulo 25 Nov 2012, 01:56
To be completely honest, it's a mess. I'm far from a pro, and I definitely don't want to complain about C, it's not so bad, but it's indeed a bit weakly typed (due to various reasons, e.g. heritage from B) and a bit confusing. It makes it harder to write portable code (esp. when type sizes vary across platforms). You have to be very very careful and use limits.h, float.h, inttypes.h, stdint.h, ptrdiff_t, size_t, int32_t, etc.
Part of the problem is also that arrays decay into pointers, which is C's way of avoiding strictly sized arrays (a complain about original Pascal that was fixed in later derivatives). Also, unlike "original" Pascal, C can get/use the absolute address of anything. Hence it's easy to misuse pointers or make sloppy errors. Various add-on utilties and workarounds have been used (cdecl, lint, valgrind, Boehm gc) to avoid such errors. I wish I had an easy answer, but the simple truth is that you should probably?? avoid pointer arithmetic if at all possible. Code: #include <stdio.h> #include <stdlib.h> int main(void) { static int* pointer_to_int = NULL; static int moo = 0x5150; pointer_to_int = &moo; printf("0x%x",*pointer_to_int); return EXIT_SUCCESS; } |
|||
|
25 Nov 2012, 01:56 |
|
|
Tyler 30 Dec 2012, 04:48
rugxulo wrote: I wish I had an easy answer, but the simple truth is that you should probably?? avoid pointer arithmetic if at all possible. But, if, for whatever reason, you *need* to do actual pointer arithmetic, use uintptr_t from stdint.h. It's basically a type which can represent a void pointer as an integer, and be cast back to a valid void pointer. Just FYI, void pointers are like the real pointers from ASM, all other pointers behave weirdly to an ASM programmer (except char, but that's only because it happens to be a byte). The reason for uintptr_t is because pointer arithmetic is undefined for void* by the standard. For example: Code: void *t = NULL; t += 1; |
|||
|
30 Dec 2012, 04:48 |
|
|
revolution 30 Dec 2012, 05:01
Tyler wrote: The reason for uintptr_t is because pointer arithmetic is undefined for void* by the standard. For example: Code: void *t = 0; t += 1; |
|||
|
30 Dec 2012, 05:01 |
|
|
HaHaAnonymous 30 Dec 2012, 12:09
[ Post removed by author. ]
Last edited by HaHaAnonymous on 28 Feb 2015, 22:08; edited 1 time in total |
|||
|
30 Dec 2012, 12:09 |
|
|
revolution 30 Dec 2012, 12:59
HaHaAnonymous wrote:
|
|||
|
30 Dec 2012, 12:59 |
|
|
typedef 30 Dec 2012, 13:08
revolution wrote:
If using windows SDK yes. Otherwise you have to define it somewhere else. What the op has to know is that pointers are just numbers, holding an address to data in memory |
|||
|
30 Dec 2012, 13:08 |
|
|
revolution 30 Dec 2012, 13:38
typedef wrote: What the op has to know is that pointers are just numbers, holding an address to data in memory |
|||
|
30 Dec 2012, 13:38 |
|
|
revolution 30 Dec 2012, 13:43
typedef wrote: If using windows SDK yes. Otherwise you have to define it somewhere else. |
|||
|
30 Dec 2012, 13:43 |
|
|
f0dder 30 Dec 2012, 13:59
Tyler wrote:
For what it's worth: GCC 4.4.5 compiles without a warning in C mode, but gives "warning: pointer of type 'void *' used in arithmetic" in C++ mode. When run (64bit linux, compiled to 64bit ELF) it indeed produces '1'. Visual C++ 17.00 (the one from VS2012 + Update 1) I get "void.cpp(5) : error C2036: 'void *' : unknown size" which might be against the spec (which would be bad), but at least is sane
revolution wrote:
For C, section 5.4, Address Arithmetic. NULL is defined in stdio.h, and there's nothing special about it, it's just a symbolic define for 0. In C++, because of tighter type checking and how some library vendors defined NULL, it has been better to use literal 0... C++11 has finally introduced "nullptr". ... IMHO, the way pointers are handled in C/C++ makes sense - most of the time you want to deal with elements rather than memory offsets, and when you need to deal with memory offset you still can do that - but the common case is simpler & shorter. Also, as revolution has touched on, not everybody lives in a flat memory model (and then there's things like structure padding), so it'd be nasty to have portable pointer arithmetic in your code if you were dealing with byte- instead of element-offsets. Also, even in flat address space programs, not all pointers are necessarily equally wide. C++ member function pointers come to mind _________________  - carpe noctem |
|||
|
30 Dec 2012, 13:59 |
|
|
f0dder 30 Dec 2012, 14:22
OK, just skimmed through the pointer arithmetic part (ANSI C 2nd. ed.) as well as references to "void" and "void*" (and even threw in "sizeof" for good measure) from the index... and didn't find anything that seemed relevant. IMHO arithmetic on "void*" doesn't make sense, and if one could talk about "the size of nothing" at all, it should at least be 0 and not 1
EDIT: for C++, it's quite clear: Quote: A pointer to any type of object can be assigned to a variable of type void*, a void* can be assigned to another void*, void*s can be compared for equality and inequality, and a void* can be explicitly converted to another type. Other operations would be unsafe because the compiler cannot know what kind of object is really pointed to. Consequently, other operations result in compile-time errors. |
|||
|
30 Dec 2012, 14:22 |
|
|
typedef 30 Dec 2012, 18:15
I love C as much as I love Assembly.
nothing wrong with it. |
|||
|
30 Dec 2012, 18:15 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|