On 5/14/23 1:28 AM, Po Lu wrote:
>> You may feel free to take an exact GCC release (source or binary),
>> analyze it, reverse-engineer it, or verify that it does what you want
>> it to do, and then trust that those undefined and undocumented
>> behaviors are ***benevolent***, but that doesn't cause
On 5/14/23 1:28 AM, Po Lu wrote:
>> GCC has formal documentation. It is written in HTML. If it is lacking,
>> then the only valid move is to improve the HTML documentation and then
>> abide by it. In the absence of documentation, all behavior is, well,
>> "undocumented", which ***definitely*** mean
On 5/13/23 1:53 AM, Po Lu wrote:
> There are no ``errors'' in Standard C (with the possible exception of
> the #error preprocessing directive), only constraint and syntax rule
> violations. Such violations are required to generate diagnostic
> messages, after which the behavior of the translator c
On 5/12/23 8:45 PM, Po Lu wrote:
> Gabriel Ravier writes:
>
>> ...You're joking, right ? You can't possibly be seriously arguing
>> this, you have to be kidding... right ?
>
> No, I'm not. The meaning of a variable declaration with only a storage
> class specifier is extremely clear: the type o
On 5/12/23 2:01 AM, Po Lu wrote:
> Jason Merrill writes:
>
>> You shouldn't have to change any of those, just configure with CC="gcc
>> -fwhatever".
>
> If it were so simple...
>
> Many Makefiles come with a habit of using not CC_FOR_BUILD, but just
> `cc', to build programs which are run on th
On 5/12/23 1:57 AM, Po Lu wrote:
> Eli Schwartz writes:
>> It's still no big deal, no matter how much you dramatize the intensity
>> of adding a flag to your Makefiles.
>
> It's extra work. Why don't I just write:
>
> extern int foo ();
>
> above each of the new errors?
> That is just about
On 5/11/23 10:39 PM, Po Lu wrote:
>> If so, then as far as I can tell, that was the original plan? The flag
>> already exists, even. And the original proposal was to provide another
>> flag that doesn't even restrict you to c89.
>
> And what will guarantee this ``always'' always remains true?
No
On 5/11/23 10:08 PM, Po Lu wrote:
>> I do not consider that you are being told what to do with your code.
>> Your code is not being broken. You may have to update your Makefile to
>
>
> My code is being broken. There are thousa
On 5/11/23 2:24 AM, Eli Zaretskii wrote:
> Please be serious, and please don't mock your opponents. This is a
> serious discussion of a serious subject, not a Twitter post.
I responded with precisely the degree of seriousness as the statement I
responded to.
For the record, I believe both state
On 5/11/23 2:18 AM, Po Lu wrote:
> Eli Schwartz writes:
>> Absolutely! It's a very good point. It's a point that people writing
>> traditional not-C in this day and age are doing so with highly complex
>> toolchains they have personally written to do things that no non-bespoke
>> toolchain does. A
On 5/11/23 2:12 AM, Eli Zaretskii wrote:
>> Date: Wed, 10 May 2023 23:14:20 -0400
>> From: Eli Schwartz via Gcc
>>
>> Second of all, why is this GCC's problem? You are not a user of GCC,
>> apparently.
>
> He is telling you that removing support for these
On 5/11/23 12:46 AM, Eli Schwartz wrote:
> On 5/10/23 11:56 PM, Po Lu wrote:
>> And remember that `-traditional' DID exist for a certain amount of time.
>> Then it was removed. So in addition to annoying a lot of people, what
>> guarantees that -Wno-implicit will not be removed in the future, afte
On 5/10/23 11:56 PM, Po Lu wrote:
> Eli Schwartz writes:
>
>>> Unfortunately, we do not have the source code for our compiler. Would
>>> you care to ask people here to restore `gcc -traditional'?
>>
>>
>> This would appear to be a self-inflicted wound. If I understand the
>> chain of events prop
> Unfortunately, we do not have the source code for our compiler. Would
> you care to ask people here to restore `gcc -traditional'?
This would appear to be a self-inflicted wound. If I understand the
chain of events properly...
- gcc drops support for -traditional
- you wish to use code that
14 matches
Mail list logo
