I've been trying to fill in as many gaps as possible in the config.sub
test suite (and finding a whole bunch of actual bugs in the process).
I have a short list of inputs where the actual code to handle them is
incomplete or broken, there's nothing in config.guess to use as a clue,
and I don't know
On Wed, Nov 16, 2022, at 1:17 PM, Paul Eggert wrote:
...
> If Clang's threatened pickiness were of some real use elsewhere, it
> might be justifiable for default Clang to break Autoconf. But so far we
> haven't seen real-world uses that would justify this pickiness for
> Autoconf's use of 'char
On Tue, Nov 15, 2022, at 12:03 AM, Sam James wrote:
>> On 13 Nov 2022, at 00:43, Paul Eggert wrote:
>>
>> Although there will be problems with people who run "./configure
>> CFLAGS='-Werror'", that sort of usage has always been problematic and
>> unsupported by Autoconf, so we can simply contin
Wookey writes:
> On 2022-11-10 19:08 +0100, Florian Weimer wrote:
>> based on a limited attempt to get this fixed about three years
>> ago, I expect that many of the problematic packages have not had their
>> configure scripts regenerated using autoconf for a decade or more. This
>> means that as
Sam James writes:
>> On 12 Nov 2022, at 03:40, Zack Weinberg wrote:
>> This is definitely more work than I can see myself doing on a volunteer
>> basis, but a 2.69.1 patch release — nothing that’s not already on trunk,
>> cherry pick the changes needed to support
Paul Eggert writes:
> On 2022-11-10 19:33, Zack Weinberg wrote:
>
>> It would be relatively easy for me to take a couple hours this
>> weekend and put out a 2.72 release with everything that's already in
>> trunk and nothing else. Anyone have reasons I _shouldn
Florian Weimer writes:
> based on a limited attempt to get this fixed about three years
> ago, I expect that many of the problematic packages have not had their
> configure scripts regenerated using autoconf for a decade or more. This
> means that as an autoconf maintainer, you unfortunately won'
Rich Felker writes:
> On Thu, Nov 10, 2022 at 12:16:20PM -0500, Zack Weinberg wrote:
>> The biggest remaining (potential) problem, that I’m aware of, is that
>> AC_CHECK_FUNC unconditionally declares the function we’re probing for
>> as ‘char NAME (void)’, and asks the compil
Nick Bowler writes:
> My gut feeling is that Autoconf should just determine the necessary
> options to get compatible behaviour out of these modern compilers, at
> least for the purpose of running configure tests. For example, Autoconf
> should probably build the AC_CHECK_FUNC programs using gcc'
On Thu, Nov 10, 2022, at 10:08 PM, Sam James wrote:
>> On 10 Nov 2022, at 21:10, Michael Orlitzky wrote:
>> While everyone else is discussing big ideas, it would be helpful for me
>> personally if autoconf just made a release with the latest bugfixes.
>
> Before I dive into the rest of this thread
I’m the closest thing Autoconf has to a lead maintainer at present.
It’s come to my attention (via https://lwn.net/Articles/913505/ and
https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
Clang both plan to disable several “legacy” C language features by
default in a near-future
On Fri, Sep 17, 2021, at 9:36 PM, James Y Knight via Libc-alpha wrote:
> Glibc currently implements bcmp as an alias to memcmp -- which is valid,
> but provides more than just the boolean equality semantics. There was
> concern raised that modifying that might break existing binaries. However,
> th
> printf(“Hello World\n”); is UB under -fexec-charset= EBCDIC. WTF WTF!!!
It's not undefined behavior. It does, however, appear to trip various
bugs in GCC.
$ cat test.c
#include
int main(void) { printf("hello world\n"); }
$ gcc-9 --version | head -n1
gcc-9 (Debian 9.3.0-18) 9.3.0
$ gcc-9 -fex
On 09/09/2015 02:02 PM, paul_kon...@dell.com wrote:
>> On Sep 9, 2015, at 1:54 PM, David Edelsohn
>> wrote:
>>
>> What level of erasure of sensitive data are you trying to ensure?
>> Assuming that overwriting values in the ISA registers actually
>> completely clears and destroys the values is d
On 09/09/2015 01:13 PM, Rich Felker wrote:
> On Wed, Sep 09, 2015 at 12:47:10PM -0400, Zack Weinberg wrote:
>> On Wed, Sep 9, 2015 at 12:42 PM, Rich Felker wrote:
>>> You're making this harder than it needs to be. The "m" constraint is
>>&g
On 09/09/2015 12:52 PM, paul_kon...@dell.com wrote:
> Then again, suppose all you had is explicit_bzero, and an annotation
> on the data saying it's sensitive. Can static code analyzers take
> care of the rest? If so, this sort of thing doesn't need to be in
> the compiler.
The thing that absolu
On Wed, Sep 9, 2015 at 12:42 PM, Rich Felker wrote:
> You're making this harder than it needs to be. The "m" constraint is
> the wrong thing to use here. Simply use:
>
> __asm__(""::"r"(ptr):"memory");
Please review my earlier conversation with Adhemerval on exactly this point.
zw
OK, I have now failed to find the LLVM development list twice in a
row. Could some kind soul please forward the message to whereever the
heck the proper address is?
zw
[Sorry for the double-post, but I got the LLVM mailing list address wrong,
and I want to make sure that everyone sees the entire conversation.]
Over the past couple months I have been working on adding a function to
glibc for erasure of sensitive data after it's used. This function
already exists
Over the past couple months I have been working on adding a function to
glibc for erasure of sensitive data after it's used. This function
already exists in various other libraries under various names --
explicit_bzero, explicit_memset, SecureZeroMemory, memset_s,
OPENSSL_cleanse, etc -- and the pr
>In a recent upgrade, we noticed that -I- functionality is being
>replaced with -iquote. This -iquote does not have the same
>functionality as -I- and is removing a strong function that is needed.
I wasn't around for the decision to remove the "don't search the
directory containing the current fi
Lijuan Hai wrote:
>
> I have a plan to convert UCN to alphabet instead of UTF8 in
> GCC-4.2.0, and already handled it in libcpp.
I would like to offer advice, but I don't understand what you are
trying to do. You say you want to "convert UCN[s] to [an] alphabet
instead of UTF8" but that doesn't m
I suppose this is related to what I said to you on IRC, so I ought to
chime in here.
I agree with Daniel and David - your patch is not appropriate. As
long as we actually have the .l and .y files, the associated .c/.h
files should not be checked in, and flex/bison should be required when
building
Joern Rennecke wrote:
The score, sh and sparc instructions may or may not display canonical
behavior; their ports do not define CLZ_DEFINED_VALUE_AT_ZERO and I was
not able to find documentation of the relevant instruction.
The operation the nsb instruction of the SHmedia instruction set perfor
Andrew Pinski wrote:
On 8/15/07, Zack Weinberg <[EMAIL PROTECTED]> wrote:
Is popcount really slow on PowerPC? (Compared to clz?)
popcount is really popcount in bytes and then you do a multiple to get
the real popcount. This is why it is slower than count leading zeros.
Also popcoun
Segher Boessenkool wrote:
* I would like to do the same for __builtin_ctz, but there is a catch.
The synthetic ctz sequence in terms of popcount (as presently
implemented by ia64.md, and potentially usable for at least i386 and
rs6000 as well if moved to optabs.c) produces the canonical behavior
Richard Kenner wrote:
* Since no one uses it, we rip out all support for the ffs pattern and
expression.
There's an ffs builtin! How do we know who uses it?
I am not proposing to remove the built-in (i.e. the language visible
__builtin_ffs() function); only the RTL expression (ffs:MODE ...)
During development of the patch I just posted for double-word clz, I
went through all the back ends and audited their use of the bit-scan
named patterns and RTL. It appears to me that our current handling of
C[LT]Z_DEFINED_VALUE_AT_ZERO is much more complicated than it needs to
be, and also that
On 7/5/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> libstdc++'s bitmap_allocator.cc, because for some reason reload wants
> a MODE_PARTIAL_INT mode with 64 bits. There is no such mode, so
> get_smallest_mode_for_size aborts. I am attaching the .lreg and .greg
> dumps to this message (compress
On 05 Jul 2007 18:22:50 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Zack Weinberg" <[EMAIL PROTECTED]> writes:
[std_expand_builtin_va_start]
> rtx va_r = expand_normal (valist);
> emit_move_insn (va_r, nextarg);
>
> but this is a part of the comp
On 7/5/07, Zack Weinberg <[EMAIL PROTECTED]> wrote:
I'll try your patch, but I would still like to know whether we
couldn't stop using make_tree altogether, just expand valist and then
pass it to emit_move_insn (or maybe convert_move would be better).
Patch does not help.
I'll try your patch, but I would still like to know whether we
couldn't stop using make_tree altogether, just expand valist and then
pass it to emit_move_insn (or maybe convert_move would be better).
zw
I'm trying to help DJ with converting m32c to define_constraint, and
I'm running into an unrelated problem. Specifically, the unmodified
compiler targeting m32c-elf, in -mcpu=m32cm mode, crashes on any use
of __builtin_va_start, even this:
int foo(int x, ...)
{
__builtin_va_list t;
__builtin_v
On 5/28/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
Just in case you've forgotten: You posted a patch for h8300 here:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02031.html>
Yes, but it's got bugs, and it will be more efficient for an actual
h8300 expert to fix them than for me
Back in 2006 I added a mechanism for defining machine-specific
constraints in the MD file rather than with C macros. This mechanism
offers several advantages over the old way of doing it, but until all
ports are converted, we can't actually implement some of those -- most
important, perhaps, is th
On 4/1/07, Robert Dewar <[EMAIL PROTECTED]> wrote:
Zack Weinberg wrote:
It's not bending the language, the standard has nothing whatever to say
about -D. I see no reason not to be completely permissive wrt -D if it
is going to make transition smoother.
The thing is, the standard do
Ugh. That puts us in the position of having to decide whether command
line definitions "count" as previous definitions for 6.10.3p3.
6.10.3p*2*.
zw
On 4/1/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
* Zack Weinberg <[EMAIL PROTECTED]> [2007-04-01 08:30]:
> This therefore needs to stay a pedwarn at least for the case where the
> redefinition comes from a #define in the source. It's not clear to me
> whet
Martin Michlmayr wrote:
...
- The "no newline" and "xxx redfined" pedwarnings should be converted
into normal warnings. Rationale: no newline doesn't harm anyone and
there are quite a few programs that would fail because of an error
that many agree is too strict. Redefining something with
[resend]
On 3/29/07, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:
> I've attached a patch that should fix it (it
> just reverts the oprintf() changes, which were not really necessary, I
> was just trying to be more efficient).
Thanks, that fixes it for me on i386-pc-mingw32.
committed.
On 3/29/07, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:
Works OK on the cross. So, it's probably a host problem in gengtype.
It appears to exist on HPUX as well, as Steve noted.
Yeah, it appears I was overly optimistic in hoping vsnprintf() would
do what C99 says it does. I do not have
Gabriel Dos Reis wrote:
I don't understand your statement. The C++ (and the C) standard says
# If a source file that is not empty does not end in a new-line
# character, or ends in a new-line character immediately preceded by a
# backslash character, the behavior is undefined.
The GNU prepr
So I've just checked in a patch series which accomplishes about half
of what I was originally aiming to achieve with gengtype, and I'd like
to review what I think should still be done. My ultimate goal - not
just with gengtype - is to remove all hardwired kludges and
dependencies on target header
Ian Lance Taylor writes:
Kazu Hirata <[EMAIL PROTECTED]> writes:
>
> I am aware of the define_constraints patch. I am thinking about
> working on the H8 and M68K ports at least. How urgent is this? FWIW,
> I've reproduced the ICE that Zack mentioned, but I haven't
> investigated it.
It's not
Back in 2000 I wrote a really simple patch that caused gcc to treat an
ASM_OPERANDS that clobbered "pc" as a control flow barrier, exactly
for this problem.
http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00190.html
I still think it was a good idea, but at the time it was received
unenthusiasticall
I want to have a GTY() garbage collected structure such that, when it
is destoyed, some specific routine is called (this should indeed be
possible, since GGC is a mark& sweep garbage collector, which delet
individually each dead data).
if_marked and deletable are not what you want; they are two
> However, there is still a question which puzzles me a lot? Why gengtype is
> not a sort of filter or generator (like yacc is) taking a (list of) files on
> input and producing a file on output?
It used to take a list of files on its command line, but the list
was so long we were running into len
On 10/2/06, Kaveh R. Ghazi <[EMAIL PROTECTED]> wrote:
> Let's not go down the road of including the target config file in
> more places which are not part of the compiler proper - which are
> not even inside the gcc directory!
I agree, but I also want to avoid duplicating the info in two plac
The runtime of what, gcc or fixincludes? Whatever solution we come up
with, I'd like to avoid duplicating setting STDC_0_IN_SYSTEM_HEADERS,
i.e. bad idea to do it once in gcc and once in fixincludes. Better is
if we can include the target config file somehow.
Let's not go down the road of incl
On Thu, Apr 27, 2006 at 05:16:10PM -0700, Joe Buck wrote:
> On Thu, Apr 27, 2006 at 07:58:29PM -0400, Zack Weinberg wrote:
> [ Unicode, UTF-{8,16}, BOMs, etc ]
> > It would also be good to take advantage of the fact that 95+% of C
> > source files start with "/*&q
> I think that CPP should try to determine the encoding for each file
> and not use a single encoding for every file. It should look for
> a unicode header when it opens a file (original c source or any
> include), and if it doesn't find one, use the default: -finput-charset,
> LC_CTYPE, UTF-8, un
It's an interesting system. I wonder if it's powerful enough to express
the rather complicated constraints on objects of type va_list. Warnings
for violations of those constraints would be valuable - there are common
portability errors that could be caught - but it's never been important
enough t
Since mainline is now in bugfixes only mode, and since port conversions
have been being more troublesome than I had hoped, I think it makes sense
to start a branch now to queue up port conversions until the next release
cycle. I can undertake to do periodic mainline-to-branch merges (no more
frequ
My patch to allow defining constraints in the machine description rather
than with tm.h macros has been on mainline for a week now with no serious
problems reported. Now would be a good time to start converting ports.
Conversions are easy, but are best done by port maintainers, as
careful testing
On Tue, Feb 28, 2006 at 10:02:03PM +0100, Gerald Pfeifer wrote:
> That said, I don't really disagree about enforcing proper prerequisites to
> build GCC and its documentation, my question in this case, and in general,
> just is: Can the issue which we encountered be worked around in a simple
> wa
On Wed, Jan 25, 2006 at 04:13:02PM -0800, Steve Ellcey wrote:
>
> I see, in an older GCC build output I see a compilation of
> insn-attrtab.c and I get the messages:
>
> /proj/opensrc/sje/svn/gcc.patch/trunk/gcc/config/ia64/itanium2.md: In
> function 'print_reservation':
> /proj/opensrc/sje/svn/
On Wed, Jan 25, 2006 at 02:10:33PM -0800, Steve Ellcey wrote:
>
> It seems to be coming from the reservation_names array set up in
> print_reservation. One of the entries is:
>
> "(1_0m_bs,1_m_cont)|(1_0mi_bs,1_mi_cont|nothing)|(1_0mm_bs,1_mm_cont)|(1_0mf_bs,1_mf_cont|nothing)|(1_0b_bs,1_b_cont|
On Wed, Jan 25, 2006 at 01:01:17PM -0800, Steve Ellcey wrote:
>
> I took Zack's advice and put all the includes from insn-attrtab.c into
> insn-automata.c. My current problem is that I get:
>
> | insn-automata.c: In function 'print_reservation':
> | insn-automata.c:22466: warning: string length
On Wed, Jan 25, 2006 at 10:17:40AM -0800, Steve Ellcey wrote:
> > 2006-01-25 Andreas Tobler <[EMAIL PROTECTED]>
> >
> > * genautomata.c (main): Add insn-config.h and recog.h to the
> > include list.
> > * Makefile.in (insn-automata.o): Adjust dependencies for the above
>
On Tue, Jan 24, 2006 at 11:55:32PM -0500, Kaveh R. Ghazi wrote:
> Okay, now I get:
[...]
>"build/gencondmd.c", line 60: incomplete struct/union/enum c_test:
> insn_conditions
>"build/gencondmd.c", line 1952: warning: syntax error: empty initializer
>"build/gencondmd.c", line 1952: can
On Tue, Jan 24, 2006 at 10:29:08PM -0500, Kaveh R. Ghazi wrote:
> I'm getting the following new bootstrap failure on both
> sparc-sun-solaris2.10 and sparc64-sun-solaris2.10 when using cc for
> stage1:
>
> > "build/gencondmd.c", line 1943: warning: syntax error: empty initializer
> > "build/gen
On Wed, Jan 25, 2006 at 12:17:00AM +0100, Andreas Tobler wrote:
> Andreas Tobler wrote:
> >I get the following bootstrap break on solaris 8:
> >
> >cc1: warnings being treated as errors
> >insn-automata.c: In function 'internal_insn_latency':
> >insn-automata.c:1969: warning: implicit declaration o
On Mon, Jan 23, 2006 at 10:39:19PM +0100, Marcin Dalecki wrote:
>
> Inside genautomata.c there is a function gen_regexp_el(). It's
> allocating
> a regexp_t by calling create_node(). However the code looks like:
>
> else if (strcmp (str, NOTHING_NAME) == 0)
> {
> regexp = create_nod
On Mon, Jan 23, 2006 at 03:46:10PM -0800, Richard Henderson wrote:
> Got it.
Looks good to me. (Argh, I thought I had caught all of the places where
I made that mistake.) Are you going to check it in?
And here's the fix for genautomata, which had two bugs. One was a
simple case of assuming tha
On Mon, Jan 23, 2006 at 03:28:59PM -0500, Andrew Pinski wrote:
> >
> > On Mon, Jan 23, 2006 at 03:16:56PM -0500, Andrew Pinski wrote:
> > > >
> > > > That's the genextract crash that rth is seeing on ppc-linux. Can you
> > > > also
> > > > reproduce the ppc-darwin genautomata crash?
> > >
> >
On Mon, Jan 23, 2006 at 03:16:56PM -0500, Andrew Pinski wrote:
> >
> > That's the genextract crash that rth is seeing on ppc-linux. Can you also
> > reproduce the ppc-darwin genautomata crash?
>
> Nope. genautomata just works.
Clarification please. In a cross configuration targeting ppc-darwin
On Mon, Jan 23, 2006 at 03:04:25PM -0500, Andrew Pinski wrote:
> >
> > On Mon, Jan 23, 2006 at 11:13:26AM -0800, Richard Henderson wrote:
> > > This is reproducible with an i686 cross.
> >
> > Urgh. And I've got Geert reporting a crash (in a different place)
> > on ppc-darwin.
>
> I was able to
On Mon, Jan 23, 2006 at 11:13:26AM -0800, Richard Henderson wrote:
> This is reproducible with an i686 cross.
Urgh. And I've got Geert reporting a crash (in a different place)
on ppc-darwin.
I won't be able to do anything until I get home, at 4 or 5 Pacific.
If you/anyone feels like fixing it so
> > We can now identify the exact version of gcc t have simply by the
> > revision number and branch name. So maintaining all this stuff in a
> > DATESTAMP, etc, is severe overkill when you could simply use the result
> > of "svnversion .' and commit that to a file, or do it client side).
>
> I th
Gabriel Dos Reis said:
[...]
> Good. It seems to me like those who would be spending a great deal of
> time and money are not sufficiently convinced by your arguments.
> Consequently, it appears that they are not in position to explain your
> strong opinion to the committees -- personally, I'm not
Gabriel Dos Reis said:
> "Zack Weinberg" <[EMAIL PROTECTED]> writes:
>
> | Gabriel Dos Reis said:
> | > C++98 came before C99, so who diverged from whom?
> |
> | It doesn't matter.
>
> Yet, you're you were construeing it as an argument to suppor
Gabriel Dos Reis said:
> "Zack Weinberg" <[EMAIL PROTECTED]> writes:
> | When the standard is arguably buggy -- if nothing else, it diverges from C
>
> C++98 came before C99, so who diverged from whom?
It doesn't matter. The divergence should be resolved in f
Joseph S. Myers said:
> On Fri, 16 Sep 2005, Zack Weinberg wrote:
>> I am with Joe Buck in the opinion that even a 1% performance penalty for
>> implementing (A) [or (B)] would be too much -- I suggest this be fixed by
>> convincing the C++ committee to allow (C) an
[I apologize for breaking the thread; I am currently stuck using a web-mail
client that does not permit manual insertion of References: headers. Please
don't take this comment as a sign that I am resuming participation in GCC
development in general.]
Joseph Myers:
> There are plenty of spare bits
Nix said:
> On 14 Aug 2005, Zack Weinberg yowled:
>> Kaveh R. Ghazi said:
>>> Hmm I'm curious, what systems (if any) have fprintf_unlocked?
>>
>> At the time I thought glibc had it, but I don't see it on my (2.3.5)
>> system now.
>
> It doesn&#
Kaveh R. Ghazi said:
> Hmm I'm curious, what systems (if any) have fprintf_unlocked?
At the time I thought glibc had it, but I don't see it on my (2.3.5)
system now.
baffled,
zw
George R Goffe <[EMAIL PROTECTED]> writes:
> tail: cannot open `+16c' for reading: No such file or directory
> tail: cannot open `+16c' for reading: No such file or directory
> tail: cannot open `+16c' for reading: No such file or directory
You have the buggy version of coreutils that does not re
"wangxiuli" <[EMAIL PROTECTED]> writes:
> Hi some errors appear when compiling gcc-3.4.4 and gcc-4.0.0 on i386
> freebsd -5.2.1.those errrors are caused by byacc's convention of
> arguments .how to solve them?
You must use Bison; we do not support byacc.
zw
Kelley Cook wrote:
> In my local tree, I've updated all the files copyrights with the new FSF
> address (a.k.a. GNU Public License 2, rev 3). This change has already
> been preapproved. I figured committing this in the lull of the GCC
> Summit would be a good time as any.
>
> My question is can
Jakub Jelinek wrote:
> I have posted a patch that implements it, but it hasn't been reviewed
> (yet). If it ever goes in (which would be certainly after 4.0.1 release),
> the next step would be to modify gettext again to grok it.
I sent you a revision yesterday, have you had a chance to look at i
Sergei Organov wrote:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
>
>>Sergei Organov writes:
>> > Hi,
>> >
>> > Using gcc compiled from gcc-4_0-branch, in an attempt to see which
>> > particular optimization option makes my test case to be mis-optimized, I
>> > try to replace -O1 (which toggles
Richard Henderson <[EMAIL PROTECTED]> writes:
> On Mon, Jun 13, 2005 at 07:17:24PM -0700, Zack Weinberg wrote:
>> Or, if GAS can be told which mode it should be in via directives in
>> its input (.code32/.code64?), then we could add something like
>>
>> f
Mark Mitchell <[EMAIL PROTECTED]> writes:
> I would be in favor of making the mode always explicit, as you suggest
> -- but I would prefer that we not embed the assumption that the
> default mode is 64-bit mode in x86-64.h so that we can continue to use
> that file for 32-bit default compilers. (
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> gensupport.c:1122: undefined reference to `insn_elision_unavailable'
> gensupport.c:975: undefined reference to `n_insn_conditions'
> gensupport.c:977: undefined reference to `insn_conditions'
> collect2: ld returned 1 exit status
>
>
> This is an ins
R Hill <[EMAIL PROTECTED]> writes:
> Joe Buck wrote:
>> [The request to create a login] also helps assure that the bug
>> filer is a real person. If Bugzilla provided an anonymous way to
>> file Bugzilla reports, we'd probably have spammers filling the bug
>> database with ads for penis enlargemen
On Tue, 2005-05-24 at 20:54 -0400, DJ Delorie wrote:
> > This doesn't do what I want at all. The goal is to make the *symbolic
> > enumeration constants* inaccessible to most code.
>
...
> If it's OK to have the enums in a header, provided you can't *use* them...
>
> enum {
> #ifdef TVQ_AUTHORIT
On Tue, 2005-05-24 at 20:27 -0400, DJ Delorie wrote:
> > This is still not an answer to the question I originally asked - do you
> > see any way IN C to write code which has the relevant property of the
> > class above (that is, that the FOOmode constants are not accessible
> > except to authorized
On Tue, 2005-05-24 at 20:11 -0400, Daniel Jacobowitz wrote:
> On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote:
> > Well, if I were running the show, the 'clock' would only start running
> > when it was consensus among the libstdc++ developers that the sonam
On Wed, 2005-05-25 at 01:45 +0200, Paolo Carlini wrote:
> >.. However, the active development on the
> >libstdc++.so.7 branch means that we haven't even started the clock
> >running on this criterion yet.
>
> Maybe a clarification is in order: actually, the name
> libstdcxx
On Wed, 2005-05-25 at 03:03 +0200, Gabriel Dos Reis wrote:
> Zack Weinberg <[EMAIL PROTECTED]> writes:
>
> | On Tue, 2005-05-24 at 10:49 +0200, Gabriel Dos Reis wrote:
> | > | So you don't see any value whatsoever to having (for instance) the
> | > | individual con
On Tue, 2005-05-24 at 19:17 -0400, Daniel Jacobowitz wrote:
> On Tue, May 24, 2005 at 04:20:27PM -0700, Zack Weinberg wrote:
> > Um, there have been plenty of cases in the past where the top level set
> > something correctly and the subdirectory makefiles overrode it with an
> &
On Tue, 2005-05-24 at 09:41 -0400, Daniel Jacobowitz wrote:
> We've fixed a lot of these problems already; I will be brave and say
> that we have fixed most of them.
I'm glad you're optimistic about it. It's good to have someone
balancing out pessimistic people like me. :)
> > This scenario, at
On Tue, 2005-05-24 at 10:49 +0200, Gabriel Dos Reis wrote:
> | So you don't see any value whatsoever to having (for instance) the
> | individual constants of 'enum machine_mode' be inaccessible in most of
> | GCC? 'cos I sure do.
>
> What I'm saying is that when you have a name like EXPAND_NORMAL,
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> But we do not get any expressive power by using C++ keywords.
Readability, readability, readability.
(for instance, 'class' vs. 'klass' - I can read decimal orders of
magnitude faster if all the English words in what I'm reading are
correctly spel
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
[dropping most of the message - if I haven't responded, assume I don't
agree but I also don't care enough to continue the argument. Also,
rearranging paragraphs a bit so as not to have to repeat myself]
> with the explicit call to malloc + explicit sp
Mark Mitchell <[EMAIL PROTECTED]> writes:
...
> Like you, I do think these problems are surmountable; but, also like
> you, I think it would take some time to get all the problems solved.
> I don't really think, though, that this is immediately relevant;
> Gaby's trying to fix things that seem to m
Mark Mitchell <[EMAIL PROTECTED]> writes:
[snip stuff addressed elsewhere]
> I agree with the goal of more hiding.
>
> You can do this in C by using an incomplete structure type in most
> places, and then, in the files where you want the definition visible,
> defining the structure to have a singl
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
[...]
> The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC
> and such. It is not anything you'll find in the code directly. So,
> in fact we do not lose readability as you claim.
To be honest, I think XNEW* are less readable than bar
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote:
>> Furthermore, as I've said before, I support migrating
>> to C++ -- but only if the C++ ABI and libstdc++ soname are first
>> permanently frozen. If
On Mon, 2005-05-23 at 01:15 -0500, Gabriel Dos Reis wrote:
> Hi,
>
> I spent the week-end trying to get GCC -- mainline -- compilable
> (i.e. those compoenents written in C) with a C++ compiler (e.g. g++).
These results are very interesting.
As a general observation: A lot of the things you ha
1 - 100 of 179 matches
Mail list logo
