of that.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
made), stdarg.h is safe.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
by
expressing one's opinion that the decisions various platforms made were
stupid. :)
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
that
I've *never* seen wrapped in ifdef even in code meant to compile on
extremely strange systems.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
problems.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Brent Dax [EMAIL PROTECTED] writes:
Russ Allbery:
# POSIX reserves all types ending in _t. I'm not sure that extends to
# struct tags, but it may still be better to use _s or something else
# instead to avoid potential problems.
My understanding is that it only reserves types that start
equivalence does nothing as
ill-conceived as unifying e and e', for very good reason because that
would be a horrible mistake.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Bryan C Warnock [EMAIL PROTECTED] writes:
On Monday 21 January 2002 16:43, Russ Allbery wrote:
Changing the capitalization of C does not change the word.
Er, most of the time.
No, pretty much all of the time. There are differences between proper
nouns and common nouns, but those
. */
#define UNUSED __attribute__((__unused__))
and then writing things like:
int
foo(int bar UNUSED)
actually serves to add additional documentation as well as shutting up
warnings.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
, so -Wredundant-decls possibly could get pulled back in.
-Wundef is a style thing.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
by POSIX and may be used without
warning in later versions of the standard. (This comes up not
infrequently in some of the groups I read, but I unfortunately don't have
a copy of POSIX to check for myself and be sure.)
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Robert Spier [EMAIL PROTECTED] writes:
On Tue, 2001-10-23 at 20:52, Russ Allbery wrote:
Dan Sugalski [EMAIL PROTECTED] writes:
Once we build miniparrot, then *everything* can be done in
perl. Having hacked auto* stuff, I think that'd be a good
thing. (autoconf and friends are unmitigated
Russ Allbery [EMAIL PROTECTED] writes:
I'm not sure what there is to expand on. I've looked at 2.50, and it
definitely doesn't look like an unmitigated evil hack to me. It looks
like a collection of tests for various standard things that packages need
to know to compile, put together about
the other night... :) and
it'll let us skip some of the more awkward bits of make.
I can certainly see the features of that approach. It just seems like
quite a lot of work.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
for.
(In the case above, I'd probably instead define a sleep function on WIN32
that calls Sleep so that the platform differences are in a separate file,
but there are other examples of things like this that are better suited to
other techniques.)
--
Russ Allbery ([EMAIL PROTECTED]) http
at the facilities for dynamic loading provided by libtool before
rolling our own again may also be a good idea; it's designed to support
dynamically loadable modules.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
inside)
I've looked inside a lot, and I definitely do not agree. But maybe you've
not seen autoconf 2.50 and later?
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Definitely bugs in Configure there; cc has to be used as the linker or -lc
isn't added (and possibly some of the other crt.o files too), and
libraries have to be after all the object files.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
be performed.
Something akin to gcc's --enable-checking strikes me as a really good
idea.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
of the compatibility characters for you.
NFKC will go further and do stuff like getting rid of superscripts and the
like.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Dan Sugalski [EMAIL PROTECTED] writes:
At 01:05 PM 6/11/2001 -0700, Russ Allbery wrote:
Dan Sugalski [EMAIL PROTECTED] writes:
Should perl's regexes and other character comparison bits have an
option to consider different characters for the same thing as
identical beasts? I'm thinking
at glibc's approach is that they get tons
of bug reports about obscure things and conventions for using particular
characters that aren't obvious from the specifications.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
). If there is some similar
distinction of meaning for numbers in some language, I suppose that
Unicode may add such a thing; to date, there doesn't appear to be any
concept of uppercase or lowercase for anything but letters.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org
Dan Sugalski [EMAIL PROTECTED] writes:
At 12:40 PM 6/5/2001 -0700, Russ Allbery wrote:
(As an aside, UTF-8 also is not an X-byte encoding; UTF-8 is a variable
byte encoding, with each character taking up anywhere from one to six
bytes in the encoded form depending on where in Unicode
, and in the other two you recompose characters as
much as possible.)
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Simon Cozens [EMAIL PROTECTED] writes:
On Tue, Jun 05, 2001 at 03:27:03PM -0700, Russ Allbery wrote:
Caseless characters should be guaranteed unchanged by conversion to
upper or lower case, IMO.
I think Bryan's asking more about \p{IsUpper} than uc().
Ahh... well, Unicode classifies them
is
actually doing.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
that they've buried the idea of
keeping Unicode to 16 bits.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Russ Allbery [EMAIL PROTECTED] writes:
That's probably unnecessary; I really don't expect them to ever use all
31 bytes that the IETF-standardized version of UTF-8 supports.
31 bits, rather. *sigh*
But given that, modulo some debate over CJKV, we're getting into *really*
obscure stuff
Larry Wall [EMAIL PROTECTED] writes:
Russ Allbery writes:
Particularly since extending UTF-8 to more than 31 bits requires
breaking some of the guarantees that UTF-8 makes, unless I'm missing
how you're encoding the first byte so as not to give it a value of
0xFE.
The UTF-16 BOMs, 0xFEFF
The Right
Thing.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
o in-place modifications without changing the allocation, but
that sounds a lot iffier.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
function pointers from us somehow, and
do the call in.
Can't. ISO C requires that all variadic functions take at least one named
parameter. The best you can do is something like (void *, ...).
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Chaim Frenkel [EMAIL PROTECTED] writes:
"RA" == Russ Allbery [EMAIL PROTECTED] writes:
RA This will be completely impossible to implement in some installation
RA environments, such as AFS or read-only remote NFS mounts. I really
RA don't like software that tries to play dynamic c
this too hard to do.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
to do this if so wished.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
library on some
platforms, which is frequently a plus in load time.
Don't have time at the moment to write an RFC, so if someone else wants
to, be my guest
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
than glibc, given that our
interface is positively tiny compared to the entire C library.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
more convenient).
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Dan Sugalski [EMAIL PROTECTED] writes:
On 29 Aug 2000, Russ Allbery wrote:
I'd love to see Perl aggressively take advantage of new capabilities in
dynamic loaders, though. Among other things, I'll point out that
symbol versioning is the way that things like libc manage to be
backward
n undef;
}
should be done away with for good.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
platforms? If so, I
can definitely see the wisdom in doing something about *that* and
off-loading the system-local time processing into modules (although I can
also see the wisdom in leaving well enough alone). But why not go with
the most commonly used and most widely analyzed epoch?
--
Russ Allbe
a change of epoch; I just don't see what
would be gained.
I must be very confused. I don't understand what we gain from MJD dates
at all, and the arguments in favor don't make any sense to me; all of the
advantages listed apply equally well to the time system we have already.
--
Russ Allb
-bit
value, something that apparently we'd need to do with an MJD-based time
anyway. And everyone already knows how it works and often relies on the
base being consistent with their other applications.
It really doesn't sound like a good idea to change all that.
--
Russ Allbery ([EMAIL PROTECTED
Tim Jenness [EMAIL PROTECTED] writes:
On 14 Aug 2000, Russ Allbery wrote:
Day resolution is insufficient for most purposes in all the Perl
scripts I've worked on. I practically never need sub-second precision;
I almost always need precision better than one day.
MJD allows fractional days
have merit, I am absolutely
100% opposed to the grand implications and its tone and would consider
this approach to be disasterous for Perl.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
that a program wants to modify during
its normal course of operation and isn't a dotfile in the user's home
directory is inherently Evil and not to be tolerated if at all possible.
Bear in mind that site-wide Perl installations are going to be exported
read-only.
--
Russ Allbery ([EMAIL PROTECTED
49 matches
Mail list logo
