flat assembler
Message board for the users of flat assembler.

Index > Heap > HLL programmers are dumb

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
Turbo Lover



Joined: 22 Feb 2013
Posts: 32
Turbo Lover
?????????????
$ readelf -l /bin/ls

Elf file type is EXEC (Executable file)
Entry point 0x804a0e0
There are 10 program headers, starting at offset 52

Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x00140 0x00140 R E 0x4
INTERP 0x000174 0x08048174 0x08048174 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
LOAD 0x000000 0x08048000 0x08048000 0x16f3c 0x16f3c R E 0x1000
LOAD 0x017ef8 0x0805fef8 0x0805fef8 0x00428 0x0105c RW 0x1000
DYNAMIC 0x017f0c 0x0805ff0c 0x0805ff0c 0x000e0 0x000e0 RW 0x4
NOTE 0x000188 0x08048188 0x08048188 0x00020 0x00020 R 0x4
GNU_EH_FRAME 0x016de8 0x0805ede8 0x0805ede8 0x00034 0x00034 R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4
GNU_RELRO 0x017ef8 0x0805fef8 0x0805fef8 0x00108 0x00108 R 0x1
PAX_FLAGS 0x000000 0x00000000 0x00000000 0x00000 0x00000 0x4

Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .hash .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame
03 .ctors .dtors .jcr .dynamic .got .got.plt .data .bss
04 .dynamic
05 .note.ABI-tag
06 .eh_frame_hdr
07
08 .ctors .dtors .jcr .dynamic .got
09
Post 25 Feb 2013, 10:31
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
edfed wrote:
unsigned long....
unsigned long long
just to don't write
dword
qword?
just because some hll coders thinks byte, word, dword etc are only microsoft(c) types...

I'm sorry, but you don't really know what you're moaning about, do you?

First, you're using the generic "hll" when what you're specifically moaning at is C/C++ (Java, C# and lots of other languages define explicit sizes for their data types). C/C++ has reasons for it's data types: efficiency when you need to target multiple architectures. The world is bigger than x86.

Also, "WORD" is ambiguous - and it's used damn inconsistenly on x86. Again, the world is bigger than x86, and you might want to look up what "WORD" means in the context of machine data types. C/C++ has unambiguous guaranteed-size through stdint.h/cstdint, by the way (preemptive snark: it took MS forever to support stdint.h, and cstdint wasn't added until C++11).

edfed wrote:
Code:
Compiler Error CXXXXX: cannot convert char* to const char*....
    

Pulling compiler errors out of the air now, are you? If you're going to moan, at least try to be correct. There's obviously nothing wrong with that assignment, since you're moving to a safer type. Your moaning should have been (with the Cxxxx error from MSVC):
Code:
const.cpp(7) : error C2440: '=' : cannot convert from 'const char *' to 'char *'    


edfed wrote:
ok, then,..... can you tell me how a pointer to 8 bits datas cannot be converted in a pointer to 8 bits datas...

You have one piece of memory with the explicit guarantee that it will never be written to, and you don't expect an error or warning when you try to throw that guarantee away? I guess you must be a fan of Humpty Dumpty.

_________________
Image - carpe noctem
Post 25 Feb 2013, 12:03
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.