https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94626
--- Comment #3 from Allison Karlitskaya
---
(In reply to Martin Sebor from comment #2)
> Thanks for the report (and for getting Glibc to update its headers). The
> problem with strncpy is that its correct and intended uses (filling a buffer
> w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94615
Allison Karlitskaya changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: allison.karlitskaya at redhat dot com
Target Milestone: ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94615
Consider this code:
{
struct lastlog entry;
strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94615
Allison Karlitskaya changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94615
--- Comment #3 from Allison Karlitskaya
---
(In reply to Richard Biener from comment #1)
> Maybe use memcpy then, str* routines generally expect nul-termination
"str* routines generally expect nul-termination" doesn't really fly as an
argument,
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: allison.karlitskaya at redhat dot com
Target Milestone: ---
Consider this code:
{
struct lastlog entry;
strncpy (entry.ll_host, rhost, sizeof entry.ll_host);
/* fill other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91952
--- Comment #5 from Allison Karlitskaya
---
One could imagine (as a first step) that __default_value__() would be
implemented by way of a simple code transformation whenever it is encountered.
An additional block could be added and the variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91952
--- Comment #4 from Allison Karlitskaya
---
(In reply to Jakub Jelinek from comment #3)
> First of all, not all automatic vars live on stack, some live in registers.
Sure. The register could also be initialised to the same value, of course.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91952
--- Comment #2 from Allison Karlitskaya
---
Consider this example in way of clarification:
void cleanup_func (void **ptr);
void *init (void);
void
function (bool condition)
{
if (condition)
goto out;
__attribute__((__cleanup__(cleanu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91951
--- Comment #1 from Allison Karlitskaya
---
Two notes:
First: Owen Taylor (the author of the blog post) pointed out that with -O2, GCC
is able to notice the uninitialised use of the variable in my example and warn
about it. Note that this is a
Assignee: unassigned at gcc dot gnu.org
Reporter: allison.karlitskaya at redhat dot com
Target Milestone: ---
In automatic context, instead of writing
int x = 5;
it would be nice to be able to write
__attribute__((__default_value__(5))) int x;
which would have slightly
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: allison.karlitskaya at redhat dot com
Target Milestone: ---
Declaring a variable using __attribute__((__cleanup__)) and an initialiser and
then jumping over it with goto will produce
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: allison.karlitskaya at redhat dot com
Target Milestone: ---
The GObject type system contains support for private variables, which works
like this: you create a
13 matches
Mail list logo
