const char*

Re: const char*

"Travis D. Reed" <tdreed@...> wrote:
> Since updating gcc, I've had to tinker with the code (see attached 
> patch).
> I've seen some updates that do the same thing, but when I sync with 
> svn, I
> can't compile...so I'm just patching the files. What am I doing 
> wrong?

I haven't tested it (and for help in this regard, adding the compiler 
output would be very convenient), but you mess up the function 
signatures, making them not follow the standards, see
http://www.opengroup.org/onlinepubs/9699919799/toc.htm 
for what const or non const values those functions should return.

Bye,
   Axel.

Re: const char*

Re: const char*

On Wed, Jul 1, 2009 at 11:55 AM, Travis D. Reed<tdreed@...> wrote:
> Here's the relevant compiler output. I'm using gcc (GCC) 4.4.0 20090526
> (prerelease), which is what ArchLinux requires at the
>  moment.

Here is a link describing what's going on:

http://gcc.gnu.org/gcc-4.4/porting_to.html

Scroll down a bit to the "Strict null-terminated sequence utilities"
section, and you'll see how things have changed in the interest of
const-correctness for GCC 4.4.

r30919 was the first instance I saw a fix in this regard,

Basically, with GCC 4.4, if something like strchr is fed a const char*
, it's going to return a const char* .  This can then become
problematic, like has shown to be the case here.

I assume some kind of casting will have to be done.  Will utilizing
const_cast or the like be the way to go?  I'm currently testing other
breakage, so will wait to update my Linux compiler to do further
testing in this regard.

- joe

Re: const char*

On Wed, Jul 1, 2009 at 2:03 PM, Joseph
Prostko<joe.prostko+haiku@...> wrote:
> On Wed, Jul 1, 2009 at 11:55 AM, Travis D. Reed<tdreed@...> wrote:
>> Here's the relevant compiler output. I'm using gcc (GCC) 4.4.0 20090526
>> (prerelease), which is what ArchLinux requires at the
>>  moment.
>

> I'm currently testing other
> breakage, so will wait to update my Linux compiler to do further
> testing in this regard.
>

Okay, first of all, the "other breakage" I mentioned above was human
error on my part, so I didn't have to investigate that too long.  :)

Back on topic though, I messed around with my host compiler a bit.  I
first installed the latest available GCC 4.4.0 package for Ubuntu, but
encountered no problems with the Haiku build.  After that, I built the
latest GCC 4.4 snapshot from the other day, and it built Haiku just
fine as well.  I rebuilt the buildtools and all of Haiku each time
just to make sure the fs_shell objects were getting rebuilt from
scratch.  Actually, I blew away all of my generated dir too throughout
this process, just to be extra sure.

So anyways, I'm not sure what to think, as currently both my host and
cross-compiler are both at the latest GCC 4.4 snapshot level, and I
don't run into the problem you're having.  I am using the latest trunk
with the latest 32bit-w_char branch changes merged in, but that
shouldn't be relevant in this case.  Come to think of it, some time
ago I was building Haiku in Haiku with the native GCC 4.4.0 I was
testing, and I didn't have any hiccups with it bombing out either.  It
doesn't appear as if any changes to fs_shell in this regard since then
would now cause an issue either.

I also logged the build output to see if I noticed anything odd, but I
never encounter the problem with string.o like you get.  It builds
cleanly here with no warnings or anything.  I did get warnings for
"invalid access to non-static data member" several times in vfs.cpp,
but nothing that seems to be related to this problem.

I have no more ideas at the time, really.  I thought my last email was
on the right track, but perhaps not.  Maybe it's just something
specific with the Arch Linux implementation or environment?

Axel may have a better clue now if he dissects anything relevant from
my ramblings.  :)

- joe

Example of LOD usage of icons

Hi!

The documentation of the LOD settings in icons is almost done. Now I need a striking 
exmaple of its use. Anyone know a very visibly LODded icon?
All I can come up with is the StyledEdit icon, but that's only differing in stroke widths 
which is easily overseen.

Thanks.

Regards,
Humdinger

--

-- 
--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-
Deutsche Haiku News  <at>  http://www.haiku-gazette.de

Re: Example of LOD usage of icons

> Hi!
> 
> The documentation of the LOD settings in icons is almost done. Now I 
> need 
> a striking 
> exmaple of its use. Anyone know a very visibly LODded icon?
> All I can come up with is the StyledEdit icon, but that's only 
> differing 
> in stroke widths 
> which is easily overseen.

The App_XEmacs icon shows less lines and parens at 16x16 IIRC.

François.

Re: Example of LOD usage of icons

François Revol wrote:
>> Hi!
>>
>> The documentation of the LOD settings in icons is almost done. Now I 
>> need a striking exmaple of its use.

> The App_XEmacs icon shows less lines and parens at 16x16 IIRC.

Thanks, François, but that's about as striking as the StyledEdit one. :)
I have found a good candidate, however: The archive icons (7zip etc.) wave a colourful 
flag that sports the extention's letters at 32 and 64px, but no letters at 16px. That's 
not too bad if nobody has any better suggestions.

Thanks!

Regards,
Humdinger

--

-- 
--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-
Deutsche Haiku News  <at>  http://www.haiku-gazette.de

Re: Example of LOD usage of icons

Re: Example of LOD usage of icons

scott mc wrote:
> IIRC the BeVexed one has numbers at larger sizes, but drops them at lower
> ones, is this what you are looking for?
> http://dev.haiku-os.org/browser/haiku/trunk/data/artwork/icons/App_BeVexed

Hey, that's even better. More colourful. I think, I'll take that one!
Thanks!

Regards,
Humdinger

--

-- 
--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-
Deutsche Haiku News  <at>  http://www.haiku-gazette.de