Subject: Re: mklocale, take 2
To: None <tech-toolchain@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-toolchain
Date: 10/22/2001 09:39:16
>> (2) is the argument that was being "recycled" ((1) is certainly
>> valid, even to the tech-toolchain discussion, but wasn't mentioned
>> in this connection), and it applies just as strongly to
>> __attribute__.
> While I mostly dislike all GNU extensions to almost everything, and
> have trouble digesting most of RMS's arguments about almost anything,
> are you really certain about that?

Sure.  (2) was "#pragma can mean just about anything to some other
compiler", and that applies equally well to __attribute__.

> C #defines can generate just about anything, other than other C
> preprocessor statements.

Yes; this is RMS's argument 1, which is valid, and which applies to the
present tech-toolchain discussion.  But it's not the argument that was
being "recycled" and it's not the argument that I was saying above
applies to __attribute__ as well as #pragma.  (Watch the parentheses.)

>> Struct packing, as the discussion has pointed out, shouldn't be
>> ignored.)
> That's simply wrong.   Any code that depends upon struct packing, or
> anything related to alignment, for anything related to code
> correctness (as distinct from efficiency) is simply broken.

This I have to disagree with.  Not all code is intended to be portable
to the entire known universe, or is "broken" if it's not.

> This stuff all related to mklocale I think, which seems to simply be
> terminally broken as currently implemented (and admitted to be that
> way).

> Eventually it should be fixed so whatever method of getting packed
> structs might happen to apply, or not apply, it still works
> correctly.

In mklocale's case I agree; given NetBSD's goals, the code should be
arranged to work with some large subset of the compilers in existence
today and likely to exist in the near future, definitely including more
than just gcc.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B