* David Brown:
>> C23 changes meaning of of extern foo(); to match the C++
>> interpretation of extern foo(void);. I don't think we should warn
>> about that. If we warn, it would be at the call site.
>
> I'm not sure I fully agree. "extern foo();" became invalid when
> implicit int was removed
On 11/10/2023 12:17, Florian Weimer wrote:
* David Brown:
On 11/10/2023 10:10, Florian Weimer wrote:
* David Brown:
So IMHO (and as I am not a code contributor to GCC, my opinion really
is humble) it is better to be stricter than permissive, even in old
standards. It is particularly impo
* David Brown:
> On 11/10/2023 10:10, Florian Weimer wrote:
>> * David Brown:
>>
>>> So IMHO (and as I am not a code contributor to GCC, my opinion really
>>> is humble) it is better to be stricter than permissive, even in old
>>> standards. It is particularly important for "-std=c89", while
>>>
On 11/10/2023 10:10, Florian Weimer wrote:
* David Brown:
So IMHO (and as I am not a code contributor to GCC, my opinion really
is humble) it is better to be stricter than permissive, even in old
standards. It is particularly important for "-std=c89", while
"-std=gnu89" is naturally more pe
* David Brown:
> So IMHO (and as I am not a code contributor to GCC, my opinion really
> is humble) it is better to be stricter than permissive, even in old
> standards. It is particularly important for "-std=c89", while
> "-std=gnu89" is naturally more permissive. (I have seen more than
> enoug
On 10/10/2023 18:30, Jason Merrill via Gcc wrote:
On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc
wrote:
Are these code fragments valid C89 code?
int i1 = 1;
char *p1 = i;
char c;
char *p2 = &c;
int i2 = p2;
Or can we generate errors for them even with -std=gnu89?
(It
On Tue, Oct 10, 2023 at 12:09 PM Florian Weimer via Gcc
wrote:
> * Jakub Jelinek:
>
> > On Tue, Oct 10, 2023 at 12:30:52PM -0400, Jason Merrill via Gcc wrote:
> >> On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc >
> >> wrote:
> >>
> >> > Are these code fragments valid C89 code?
> >> >
> >
* Joseph Myers:
> On Tue, 10 Oct 2023, Florian Weimer via Gcc wrote:
>
>> Are these code fragments valid C89 code?
>>
>> int i1 = 1;
>> char *p1 = i;
>>
>> char c;
>> char *p2 = &c;
>> int i2 = p2;
>
> Implicit conversions between pointers and integers are not valid C89.
>
> ANSI C89,
* Jakub Jelinek:
> On Tue, Oct 10, 2023 at 12:30:52PM -0400, Jason Merrill via Gcc wrote:
>> On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc
>> wrote:
>>
>> > Are these code fragments valid C89 code?
>> >
>> > int i1 = 1;
>> > char *p1 = i;
>> >
>> > char c;
>> > char *p2 = &c;
>>
On Tue, 10 Oct 2023, Florian Weimer via Gcc wrote:
> Are these code fragments valid C89 code?
>
> int i1 = 1;
> char *p1 = i;
>
> char c;
> char *p2 = &c;
> int i2 = p2;
Implicit conversions between pointers and integers are not valid C89.
ANSI C89, as adopted as FIPS PUB 160, is ava
On Tue, Oct 10, 2023 at 12:30:52PM -0400, Jason Merrill via Gcc wrote:
> On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc
> wrote:
>
> > Are these code fragments valid C89 code?
> >
> > int i1 = 1;
> > char *p1 = i;
> >
> > char c;
> > char *p2 = &c;
> > int i2 = p2;
> >
> > Or ca
On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc
wrote:
> Are these code fragments valid C89 code?
>
> int i1 = 1;
> char *p1 = i;
>
> char c;
> char *p2 = &c;
> int i2 = p2;
>
> Or can we generate errors for them even with -std=gnu89?
>
> (It will still be possible to override th
Are these code fragments valid C89 code?
int i1 = 1;
char *p1 = i;
char c;
char *p2 = &c;
int i2 = p2;
Or can we generate errors for them even with -std=gnu89?
(It will still be possible to override this with -fpermissive or
-Wno-int-conversion.)
Thanks,
Florian
13 matches
Mail list logo
