Hi all,
although this is a problem of the C standard, I still
find it annoying that the following code produces warnings
about incompatible pointer types (this has been discussed
before, see below):
extern void test(const double x[2][2]);
void foo(void)
{
double x[2][2];
const
Manuel López-Ibáñez :
Thank you for your quick response.
> > Could we have an option to turn these warnings off?
>
> This will be controlled by a new option in GCC 5.0.
>
> For the details and the answer to your other questions, see
> https://gcc.gnu.org/wiki/FAQ#constmismatch
The option '-Win
Manuel López-Ibáñez :
> > Could we have an option to turn these warnings off?
>
> This will be controlled by a new option in GCC 5.0.
>
> For the details and the answer to your other questions, see
> https://gcc.gnu.org/wiki/FAQ#constmismatch
>
> (If others have comments that are not covered in
Am Tue, 14 Oct 2014 00:05:47 +0100
Jonathan Wakely :
> On 14 October 2014 00:01, Martin Uecker wrote:
> > Manuel López-Ibáñez :
> >
> > Thank you for your quick response.
> >
> >> > Could we have an option to turn these warnings off?
> >>
> &g
Manuel López-Ibáñez :
> On 14 October 2014 01:12, Martin Uecker wrote:
> > Converting a pointer to an array to a pointer to a constant array
> > is safe. Converting a pointer to a pointer to a pointer to a pointer
> > to a constant is not (as the CFAQ points out).
>
Sorry for bringing this up again, but this could work:
void foo(int x, int (*s)[x])
{
(*s)[x] = 1;// <- undefined behaviour
}
Such an access beyond the specified length means that either
1. the array is accessed out-of-bounds or
2. was accessed using an incompatible pointer
and a
rn 1 ? p : p2; }
Index: gcc/testsuite/gcc.dg/pointer-arrays-quals.c
=======
--- gcc/testsuite/gcc.dg/pointer-arrays-quals.c (Revision 0)
+++ gcc/testsuite/gcc.dg/pointer-arrays-quals.c (Arbeitskopie)
@@ -0,0 +1,28 @@
+/* { dg-do compile } */
Jonathan Wakely :
> On 27 October 2014 13:10, Joseph S. Myers wrote:
> > On Sat, 25 Oct 2014, Martin Uecker wrote:
> >
> >> Strictly speaking the C standard considers such pointers to be
> >> incompatible. This seems to be an unintentional consequence
> >>
ic
Note that there is now a semantic (and not only diagnostic) change.
Without this patch
const int a[1];
int b[1];
(x ? &a : &b)
would return a 'void*' and a warning about pointer type mismatch.
With this patch the conditional has type 'const int (*)[1]'.
I am trying to get more useful warnings for array bounds.
In particular I am interested in cases like this:
void foo(int (*a)[3], int n, int (*b)[n])
{
(*a)[4] = 1;
(*b)[n + 1] = 1;
}
That currently even the first assignment does not produce a warning
is a bit disappointing. (cl
Jakub Jelinek :
> On Mon, Nov 10, 2014 at 12:20:03AM -0800, Martin Uecker wrote:
> > There is also no warning in the following example
> > when the array is the last element of a struct.
> >
> > struct h3 {
> > int i;
> > int j[3];
> &
Jakub Jelinek :
> On Mon, Nov 10, 2014 at 12:52:02AM -0800, Martin Uecker wrote:
> > Jakub Jelinek :
...
> > The warning seems very useful to me and can easily be turned off.
> > Or one could add -W(no-)warn-struct-hack if really needed.
> >
> > Another
Manuel López-Ibáñez :
> On 14 October 2014 01:12, Martin Uecker wrote:
> > Converting a pointer to an array to a pointer to a constant array
> > is safe. Converting a pointer to a pointer to a pointer to a pointer
> > to a constant is not (as the CFAQ points out).
>
Hi all,
I am writing numerical code, so I am trying to make the use
of arrays in C (with gcc) suck a bit less. In general, the long term
goal would be to have either a compile-time warning or the possibility
to get a run-time error if one writes beyond the end of an array as
specified by its ty
Manuel López-Ibáñez :
> On 26 January 2015 at 19:15, Martin Uecker wrote:
> >
> > Since my patch to change this has been accepted, could you please
> > update the FAQ again?
>
> Done. Moreover, if you create a wiki account, I will grant you editing powers.
tha
Am Tue, 27 Jan 2015 15:15:08 -0500
"Frank Ch. Eigler" :
> Hi -
>
> > > thank you, I tried creating an account, but it said: Unknown action
> > > newaccount.
> > Frank, do you know what the problem might be?
>
> Yes, this facility was temporarily disabled, as a load-shedding
> measure. I'll tur
Marek Polacek :
> Sorry for late reply - I've found this in my inbox only today.
>
> On Mon, Jan 26, 2015 at 11:53:59AM -0800, Martin Uecker wrote:
>
> > Finally, what is missing is a way to diagnose problems inside
> > the called functions. -Warray-bounds=2 (
Martin Uecker :
> Marek Polacek :
>
> > > void foo(int (*x)[4])
> > > {
> > > (*x)[4] = 5;// warning
> > > }
> >
> > This is detected by -fsanitize=object-size, turned on by default in
> > -fsanitize=undefined. Since it makes
Hi Manuel,
sorry for the late reply, I was travelling last week.
My account name is: MartinUecker
Martin
Manuel López-Ibáñez :
> Martin,
>
> did you manage to create a wiki account?
>
> I can add you to the editors group then.
>
> On 27 January 2015 at 22:54, Martin
Campbell Barton :
...
> Given the simple function:
>
> void print_v3(float v[static 3])
> {
> printf("%f %f %f\n", v[0], v[1], v[2]);
> }
>
> Calling `foo(NULL);` or `{ float v[2]; foo(v); }` should be able to
> cause a warning, it would be useful since this is a farily
Yes. I want this too
Am Tue, 5 May 2015 21:37:10 -0700
Andrew Pinski :
> On Tue, May 5, 2015@9:00 PM, Aditya K wrote:
> >>>
> >>> gcc/rtlanal.c:5573:23: warning: array index 1 is past the end of the
> >>> array (which contains 1 element) [-Warray-bounds]
> >>> ../../gcc/rtlanal.c:5573:23: warning: array index 1 is p
Am Mon, 04 May 2015 18:28:49 +0200
schrieb Manuel López-Ibáñez :
> On 04/05/15 07:40, Martin Uecker wrote:
> >
> > BTW: Why is 'nonnull' a function attribute and not something
> > which can be attached to pointer types?
>
> I think this is somethi
Am Fri, 8 May 2015 11:04:22 +
Joseph Myers :
> On Fri, 8 May 2015, Manuel López-Ibáñez wrote:
>
> > "At present, the first parameter in a function prototype must have
> > some type specifier that is not an attribute specifier; this resolves
> > an ambiguity in the interpretation of void f(int
mark maule :
> On 5/20/2015 3:27 AM, Richard Biener wrote:
> > On Mon, May 18, 2015 at 10:01 PM, mark maule wrote:
> > The usual issue with this kind of behavior is out-of-bound accesses of
> > arrays in a loop
> > or invoking undefined behavior when signed integer operations wrap.
> >
> >
> >
Am Thu, 21 May 2015 07:45:19 -0500
schrieb mark maule :
>
>
> On 5/20/2015 2:13 PM, Martin Uecker wrote:
> > mark maule :
> >> On 5/20/2015 3:27 AM, Richard Biener wrote:
> >>> On Mon, May 18, 2015 at 10:01 PM, mark maule
> >>> wrote:
> &g
Hi all,
does anybody know if all architectures support passing
an environment pointer in their function call ABI?
Are the some where this does not exist?
Is there are table somewhere which lists the
register (or stack slot) used for this for
all architectures?
Somehow I could not find this
Am Mittwoch, dem 13.10.2021 um 15:21 + schrieb Michael Matz:
> Hello,
>
> On Wed, 13 Oct 2021, Martin Uecker wrote:
>
> > does anybody know if all architectures support passing
> > an environment pointer in their function call ABI?
>
...
>
> Or you could m
Am Donnerstag, dem 14.10.2021 um 13:17 + schrieb Michael Matz:
> Hello,
>
> On Wed, 13 Oct 2021, Martin Uecker wrote:
>
> > > [... static chain ...]
> > > If you mean that, then it's indeed psABI specific, and possibly
> > > not
> > > al
Am Samstag, dem 03.12.2022 um 22:03 +0100 schrieb Alejandro Colomar:
...
> Since we've seen that using a '.' prefix seems to be problematic
> because of lookahead, and recently Michael Matz proposed using a
> different punctuator (he proposed '@') for differentiating parameters
> from struct member
Hi all,
what is the process for adding a new UBsan handler?
We have the source in the GCC tree, but I guess this
should go via LLVM?
Martin
Am Montag, dem 19.12.2022 um 09:44 +0100 schrieb Martin Liška:
> On 12/17/22 20:35, Martin Uecker wrote:
> >
> >
> > Hi all,
> >
> > what is the process for adding a new UBsan handler?
>
> Hello.
>
> Yes, we sync the run-time library from LLVM pr
Am Montag, dem 19.12.2022 um 15:22 +0100 schrieb Martin Liška:
> On 12/19/22 10:25, Martin Uecker wrote:
> > Am Montag, dem 19.12.2022 um 09:44 +0100 schrieb Martin Liška:
> > > On 12/17/22 20:35, Martin Uecker wrote:
> > > >
> > > >
> > >
Does anybody have a CI configuration file for gitlab
that does bootstrapping and runs the testsuite?
Martin
Sounds like named address spaces to me:
https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html
Best,
Martin
Am Dienstag, dem 27.06.2023 um 14:26 +0200 schrieb Rafał Pietrak via Gcc:
> Hello everybody,
>
> I'm not quite sure if this is correct mailbox for this suggestion (may
> be "embed
Am Mittwoch, dem 28.06.2023 um 16:44 +0100 schrieb Richard Earnshaw (lists):
> On 28/06/2023 15:51, Rafał Pietrak via Gcc wrote:
> > Hi Martin,
> >
> > W dniu 28.06.2023 o 15:00, Martin Uecker pisze:
> > >
> > > Sounds like named address spaces to me:
&
Am Mittwoch, dem 28.06.2023 um 17:49 +0100 schrieb Richard Earnshaw (lists):
> On 28/06/2023 17:07, Martin Uecker wrote:
> > Am Mittwoch, dem 28.06.2023 um 16:44 +0100 schrieb Richard Earnshaw (lists):
> > > On 28/06/2023 15:51, Rafał Pietrak via Gcc wrote:
> > > >
Am Dienstag, dem 04.07.2023 um 16:46 +0200 schrieb Rafał Pietrak:...
> >
> > I think a C++ class (or rather, class template) with inline functions is
> > the way to go here. gcc's optimiser will give good code, and the C++
> > class will let you get nice syntax to hide the messy details.
>
>
Am Mittwoch, dem 05.07.2023 um 07:26 +0200 schrieb Rafał Pietrak:
> Hi,
>
> W dniu 5.07.2023 o 00:57, Martin Uecker pisze:
> > Am Dienstag, dem 04.07.2023 um 16:46 +0200 schrieb Rafał Pietrak:...
> []
> > >
> > > Yes. named address spac
Am Mittwoch, dem 05.07.2023 um 11:11 +0200 schrieb David Brown:
> On 05/07/2023 10:05, Rafał Pietrak via Gcc wrote:
...
>
> In my personal opinion (which you are all free to disregard), named
> address spaces were an interesting idea that failed. I was
> enthusiastic
> about a number of the ex
Am Mittwoch, dem 05.07.2023 um 10:05 +0200 schrieb Rafał Pietrak:
> Hi,
>
> W dniu 5.07.2023 o 09:29, Martin Uecker pisze:
> > Am Mittwoch, dem 05.07.2023 um 07:26 +0200 schrieb Rafał Pietrak:
> [---]
> > > And if it's so ... there is no mention of how does i
Am Mittwoch, dem 05.07.2023 um 12:17 +0200 schrieb Rafał Pietrak:
> Hi
>
> W dniu 5.07.2023 o 11:29, Martin Uecker pisze:
> > Am Mittwoch, dem 05.07.2023 um 10:05 +0200 schrieb Rafał Pietrak:
>
...
> >
> > > Then again, should you happen to fall onto an
> &
not need to discuss this now. I still very
much appreciate your input!
Note that I am involved with C standardization, but
TR 18307 precedes this.
Martin
Am Mittwoch, dem 05.07.2023 um 13:34 +0200 schrieb David Brown:
>
>
> On 05/07/2023 11:25, Martin Uecker wrote:
> > A
Am Mittwoch, dem 12.07.2023 um 15:23 +0200 schrieb Benjamin Priour via
Gcc:
> Hi David,
>
>
> Lately I've been working on adding a new state machine to keep track
> of
> ownership transfers
>
> and misuses, e.g. to warn about use-after-move, partial or shallow
> copy/move.
>
> I'm trying to sta
Am Montag, dem 10.07.2023 um 22:16 +0200 schrieb Alejandro Colomar via Gcc:
> On 7/10/23 22:14, Alejandro Colomar wrote:
> > [CC += Andrew]
> >
> > Hi Xi, Andrew,
> >
> > On 7/10/23 20:41, Xi Ruoyao wrote:
> > > Maybe we should have a weaker version of nonnull which only performs the
> > > diagno
timization. I think
clang uses it for optimization.
Martin
> i've seen
> proposals like
> https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854/
> but i haven't seen anything i can use yet, so you -- who do use GCC
> which aiui has something
Hi Alejandro!
Am Mittwoch, dem 09.08.2023 um 12:42 +0200 schrieb Alejandro Colomar:
...
>
> As for when one would want to mean the first (size of array)
> but not _Nonnull: for a function where you may pass either
> an array (which should not be smaller than the size), or a
> sentinel NULL va
Am Mittwoch, dem 09.08.2023 um 14:37 +0200 schrieb Alejandro Colomar:
> Hi Martin!
>
> On 2023-08-09 14:03, Martin Uecker wrote:
>
> Regarding the issues you have with _Nonnull being a qualifier,
> I've been thinking about it for a long time and don't yet have
>
Am Montag, dem 14.08.2023 um 11:51 +0200 schrieb Alejandro Colomar via Gcc:
> Hi Richard,
>
> On 2023-08-14 08:41, Richard Biener wrote:
> > On Fri, Aug 11, 2023 at 8:30 PM Alejandro Colomar via Gcc
> > wrote:
>
> [...]
>
> > > How about some -Wfam-sizeof-arithmetic that would not warn about ta
Am Montag, dem 18.09.2023 um 10:06 +0200 schrieb Richard Biener via Gcc:
> On Mon, Sep 18, 2023 at 9:51 AM Alexander Monakov wrote:
> >
> > Hi Florian,
> >
> > On Thu, 14 Sep 2023, Alexander Monakov wrote:
> >
> > >
> > > On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote:
> > >
> > > > While
Am Montag, dem 18.09.2023 um 14:43 +0300 schrieb Alexander Monakov:
> On Mon, 18 Sep 2023, Jakub Jelinek wrote:
>
> > Perhaps we should add some initial hammer approach for the pragma, like
> > if you ever use the pragma to turn it somewhere off, it is turned off
> > globally, or ditto per functio
Am Montag, dem 18.09.2023 um 19:56 +0200 schrieb Paul Floyd via Gcc:
>
> On 18-09-23 16:55, Richard Biener wrote:
>
> > What you could do is report the access only on the point of use of
> > the accessed value? (and disregard when the register holding the
> > value is re-used)
>
> Hi Richard
>
Am Montag, dem 18.09.2023 um 22:15 +0200 schrieb Paul Floyd via Gcc:
>
> On 18-09-23 21:09, Martin Uecker wrote:
>
> > I do not understand why memcheck cares about the potential trap when
> > deciding to do the backwards transformation that combines the two
> > c
GCC supports this as an extension.
Mixing declarations and code is allowed in C99 and C23
will also allow placing labels before declarations and at
the end of a compound statement. GCC supports all this
also in earlier language modes.
See:
https://gcc.gnu.org/onlinedocs/gcc/Mixed-Labels-and-
Note that the C++ warning is for jumping over a declaration,
which is generally allowed in C but not in C++.
Martin
Am Donnerstag, dem 19.10.2023 um 13:49 +0200 schrieb Martin Uecker:
>
>
> GCC supports this as an extension.
>
> Mixing declarations and code is allowed
I think this is the same bug already filed here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70954
Martin
Am Mittwoch, dem 01.11.2023 um 09:11 +0100 schrieb Rene Kita:
> Since I'm unable to create an account to report a bug and got no reply
> from gcc-bugzilla-account-requ...@gcc.gnu.org I'll
Am Dienstag, dem 21.11.2023 um 02:30 + schrieb André Albergaria Coelho via
Gcc:
> Hello
>
> #include
>
> void func(char *ptr) {
> printf("\n%i",sizeof(ptr));
> }
>
> int main(void) {
> char arr[10];
> printf("\n Sizeof arr %i",sizeof(arr));
> func(arr);
>
> return
Hi list,
the strings in the ".debug_str" section are output
in an arbitrary order. Could this be changed?
The function 'output_indirect_strings' in 'gcc/dwarf2out.c'
uses htab_traverse which then outputs the string in the
order they appear in the hash table. Instead, it would
be nicer to output
Am Mon, 17 Mar 2014 09:44:53 +0100
schrieb Richard Biener :
> On Sun, Mar 16, 2014 at 3:58 AM, Martin Uecker
> wrote:
> >
> > Hi list,
> >
> > the strings in the ".debug_str" section are output
> > in an arbitrary order. Could this be changed?
>
> On Wed, 4 Aug 2021 at 03:27, Segher Boessenkool
> wrote:
> >
> > Hi!
> >
> > On Fri, Jul 23, 2021 at 04:23:42PM +0530, Prathamesh Kulkarni via Gcc wrote:
> > > The constraint here is that, vshl_n intrinsics require that the
> > > second arg (__b),
> > > should be an immediate value.
> >
> > Some
It would be great if somebody could take a look at
PR96159.
It seems we do not do atomic accesses correctly
when the alignment is insufficient for a lockfree
access, but I think we should fall back to a
library call in this case (as clang does).
This is very unfortunate as it is an important
f
Am Sonntag, den 07.11.2021, 10:24 +0100 schrieb Florian Weimer:
> * Martin Uecker via Gcc:
>
> > It would be great if somebody could take a look at
> > PR96159.
> >
> > It seems we do not do atomic accesses correctly
> > when the alignment is insufficient fo
Am Montag, den 08.11.2021, 11:59 + schrieb Jonathan Wakely:
> On Sun, 7 Nov 2021, 09:08 Martin Uecker wrote:
>
> > It would be great if somebody could take a look at
> > PR96159.
> >
> > It seems we do not do atomic accesses correctly
> > when the alig
Am Sonntag, den 07.11.2021, 10:08 +0100 schrieb Martin Uecker:
> It would be great if somebody could take a look at
> PR96159.
>
> It seems we do not do atomic accesses correctly
> when the alignment is insufficient for a lockfree
> access, but I think we should fall back to a
Am Freitag, den 26.11.2021, 09:29 +0100 schrieb Eric Botcazou:
> > This is a silent and dangerous incorrect code generation issue.
>
> Let's avoid this kind of FUD, please, builtins are low-level devices and
> people must know what they are doing and be prepared for caveats.
Sorry, I do not thin
Am Freitag, den 26.11.2021, 09:24 + schrieb Jonathan Wakely:
> On Fri, 26 Nov 2021 at 09:00, Martin Uecker via Gcc wrote:
> > Am Freitag, den 26.11.2021, 09:29 +0100 schrieb Eric Botcazou:
> > > > This is a silent and dangerous incorrect code generation issue.
> >
Am Freitag, den 26.11.2021, 15:48 + schrieb Jonathan Wakely:
> On Fri, 26 Nov 2021 at 15:41, Martin Uecker wrote:
> > Am Freitag, den 26.11.2021, 09:24 + schrieb Jonathan Wakely:
> > > On Fri, 26 Nov 2021 at 09:00, Martin Uecker via Gcc
> > > wrote:
> &g
Hi Richard,
I have a question regarding reodering of volatile
accesses and trapping operations. My initial
assumption (and hope) was that compilers take
care to avoid creating traps that are incorrectly
ordered relative to observable behavior.
I had trouble finding examples, and my cursory
gla
Am Samstag, den 08.01.2022, 13:41 +0100 schrieb Richard Biener:
> On January 8, 2022 9:32:24 AM GMT+01:00, Martin Uecker
> wrote:
> > Hi Richard,
thank you for your quick response!
> > I have a question regarding reodering of volatile
> > accesses and trappin
Am Samstag, den 08.01.2022, 15:41 +0100 schrieb Eric Botcazou:
> > Yes, although I think potentially trapping ops
> > are not moved before calls (as this would be
> > incorrect). So do you think it would be feasable
> > to prevent this for volatile too?
>
> Feasible probably, but why would this b
Am Samstag, den 08.01.2022, 16:03 +0100 schrieb David Brown:
> On 08/01/2022 09:32, Martin Uecker via Gcc wrote:
> > Hi Richard,
> >
> > I have a question regarding reodering of volatile
> > accesses and trapping operations. My initial
> > assumption (and hope)
Am Samstag, den 08.01.2022, 10:35 -0800 schrieb Andrew Pinski:
> On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc wrote:
> >
> > Hi Richard,
> >
> > I have a question regarding reodering of volatile
> > accesses and trapping operations. My initial
&g
Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener:
> On Sat, Jan 8, 2022 at 10:09 PM Martin Uecker via Gcc wrote:
> > Am Samstag, den 08.01.2022, 10:35 -0800 schrieb Andrew Pinski:
> > > On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc
> > >
Am Dienstag, den 11.01.2022, 08:11 +0100 schrieb Richard Biener:
> On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote:
> > Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener:
Hi Richard,
> > > > For volatile, it seems this would need some tweaks.
> > >
Am Dienstag, den 11.01.2022, 10:13 +0100 schrieb Richard Biener:
> On Tue, Jan 11, 2022 at 9:17 AM Martin Uecker wrote:
> > Am Dienstag, den 11.01.2022, 08:11 +0100 schrieb Richard Biener:
> > > On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote:
> > > > Am Monta
Am Donnerstag, den 13.01.2022, 16:45 + schrieb Michael Matz:
> Hello,
>
> On Tue, 11 Jan 2022, Martin Uecker via Gcc wrote:
>
> > > Handling all volatile accesses in the
> > > very same way would be possible but quite some work I don't
> > >
Am Freitag, den 14.01.2022, 14:15 + schrieb Michael Matz:
> Hello,
>
> On Thu, 13 Jan 2022, Martin Uecker wrote:
...
> > > I think to define this
> > > all rigorously seems futile (you need a new
> > > category between observable and UB), so it comes
Am Freitag, den 14.01.2022, 19:54 + schrieb Jonathan Wakely:
> On Fri, 14 Jan 2022, 14:17 Michael Matz via Gcc, wrote:
>
> > Hello,
> >
> > On Thu, 13 Jan 2022, Martin Uecker wrote:
> >
> > > > > > Handling all volatile accesses in the very
Am Samstag, den 15.01.2022, 16:33 + schrieb Jonathan Wakely:
> On Sat, 15 Jan 2022, 09:00 Martin Uecker, wrote:
>
> > Am Freitag, den 14.01.2022, 19:54 + schrieb Jonathan Wakely:
> > > On Fri, 14 Jan 2022, 14:17 Michael Matz via Gcc,
> > wrote:
> > >
Am Samstag, den 15.01.2022, 16:38 -0500 schrieb Paul Koning:
> > On Jan 15, 2022, at 4:28 PM, Martin Sebor wrote:
> >
> > On 1/14/22 07:58, Paul Koning via Gcc wrote:
> > > > On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc
> > > > wrote:
> > > >
> > > > > ...
> > > > But right now that's equ
Am Dienstag, den 18.01.2022, 09:31 +0100 schrieb Richard Biener:
> On Mon, Jan 17, 2022 at 3:11 PM Michael Matz via Gcc wrote:
> > Hello,
> >
> > On Sat, 15 Jan 2022, Martin Uecker wrote:
> >
> > > > Because it interferes with existing optimisations. An
...
> >
> >Whether or not you feel like the manpages are the best place to
> > start that, I'll leave up to you!
>
> I'll try to defend the reasons to start this in the man-pages.
>
> This feature is mostly for documentation purposes, not being meaningful
> for code at all (for some me
Am Samstag, den 03.09.2022, 15:41 +0200 schrieb Alejandro Colomar:
> Hi Martin,
>
> On 9/3/22 14:47, Martin Uecker wrote:
> [...]
>
> > GCC will warn if the bound is specified inconsistently between
> > declarations and also emit warnings if it can see that a buffer
Hi Alejandro,
Am Samstag, den 03.09.2022, 16:59 +0200 schrieb Alejandro Colomar:
> Hi Martin,
>
> On 9/3/22 16:35, Martin Uecker wrote:
> > Am Samstag, den 03.09.2022, 15:41 +0200 schrieb Alejandro Colomar:
> > > Hi Martin,
> > >
> >
Am Donnerstag, den 10.11.2022, 01:39 + schrieb Joseph Myers:
> On Thu, 10 Nov 2022, Joseph Myers wrote:
>
> > On Thu, 10 Nov 2022, Alejandro Colomar via Gcc wrote:
> >
> > > I've shown the three kinds of prototypes that have been changed:
> > >
> > > - Normal VLA; nothing fancy except for t
Am Donnerstag, den 10.11.2022, 23:19 + schrieb Joseph Myers:
> On Thu, 10 Nov 2022, Martin Uecker via Gcc wrote:
>
> > One problem with WG14 papers is that people put in too much,
> > because the overhead is so high and the standard is not updated
> > very often. It
Am Samstag, den 12.11.2022, 01:09 + schrieb Joseph Myers:
> On Fri, 11 Nov 2022, Martin Uecker via Gcc wrote:
>
> > > Even a compiler extension requires the level of detail of specification
> > > that you get with a WG14 paper (and the level of work on fin
Am Samstag, den 12.11.2022, 14:54 + schrieb Joseph Myers:
> On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
>
> > Since it's to be used as an rvalue, not as a lvalue, I guess a
> > postfix-expression wouldn't be the right one.
>
> Several forms of postfix-expression are only rvalues.
>
Am Sonntag, den 13.11.2022, 15:02 +0100 schrieb Alejandro Colomar:
>
> On 11/13/22 14:33, Alejandro Colomar wrote:
> > Hi Martin,
> >
> > On 11/13/22 14:19, Alejandro Colomar wrote:
> > > > But there are not only syntactical problems, because
> > > > also the type of the parameter might become re
Am Sonntag, den 13.11.2022, 16:15 +0100 schrieb Alejandro Colomar:
> Hi Martin,
>
> On 11/13/22 15:58, Martin Uecker wrote:
> > Am Sonntag, den 13.11.2022, 15:02 +0100 schrieb Alejandro Colomar:
> > > On 11/13/22 14:33, Alejandro Colomar wrote:
> > > > On 11/
Am Dienstag, dem 29.11.2022 um 16:53 + schrieb Jonathan Wakely:
> On Tue, 29 Nov 2022 at 16:49, Joseph Myers wrote:
> >
> > On Tue, 29 Nov 2022, Michael Matz via Gcc wrote:
> >
> > > like. But I'm generally doubtful of this whole feature within C
> > > itself.
> > > It serves a purpose in do
Am Freitag, dem 17.02.2023 um 02:04 +0100 schrieb Alejandro Colomar
>
> [...]
>
> >
> > I'm not convinced that it's useful to the end-user to warn about
> > the
> > "use of q itself" case.
>
> I didn't quote the standard because I couldn't find it. I was
> searching in C11,
> and it seems th
Am Freitag, dem 17.02.2023 um 12:35 +0100 schrieb Alejandro Colomar:
> Hi Martin,
>
> On 2/17/23 09:12, Martin Uecker wrote:
> > Am Freitag, dem 17.02.2023 um 02:04 +0100 schrieb Alejandro Colomar
> >
> >
> > >
> > > [...]
> > >
> >
Am Donnerstag, dem 23.02.2023 um 20:23 +0100 schrieb Alex Colomar:
> Hi Martin,
>
> On 2/17/23 14:48, Martin Uecker wrote:
> > > This new wording doesn't even allow one to use memcmp(3);
> > > just reading the pointer value, however you do it, is UB.
> >
Am Donnerstag, dem 23.02.2023 um 19:21 -0600 schrieb Serge E. Hallyn:
> On Fri, Feb 24, 2023 at 01:02:54AM +0100, Alex Colomar wrote:
> > Hi Martin,
> >
> > On 2/23/23 20:57, Martin Uecker wrote:
> > > Am Donnerstag, dem 23.02.2023 um 20:23 +0100 schrieb A
Am Freitag, dem 24.02.2023 um 02:42 +0100 schrieb Alex Colomar:
> Hi Serge, Martin,
>
> On 2/24/23 02:21, Serge E. Hallyn wrote:
> > > Does all this imply that the following is well defined behavior (and shall
> > > print what one would expect)?
> > >
> > > free(p);
> > >
> > > (void) &p;
Am Freitag, dem 24.02.2023 um 03:01 + schrieb Peter Lafreniere:
...
>
> > Maybe it could do an exception for printing, that is, reading a pointer
> > is not a problem in itself, a long as you don't compare it, but I'm not
> > such an expert about this.
>
> One last thought: with the above st
Am Freitag, dem 24.02.2023 um 10:01 -0600 schrieb Serge E. Hallyn:
> On Fri, Feb 24, 2023 at 09:36:45AM +0100, Martin Uecker wrote:
> > Am Donnerstag, dem 23.02.2023 um 19:21 -0600 schrieb Serge E. Hallyn:
...
> >
> > Yes, but one comment about terminology:. The C standa
> On Thu, May 11, 2023 at 11:14 PM Kees Cook via Gcc wrote:
> >
> > On Thu, May 11, 2023 at 08:53:52PM +, Joseph Myers wrote:
> > > On Thu, 11 May 2023, Kees Cook via Gcc wrote:
> > >
> > > > On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote:
> > > > > On 5/11/23 18:07, Alej
Am Donnerstag, dem 18.05.2023 um 20:59 + schrieb Qing Zhao:
>
> > On May 18, 2023, at 12:25 PM, Martin Uecker via Gcc wrote:
> >
> >
> >
> > > On Thu, May 11, 2023 at 11:14 PM Kees Cook via Gcc
> > > wrote:
> > > >
> > &
Hi all,
is it still possible to have user branches in the repository?
If so, how do I create one? Simply pushing to users/uecker/vla
or something is rejected.
Martin
1 - 100 of 168 matches
Mail list logo
