https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35592
--- Comment #8 from Eric Gallager ---
Created attachment 45777
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45777&action=edit
testcase
(In reply to felix-gcc from comment #6)
> Sure. For example:
>
> char* c=malloc(lseek(somefd,0,SEEK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35592
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRME
--- Comment #6 from felix-gcc at fefe dot de 2008-04-01 19:34 ---
Sure. For example:
char* c=malloc(lseek(somefd,0,SEEK_END);
on a platform where off_t is 64-bit, but where size_t is 32-bit. For example:
i686-linux with #define _FILE_OFFSET_BITS 64.
Now that I'm thinking about it,
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-04-01 19:18 ---
Can you cook up some code examples where you'd like to see a warning?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35592
--- Comment #4 from felix-gcc at fefe dot de 2008-04-01 16:09 ---
I'm not familiar enough with how gcc works to say whether warning about
precision loss that turns out important later on can be done at all.
But I think we should not reject an idea because it only handles 60% of the
case
--- Comment #3 from manu at gcc dot gnu dot org 2008-04-01 02:53 ---
(In reply to comment #2)
>
> If the size_t given to memcpy is truncated, that does not overwrite a buffer.
> But if the size_t given to malloc is truncated, that is a pretty surefire way
> to find a security issue.
I
--- Comment #2 from felix-gcc at fefe dot de 2008-03-14 19:58 ---
I am aware of -Wconversion, but I am not interested in ALL conversion
truncations. Truncation happens to be a security issue in a few cases, in many
other cases it would just be a regular bug. My suggestions aims to isol
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-14 19:20 ---
You should try -Wconversion .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35592
