> I could have sworn it was NTFS...
>
> util.h:
> typedef enum {
> FILE_$Mft = 0,
> FILE_$MftMirr = 1,
What kernel version? In 2.4.10, this reads
typedef enum {
FILE_Mft= 0,
FILE_MftMirr= 1,
FILE_LogFile= 2,
...
Regards,
Martin
On Wed, 28 Nov 2001, Matthew Wilcox wrote:
> The followup to #120333 indicates this is a bug with g++; is anyone
> looking into this? i see no discussing on debian-gcc about it, but i'm
> reluctant to simply reassign it to gcc.
I'm trying to get to it :-) It looks very similar to an EH problem
The followup to #120333 indicates this is a bug with g++; is anyone
looking into this? i see no discussing on debian-gcc about it, but i'm
reluctant to simply reassign it to gcc.
--
Revolutions do not require corporate support.
On Tue, 27 Nov 2001, Martin v. Loewis wrote:
> Unlikely. The original gdb "backtrace" indicated that somebody was
> jumping to address 0. I think potential causes are:
>
> 1. dynamic initialization of a shared library has not been carried
>out. It would be interesting to verify that all shar
On Tue, 27 Nov 2001, John R. Daily wrote:
> I haven't seen any reponse from Ben, so I'm going to go ahead and
> move the bug to glibc. It would be rather unfortunate if this
> isn't fixed for woody, but at this point that may be impossible.
Ok. I'll work it out with him when he gets back from v
On Tue, 27 Nov 2001, Daniel Jacobowitz wrote:
> I could have sworn it was NTFS...
>
> util.h:
> typedef enum {
> FILE_$Mft = 0,
> FILE_$MftMirr = 1,
> etc.
>
> I'm fairly certain that DOLLARS_IN_IDENTIFIERS affects the legality of
> that enum.
Yes, it does and you're co
On Tue, 27 Nov 2001, Martin v. Loewis wrote:
> That isn't really true, is it? Atleast in the NTFS code, I cannot find
> such code (and I can't remember writing it, either :-).
Hehehe...I seem to remember seeing such code in the kernel source, but
that was some time ago and I haven't looked for i
On Tue, 27 Nov 2001, Martin v. Loewis wrote:
> According to the GCC documentation, the rationale for this feature is
> that traditional C allows it, but ISO C and ISO C++ disallow it.
>
> So I'd say that, if all Debian packages either build fine without it,
> or enable it when needed, turning it
On Tue, Nov 27, 2001 at 10:18:37PM +0100, Martin v. Loewis wrote:
> > You won't be able to build X86 kernels if you do that :) Well, not
> > with things like NTFS support, at least.
>
> That isn't really true, is it? Atleast in the NTFS code, I cannot find
> such code (and I can't remember writ
I haven't seen any reponse from Ben, so I'm going to go ahead and
move the bug to glibc. It would be rather unfortunate if this
isn't fixed for woody, but at this point that may be impossible.
--
John R. DailyProgeny Linux Systems
Consultant
Processing commands for [EMAIL PROTECTED]:
> reassign 119844 glibc
Bug#119844: gcc: __WORDSIZE definition missing
Bug reassigned from package `gcc' to `glibc'.
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
(administrator, D
> You won't be able to build X86 kernels if you do that :) Well, not
> with things like NTFS support, at least.
That isn't really true, is it? Atleast in the NTFS code, I cannot find
such code (and I can't remember writing it, either :-).
> I'm most strongly of the opinion that this isn't Debi
> So, my question is, what are the criteria for determining whether or not
> gcc should reject identifiers with dollars?
According to the GCC documentation, the rationale for this feature is
that traditional C allows it, but ISO C and ISO C++ disallow it.
So I'd say that, if all Debian packages
> > Thanks for the testcase. I meant to make one when alpha started having EH
> > problems awhile back, but never got to itMatthias, I believe this one
> > will also catch the case that I saw on alpha.
>
> Interesting enough the program works as expected when compiled with
> -static like "g++
On Tue, Nov 27, 2001 at 01:33:25PM -0500, Christopher C. Chimelis wrote:
>
> On Tue, 27 Nov 2001, Daniel Jacobowitz wrote:
>
> > As with that bug, no, GCC should complain about dollars starting
> > identifiers. Try using b$c instead of $b.
>
> Oddly enough, our powerpc gcc packages have --no-do
On Tue, Nov 27, 2001 at 06:04:21PM +0100, Guido Guenther wrote:
[..]
> > Thanks for the testcase. I meant to make one when alpha started having EH
> > problems awhile back, but never got to itMatthias, I believe this one
> > will also catch the case that I saw on alpha.
>
> Interesting enough
On Tue, 27 Nov 2001, Daniel Jacobowitz wrote:
> As with that bug, no, GCC should complain about dollars starting
> identifiers. Try using b$c instead of $b.
Oddly enough, our powerpc gcc packages have --no-dollars-in-identifiers
enabled by default, despite gas having no problems handling things
On Mon, Nov 26, 2001 at 08:01:26PM +0100, Bill Allombert wrote:
> Package: gcc-3.0
> Version: 1:3.0.2-3
> Severity: minor
>
> Hello GCC maintainers,
> As I reported in #121269,
>
> gcc-3.0 allows $ in identifiers by default on i386 but not the asm,
> so compiling the example given in #121269 fail
On Tue, 27 Nov 2001, Guido Guenther wrote:
> Interesting enough the program works as expected when compiled with
> -static like "g++ -ggdb -o throw-2.95 throw.cc" (linker bug?)
Hmmm...maybe, but I don't know until looking at it. I rebooted my Indy
last night, so I'll start playing with the tool
On Mon, Nov 26, 2001 at 01:47:55PM -0500, Christopher C. Chimelis wrote:
>
> On Mon, 26 Nov 2001, Guido Guenther wrote:
>
> > Could you check the source code if these packages crash while messing
> > with C++ exceptions? I just had a quick look into the menu package and
> > it seems that C++ exce
>Submitter-Id: net
>Originator:Johan Walles
>Organization:
>Confidential: no
>Synopsis: Internal compiler error on (probably) legal code
>Severity: critical
>Priority: medium
>Category: c
>Class: ice-on-legal-code
>Release: 3.0.2 20011014 (Debian prereleas
21 matches
Mail list logo
