Created attachment 181017 [details]
screenshot of observed clobbered values

I do not see this with current git (which is essentially 1.10.13 plus a little bit) nor in 1.10.8 from ubuntu.

Same result if I try a french locale instead.

I suspect this may have been fixed since 1.10.1 but it is such a strange bug...

Could you please verify what is really in those cells in question ie. A3 and A5 by editing those cells and seeing what shows up in the edit line? This may be an cell rendering problem. There have been fixes to the item grid rendering since 1.10.1.

confirmed. Cell contents is consistent with what is displayed in the edit line.

Would you be able to update to a newer version of Gnumeric? Maverick has 1.10.8 and Natty has 1.10.13.

This is weird, but I am also unable to reproduce.

Was Andreas right in guessing that this was with French locale?  (As
opposed to some other French-speaking locale.)  It shouldn't matter,
but still...

This was with a French locale but I see exactly the same behaviour with LANG=C.
Will try to upgrade as suggested.

I can reproduce with current git. When using the configuratble text import, things are OK in the dialog box in the two first tabs but the leading spaces disappear in the third, even if I run gnumeric in C locale. I must put the trim option to "Neither side" to make things work properly.

@Jean: At this stage we aren't really worried about the spaces. Do you see the change in the string ie. "XXX#1500" instead of " XXX#1750" note the change 5->7 and " abcdefgh" "abcdeghh" note hte "ef"->"gh"!?

that was supposed to be 7->5

No, I only see the leading white spaces issue.

@Thomas, do you see the problem with the changed strings independent from the setting of the "trim" option?

trim_spaces_inplace trims the spaces on the left by shifting the characters left using "strcpy". My manual page of strcpy says: "The  strings  may  not overlap, and the destination string dest must be large enough to receive the copy." In this specific case the strings do overlap. In the expected implementation of strcpy this should not be an issue but perhaps Thomas' compilation uses a different implementation where things fall apart.

I don't thin kwe should be using "strcpy".

We probably should replace strcpy with memmove.

aha.

I seem to recall that recent glibc may actually do things "wrong" if we
violate the requirements.

Tentatively fixes.  Keeping open for confirmation that no-strip-spaces
works even before the fix.

> @Thomas, do you see the problem with the changed strings independent from the
> setting of the "trim" option?

Believed fixed.

Thanks Morten! Indeed the symptom looks like what might happen with a strcpy on overlapping data.

Sorry for asking a basic question but... Where do I change the trim settings to check whether this indeed makes the problem disappear?

Final page of the configurable text importer has that.
Not possible from command line.

Onthe top left of the finalpage: "Coupure".

Got it! I confirm that the problem does not appear if importing without any trimming, or with just right-side trimming. It does show if importing with trimming on the left side or both sides.

For the record, I was able to reproduce the faulty behaviour on my machine (Ubuntu 10.04 with glibc 2.11.1), and check the validity of the fix, using a reduced C testcase:

#include <stdio.h>
#include <string.h>

char s1[] = " XXX#1750";
char *s2 = s1 + 1;
void main (void) {
#ifdef BAD
  strcpy (s1, s2);
#else
  memmove (s1, s2, 1 + strlen (s2));
#endif
  printf ("«%s»\n", s1);
}

Thanks Thomas. Good to know that this should really have fixed the problem at hand. (It is always difficult to handle bugs we can't replicate.)