Turbo C Strange Problem

[Gabriel]

Hi,

I'm using Turbo C 2.01 and im stuck with this problem.

I've reduced it to the following. My code in Turbo C is this:

void f(char *);

char h[] = "hello";

void main() {
f(h);
}

void f(char *s) {
int n = 0;
while (s[n] != 0) {
/*do something*/
n++;
}
}

It's just a function that takes a string as an argument and merely
loops till it finds the terminating NULL character.

I compile it like this (the file is named c.c):

tcc -mt c.c
tlink C.OBJ

and then i do exe2bin C.EXE to get the raw binary image.

The disassembly for either the .bin or .exe (they are the same, but
it's easier to work with the .bin because it doesn't have the "turbo c
junk code") is the following:

0000 mov ax, 000E
0003 push ax
0004 call 0009
0007 pop cx
0008 ret
0009 push bp
000A mov bp, sp
000C push si
000D xor si, si
000F jmp 0012
0011 inc si
0012 mov bx, [bp+04]
0015 cmp byte ptr [bx+si], 00
0018 jne 0011
001A pop si
001B pop bp
001C ret
001E 'hello\0' ;you get me :)
So, the problem is the first line!

mov ax, 000E

It doesn't point to the string, which is located in 001E, so if i
change that byte with a hexadecimal editor the program works just
fine.

My question is: why does Turbo C commit this error? Am i doing
something wrong?

NOTE: if the function f has no code then the address is correctly
compiled, but if it as ANY code, like a variable declaration, then the
problem appears.

Thanks

[Bartc]

"Gabriel" <ga***********@gmail.comwrote in message
news:01**********************************@z66g2000 hsc.googlegroups.com...

Hi,

I'm using Turbo C 2.01 and im stuck with this problem.

I've reduced it to the following. My code in Turbo C is this:

void f(char *);

char h[] = "hello";

void main() {
f(h);
}

void f(char *s) {
int n = 0;
while (s[n] != 0) {
/*do something*/
n++;
}
}

It's just a function that takes a string as an argument and merely
loops till it finds the terminating NULL character.

I compile it like this (the file is named c.c):

tcc -mt c.c
tlink C.OBJ

and then i do exe2bin C.EXE to get the raw binary image.

The disassembly for either the .bin or .exe (they are the same, but
it's easier to work with the .bin because it doesn't have the "turbo c
junk code") is the following:

0000 mov ax, 000E
0003 push ax
0004 call 0009
0007 pop cx
0008 ret
0009 push bp
000A mov bp, sp
000C push si
000D xor si, si
000F jmp 0012
0011 inc si
0012 mov bx, [bp+04]
0015 cmp byte ptr [bx+si], 00
0018 jne 0011
001A pop si
001B pop bp
001C ret
001E 'hello\0' ;you get me :)
So, the problem is the first line!

mov ax, 000E

It doesn't point to the string, which is located in 001E, so if i
change that byte with a hexadecimal editor the program works just
fine.

The 000E isn't necessarily wrong, it depends on the segment registers. But
if you use a memory model where CS=DS=SS=ES then no it doesn't look right
(assuming exe2bin is doing it's job properly).

What happens when you add in this 0x10 offset to the source code (ie.
s[n+0x10])? How about varying the call, eg from f(h) to f(&h[0]) to
f("hello") and so on?

Of interest might be the contents of c.obj also, can you dump that? What
does -mt compilation switch do?

--
bartc

[Keith Thompson]

Gabriel <ga***********@gmail.comwrites:

I'm using Turbo C 2.01 and im stuck with this problem.

I've reduced it to the following. My code in Turbo C is this:

void f(char *);

char h[] = "hello";

void main() {
f(h);
}

void f(char *s) {
int n = 0;
while (s[n] != 0) {
/*do something*/
n++;
}
}

It's just a function that takes a string as an argument and merely
loops till it finds the terminating NULL character.

<NITPICK>
That's null character, not NULL character. NULL (all-caps) refers
specifically to the macro that expands to a null *pointer* constant.
</NITPICK>

I'd say you've narrowed it down a bit *too* far. The program produces
no output, so a sufficiently clever compiler could reduce the whole
thing to the equivalent of ``int main(void) { }''. I doubt that Turbo
C 2.01 is that clever, but who knows what it could decided to do. (I
don't.)

Note that main returns int, not void. It's possible that TC2.01
accepts "void main()", but it's still a good habit to declare it
correctly. And since main returns int, it's a good idea to actually
return an int.

Try something like this:

#include <stdio.h>

void f(char *);

char h[] = "hello";

int main(void) {
f(h);
return 0;
}

void f(char *s) {
int n = 0;
while (s[n] != 0) {
putchar(s[n]);
putchar('\n');
n++;
}
}

If that doesn't do it, try reproducing the problem (assuming there is
one) with a program that produces output rather than asking us to look
through assembly listings.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Gabriel]

Im sorry i took so long to answer.

exe2bin works OK, because the output executable also has the address
corrupted. the bin and the exe are the same.

the -mt is to tell the compiler to use tiny model. i just noted that
in my post i missed the -c (i use it, i just forgot to write it), its
purpose is to compile and not link, so i can link in the second step.

if i try f(&h[0]) or f("hello") the problem persists, however calling
f this way: f(h + 0x10) fixes it.

Gabriel

[Gabriel]

Keith, im sorry for the assembly i just thought it would be helpful.

I tried your code but i cant get it compiled because i get undefined
external symbol when linking (putchar) even thou i have fixed my
turboc.cfg. I recall that once i got that same code to get compiled
(but i dont remember how) and it was OK, however if i try my original
code bit with int main the problem is still there. so i conclude that
stdio fixes it, but this is really strange.

Ill keep experimenting,

Gabriel

[CBFalconer]

Gabriel wrote:

>
Im sorry i took so long to answer.

exe2bin works OK, because the output executable also has the address
corrupted. the bin and the exe are the same.

the -mt is to tell the compiler to use tiny model. i just noted that
in my post i missed the -c (i use it, i just forgot to write it), its
purpose is to compile and not link, so i can link in the second step.

if i try f(&h[0]) or f("hello") the problem persists, however calling
f this way: f(h + 0x10) fixes it.

This is completely meaningless.

If you want to post a followup via groups.google.com, ensure you
quote enough for the article to make sense. Google is only an
interface to Usenet; it's not Usenet itself. Don't assume your
readers can, or ever will, see any previous articles.

More details at: <http://cfaj.freeshell.org/google/and below.

--
Some useful links on quoting:
<http://www.xs4all.nl/%7ewijnands/nnq/nquote.html>
<http://www.complang.tuwien.ac.at/anton/mail-news-errors.html>
<http://www.netmeister.org/news/learn2quote2.html>
<http://www.star-one.org.uk/computer/format.htm>
** Posted from http://www.teranews.com **

[Richard Bos]

Gabriel <ga***********@gmail.comwrote:

Keith, im sorry for the assembly i just thought it would be helpful.

You're not being helpful by snipping all context.

I tried your code

What code? Which code? I see no CODE here.

but i cant get it compiled because i get undefined
external symbol when linking (putchar)

That's an ISO C function. If your implementation doesn't recognise it,
either get a real C compiler, or reinstall the one you have, and this
time get it right.

Richard

[Mark McIntyre]

Richard Bos wrote:

>

>but i cant get it compiled because i get undefined
external symbol when linking (putchar)

You are not linking against the library that contains putchar. Read your
toolset's documentation to find out how to correctly link.

That's an ISO C function. If your implementation doesn't recognise it,
either get a real C compiler, or reinstall the one you have, and this
time get it right.

With responses like this, its no wonder CLC has a reputation for rudeness.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Old Wolf]

On Jun 7, 11:08 am, Gabriel <[e-mail]:

I've reduced it to the following. My code in Turbo C is this:
and then i do exe2bin C.EXE to get the raw binary image.
So, the problem is the first line!
mov ax, 000E

Can you write a program that actually behaves
in some erratic way ? If the program's output
matches the expected output, then it doesn't
really matter what the assembly is (and it
shouldn't be taken as a sign of a bug).

BTW (to others in this thread) Turbo C 2.01
shipped in May 1989, so ANSI compliance should
not be expected.

[Richard Heathfield]

Old Wolf said:

<snip>

BTW (to others in this thread) Turbo C 2.01
shipped in May 1989, so ANSI compliance should
not be expected.

Given that fact, it's remarkable how conforming it actually is. Yes, there are
problem bits, but really they are few and far between, and I believe that for
the most part they comprise mere corner cases. The most in-your-face
violation seems to be the use of CLOCK_TCK rather than CLOCKS_PER_SEC, which
is hardly earth-shattering.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

Mark McIntyre wrote:

Richard Bos wrote:

>>

>>but i cant get it compiled because i get undefined
external symbol when linking (putchar)

You are not linking against the library that contains putchar. Read
your toolset's documentation to find out how to correctly link.

>That's an ISO C function. If your implementation doesn't recognise
it, either get a real C compiler, or reinstall the one you have,
and this time get it right.

With responses like this, its no wonder CLC has a reputation for
rudeness.

What's rude about it? Terse, but factual, IMO.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Default User]

Richard Heathfield wrote:

Old Wolf said:

<snip>

BTW (to others in this thread) Turbo C 2.01
shipped in May 1989, so ANSI compliance should
not be expected.

Given that fact, it's remarkable how conforming it actually is. Yes,
there are problem bits, but really they are few and far between, and
I believe that for the most part they comprise mere corner cases. The
most in-your-face violation seems to be the use of CLOCK_TCK rather
than CLOCKS_PER_SEC, which is hardly earth-shattering.

I used Turbo C for quite some time back in the day. Even after I
stopped using it as a compiler, I used the manual. It had good
descriptions of the library functions, along with whether they were
ANSI, "UNIX", or their own.


Brian

[Mark McIntyre]

CBFalconer wrote:

>
What's rude about it?

How about the implication that the OP is too incompetent to install his
toolset?

Terse, but factual, IMO.

Terse, factual and rude. Richard is in peril of turning into Dan Pop.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Coos Haak]

Op Thu, 12 Jun 2008 19:36:22 +0100 schreef Mark McIntyre:

Richard Bos wrote:

>Mark McIntyre <ma**********@TROUSERSspamcop.netwrote:

>>Richard Bos wrote:
but i cant get it compiled because i get undefined
external symbol when linking (putchar)
You are not linking against the library that contains putchar. Read your
toolset's documentation to find out how to correctly link.

The library that contains putchar is the Standard C library. If it isn't
linked against by default, something is wrong in his installation.

This doesn't follow, as you know well.

It is, I've just checked my installated TC 2.01 and putchar works.
Either the OP has a bad installed compiler or forgot to #include <stdio.h>
--
Coos

[Mark McIntyre]

Coos Haak wrote:

Op Thu, 12 Jun 2008 19:36:22 +0100 schreef Mark McIntyre:

>Richard Bos wrote:

>>Mark McIntyre <ma**********@TROUSERSspamcop.netwrote:

Richard Bos wrote:
>but i cant get it compiled because i get undefined
>external symbol when linking (putchar)
You are not linking against the library that contains putchar. Read your
toolset's documentation to find out how to correctly link.
The library that contains putchar is the Standard C library. If it isn't
linked against by default, something is wrong in his installation.

This doesn't follow, as you know well.

It is, I've just checked my installated TC 2.01 and putchar works.

I know. That's not the point.

Either the OP has a bad installed compiler or forgot to #include <stdio.h>

Or indeed isn't using his linker right - so it is not necessarily
something wrong with his installation.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Bob Nelson]

Mark McIntyre wrote:

CBFalconer wrote:

>>
What's rude about it?

How about the implication that the OP is too incompetent to install his
toolset?

>Terse, but factual, IMO.

Terse, factual and rude. Richard is in peril of turning into Dan Pop.

But that's a compliment, surely.

[Kenny McCormack]

In article <g2**********@renpen.nelsonbe.com>,
Bob Nelson <bn*****@nelsonbe.comwrote:

>Mark McIntyre wrote:

>CBFalconer wrote:

>>>
What's rude about it?

How about the implication that the OP is too incompetent to install his
toolset?

>>Terse, but factual, IMO.

Terse, factual and rude. Richard is in peril of turning into Dan Pop.

But that's a compliment, surely.

Somehow, I don't think it was intended as such.

BTW, I just love it when chicks^Wregulars fight.