[gccsdk] GCC 4.1.1 prerelease 1: __RISCOSIFY_FILETYPE_NOT_SETnot working
duncan.m00re at btinternet.com
Sat Jan 19 06:48:13 PST 2008
Peter Naulls wrote:
> "Duncan Moore" <duncan.m00re at btinternet.com> wrote:
>> VRPC RISC OS 4.39
>> gcc (GCC) 4.1.1 (GCCSDK GCC 4.1.1 Prerelease 1)
>> __RISCOSIFY_FILETYPE_NOT_SET unset is no longer working, i.e. files
>> aren't getting filetyped.
I should have said "i.e. files always get filetyped as Text".
> Do you have a short example?
>> Also, is there a reason why this flag is intended to only work with
>> Unix names, and not RISC OS names?
> It's not real clear what you mean. Again, an example would be good,
> with explanations of what you were expecting.
Here' a quick contrived example. If I copy !GCC.bin.gcc from 3.4.6 and 4.1.1
to gcc346 and gcc411 respectively, and run the following commands
*gcc346 --version > 346u.pdf
*gcc411 --version > 411u.pdf
*Set UnixEnv$gcc346$nonametrans ""
*Set UnixEnv$gcc411$nonametrans ""
*gcc346 --version > 346r/pdf
*gcc411 --version > 411r/pdf
, I get 346u/pdf filetyped as Pdf, but the other 3 as Text.
So firstly I'm getting a difference in behaviour between gcc 3.4.6 and gcc
4.1.1 when nonametrans is unset. gcc 3.4.6 is filetyping the file as Pdf,
and gcc 4.1.1 as Text.
My second point was that in gcc 3.4.6 (which presumably is working as
intended) there is a difference in filetyping between having nonametrans set
or unset. With nonametrans unset the file is filetyped as Pdf, and with
nonametrans set it is filetyped as Text. I have a recollection of reading
somewhere in the documentation sometime ago that this behaviour is
intentional. But I can't find it now, so it may be my memory at fault. I was
wondering what the reason was for the files being filetyped differently, as
from the users point of view it appears inconsistent.
An example not involving redirection: I have compiled the coreutils 'touch'
utility with both gcc versions, to work with either nonametrans set or
unset. If I do:
etc, with nonametrans set appropriately, then I get the same results as
above: 346u/pdf is filetyped as Pdf, and the other 3 as Text.
I had always assumed it was __RISCOSIFY_FILETYPE_NOT_SET that controlled
this filetyping behaviour (though I've never actually confirmed this). I
should point out that I don't actually rely on this filetyping behaviour in
any of my own programs. I was just pointing out that it has changed between
gcc 3.4.6 and gcc 4.1.1.
More information about the gcc