Busybox make, modify my /dev/null on host

[Mike Frysinger]

On Thursday 14 February 2008, Paul Fox wrote:
>  > # ls -l /dev/null
>  > crwxrwxrwx    1 root     root       1,   3 Feb 14 07:04 /dev/null
>  >
>  > # gcc file.c -o /dev/null
>  > /tmp/ccopqxnU.o: In function `main':
>  > file.c:(.text+0x1d): undefined reference to `doesnt_exist'
>  > collect2: ld returned 1 exit status
>  >
>  > # ls -l /dev/null
>  > ls: /dev/null: No such file or directory
>
> okay.  educate me.  why _shouldn't_ gcc remove the output file in
> that case?  if gcc removes the target of -o in all other cases,
> then, in my opinion, /dev/null shouldn't be special.  if it's
> important that gcc be able to do "test runs" without creating
> output, then there should be a "test run" option that says,
> "don't create an output file".  or maybe "-o -" should be
> implemented, to allow writing to stdout, so it can be redirected
> to /dev/null.
>
> but gcc shouldn't be burdened with understanding the special
> needs of the developer for specific file arguments.  running
> builds as root is like performing on the high wire without a net.
> you need to understand the limits of your equipment.  should gcc
> also be told that it should refuse to write output when given "-o
> /dev/hda1", if /dev/hda1 is a mounted filesystem?  how smart do
> we expect our tools to be?

it's a trade off between code simplicity and least surprise for the user.  in 
other words, do you go for the ideal or do you deal with the reality of 
things.  in this case, i think least surprise makes more sense (and that's 
what the binutils/gcc guys picked).  yes, you should never compile as root.  
but reality is clear that people do.

i think this issue has been hammered to death here though .... time to let it 
go.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.busybox.net/pipermail/busybox/attachments/20080214/705e96f0/attachment-0002.pgp