|Mysterious triple test failures firstname.lastname@example.org (Nils M Holm) (2014-05-03)|
|Re: Mysterious triple test failures email@example.com (Kaz Kylheku) (2014-05-03)|
|Tripe test failure update firstname.lastname@example.org (Nils M Holm) (2014-05-04)|
|Re: Triple test failure update email@example.com (Chris Dodd) (2014-05-23)|
|Re: Triple test failure update firstname.lastname@example.org (Nils M Holm) (2014-05-23)|
|Re: Triple test failure update email@example.com (2014-05-23)|
|Date:||Fri, 23 May 2014 02:17:45 -0700 (PDT)|
|References:||14-05-003 14-05-004 14-05-008 14-05-027|
|Keywords:||storage, debug, comment|
|Posted-Date:||23 May 2014 12:47:11 EDT|
On Thursday, May 22, 2014 6:50:19 PM UTC-7, Chris Dodd wrote:
> "Nils M Holm" <firstname.lastname@example.org> wrote in news:email@example.com:
> > The assembly output of scc1 and scc2 is identical, the binaries are not.
> > *Both* compilers seem to work perfectly fine.
> So the difference is in the assembler or the linker.
I remember seeing *.c expand to a string containing all .c files. I'm not sure
how common this behavior of the OS shell is, but the list of files from such
an expansion may not be guaranteed to be sorted/ordered at all or always be in
one particular order. Interwebs tell me that the order may depend on the
setting of the environment variable LC_COLLATE (or an equivalent). And so,
yes, it may be an issue with the link order of the object (.o) files that
depends on the shell behavior if one uses wildcards in it.
AFAIR, in Spanish, the digraphs CH, LL (and RR?) used to collate differently
than they do now and than in English. They were considered single letters
(following C, L and R, respectively). So, for example, you could get these 2
[On any POSIX system, expanded shell wildcards are alphabetized. I suppose
it's possible that local langauge settings could change the result, but that's
getting a bit far afield from compilers. -John]
Return to the
Search the comp.compilers archives again.