toolchain: warn for unsafe library/header paths
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest8 of 12 patches 0 repliesNew
8 of 12 patches are in this archive. The cover letter announces 12.
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/12 | toolchain-external: instrument wrapper to warn about unsafe paths | +0 | 1 reply | |
| 1/12 | toolchain-external: instrument wrapper to warn about unsafe paths | +0 | 0 replies | |
| 2/12 | binutils/2.24: add patch to warn about unsafe library paths | +0 | 1 reply | |
| 6/12 | gcc/4.9: add patch to warn about unsafe header paths | +0 | 1 reply | |
| 6/12 | gcc/4.9: add patch to warn about unsafe header paths | +0 | 0 replies | |
| 10/12 | gcc: enable poison system directories option | +0 | 0 replies | |
| 11/12 | binutils: enable poison system directories option | +0 | 0 replies | |
| 12/12 | Add option for paranoid unsafe path checking | +0 | 0 replies |
Reviews trailers per patch
3 of 8 patches have a Reviewed-by or Acked-by.
| Patch | Yann E. MORIN |
|---|---|
| 1/12 | |
| 1/12 | |
| 2/12 | |
| 6/12 | |
| 6/12 | |
| 10/12 | A-b |
| 11/12 | A-b |
| 12/12 | A-b |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [Buildroot] [PATCH 00/12] toolchain: warn for unsafe library/header paths
Thomas?, All,
On 2014-08-22 21:29 +0200, Thomas De Schampheleire spake thusly:
Quoted 11 lines
"Yann E. MORIN" <[email protected]> schreef:
Quoted 10 lines
Thomas, All,
On 2014-08-21 23:33 +0200, Thomas Petazzoni spake thusly:
Quoted 6 lines · Romain Naour
Quoted 2 lines
Also,
BR_COMPILER_PARANOID_UNSAFE_PATHneeds to be renamed toBR2_COMPILER_PARANOID_UNSAFE_PATHto follow the naming scheme ?No: BR2_* variables are Config.in options. Environment variables are BR_*.
Quoted 8 lines
Quoted 2 lines
Earlier this year in Brussels, we said we were to use
BR2_everywhere :
http://elinux.org/Buildroot:DeveloperDaysFOSDEM2014Hmm, that is written in the conclusion, but this is very
different than what is in the 'proposed rules'.
Was it really the final outcome to use BR2 for all types
of variable? I thought we wanted to make a distinction between config variables and others...
Yes, I was a bit surprised by the conclusion, too. From what I remember, I thought we decided for:
- user-facing variables: prefix with BR2_
- internal variables: prefix with BR_
IIRC, we already have a few changesets implementing those rules.
For example:
35c666e toolchain/wrapper: rename BR_DEBUG_WRAPPER
(I could not find another reverse such change, unfortunetely...)
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'