• State Not Answered
  • Locked Locked
  • Replies 15 replies
  • Subscribers 22 subscribers
  • Views 3563 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

bug in strcpy

Johann Kok

I have the following structure:

struct fence_struct	{
  unsigned char	mode;
  char		sitename[13];
  unsigned char	sector_nr;
  unsigned char	sector_tot;
  unsigned int	start;
  unsigned int	feeder_offset;
  unsigned int	len;
  unsigned int	line_len;
  unsigned char	begin_far;
  unsigned int	res_norm;
  unsigned int	res_min;
  unsigned int	res_max;
  unsigned char	wire_amount;
  unsigned char	wire_name[12];
};

xdata struct fence_struct  fence;

I then initialise fence.sitename like this in the function init_vars():
strcpy(fence.sitename, "SITENAME");

and it generates this assembly:
;strcpy(fence.sitename, "SITENAME");
;SOURCE LINE # 1535
MOV  	R0,#LOW (fence+01H)
MOV  	R4,#HIGH (fence+01H)
MOV  	R5,A
MOV  	R3,#0FFH
MOV  	R2,#HIGH (?SC_403)
MOV  	R1,#LOW (?SC_403)
LCALL	?C?STRCPY

WHICH DOESN'T WORK

However, when I call exactly the same line in the function misc_info() it generates the following assembly:
;strcpy(fence.sitename, "SITENAME");
;SOURCE LINE # 4306
MOV  	R0,#LOW (fence+01H)
MOV  	R4,#HIGH (fence+01H)
MOV  	R5,#01H
MOV  	R3,#0FFH
MOV  	R2,#HIGH (?SC_403)
MOV  	R1,#LOW (?SC_403)
LCALL	?C?STRCPY

WHICH WORKS FINE

Why does it generate different assembly for the same source line and how can I rectify it?

Parents
  • 0

    What you found is not a bug. If it were, you should have demonstrated incorrect behaviour of the generated code. The bug, if any, is in your expectations.

    Note that the only actual difference between you two assembly outputs is

    MOV     R5,A

    as opposed to

    MOV     R5,#01H

    If the accu happened to contain a 01H at the point of one invocation, but not at the other, that's all it takes to explain the difference. This is an optimizing compiler, after all.

Reply
  • 0

    What you found is not a bug. If it were, you should have demonstrated incorrect behaviour of the generated code. The bug, if any, is in your expectations.

    Note that the only actual difference between you two assembly outputs is

    MOV     R5,A

    as opposed to

    MOV     R5,#01H

    If the accu happened to contain a 01H at the point of one invocation, but not at the other, that's all it takes to explain the difference. This is an optimizing compiler, after all.

Children