> It is completely agreed that the extensions are usually nice and
> convenient things to have.  [...]

> It is _still_ professional to avoid them, for reasons I have
> previously written at length regarding.  Usually, if you really need
> that abstraction, it is also available in __STDC__ macros.

Extended asm and __attribute__ come to mind as two gccisms that NetBSD
uses but which don't exist in any form in Standard C.

Additionally,

> Hardly anyone wraps initializers and calls, though, so it must not be
> considered a necessary abstraction.

The consequent here does not follow from the antecedent.  The
abstraction desired in the initial post simply cannot be done in
Standard C (under which rubric I do not yet include C99).  Thus, nobody
wraps initializers this way because it can't be done; therefore, the
fact that nobody does so says nothing about how important anyone
considers it.

>> [extended asm example]
> Actually, this one example could be easily done with a plain,
> old-style asm(),

Only by knowing the calling convention, in which case the whole routine
might as well be done in assembly.

> Sadly, the gcc docs discourage this, and even imply that such
> statements won't work because the compiler will eat your return
> values.  (Although in fact I don't think it does.)

It may not for the port relevant to this specific example.  But the gcc
docs, unlike this example, are not machine-specific; unless the asm
includes the return, the compiler *may* eat the return value on some
architectures, or with some combinations of flags.  And, especially on
architectures with multiple calling conventions available, there can be
a distinct advantage to letting the compiler deal with prologue and
epilogue.

>> (The alternative, it seems to me, is to study ABI documents [...])
> Oh come on, you can't do any serious work without knowing the ABI.
> It's almost always portable between all compilers for a machine, and
> you absorb the ABI about for free when learning the machine language.

Unless there are multiple ABIs, as for example on machines which have
both caller-saves and callee-saves conventions.

> But I will freely admit that the GNU asm() statement is the most
> useful of the extensions,

To whom? :-)  I use __attribute__ at least three or four times as often
as I use nested functions, and even the latter I use at least five to
ten tiems as much as I use any form of asm.

> (But slow only matters if the code is on a frequently used path.
> Less than 10% of a program's lines are.)

But unfortunately there is sometimes no way to tell which the 10% is.
Different parts of the kernel - this *is* tech-kern - will get
exercised more or less heavily depending on the job mix, which is not
determinable at kernel writing time.

> There is no reason to go to extremes either way.  If, all things
> considered, the positives outweigh the negatives, by all means use a
> gnu asm().  Just make sure you know the negatives.

Of course, whether "the positives outweigh the negatives" is a
judgement call, and there will always be cases people disagree on.

> And the fact that use of gnu asm() can be justified at times does not
> speak one way or the other about the rest of the extensions.

No, but it makes a convenient poster child for the larger issue. :-)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B