Re: Re: problem with strncpy
Tim Cutts <tjrc> schrieb am 20.03.2003 13:42:
> On Thu, Mar 20, 2003 at 02:09:04PM +0100, Markus Bernhardt wrote:
> > void table_set_param(Table *table, char *name, int count, long index) {
> > int i;
> > for(i = 0; i < TABLE_NAME_LENGTH; i++) {
> > table->name[i] = '\0';
> > }
>
> Wouldn't:
>
> memset(table->name, 0, TABLE_NAME_LENGTH);
>
> be nicer? Possibly not as fast, I suppose...
You're right. memset is much nicher. Will change it.
>
> > strncpy(table->name, name, TABLE_NAME_LENGTH-1);
>
> Are you certain that table->name and name are *always* independent
> variables? Note from the strncpy man page:
I'm quite sure, but not 100%. Will further look into this.
But there are two points why I think the code is ok.
1. Works perfect for x86, s390, s390x achitectures.
2. Our unittest with a small testcase works perfect on ia64.
The problem occurs only with our real life database
after processing 5.6 Gigabyte of data.
But I will try to check this.
>
> The
> strings may not overlap, and the destination string dest must be
> large enough to receive the copy.
>
> > Breakpoint 3, table_set_param (table=0x60000ffffffedec0, name=0x4000000000022808 "TSTICHWORT", count=2, index=6917546619827052592) at suchmaschine/table.c:21
> > 21 strncpy(table->name, name, TABLE_NAME_LENGTH-1);
> > (gdb) print name
> > $1 = 0x4000000000022808 "TSTICHWORT"
> > (gdb) print table->name
> > $6 = '\0' <repeats>
>
> We need to know what the hex value of the table->name pointer is at this
> point...
>
Because it will take me 6 hours of time to get to this point,is:
print &(table->name)
what we need ?
> Tim
>
> --
> Dr Tim Cutts
> Informatics Systems Group
> Wellcome Trust Sanger Institute, Hinxton, Cambridge, CB10 1SA, UK
>
Reply to: