[Z88dk-users] Using sizeof with structures (fwd)

Bridge to the z88dk-users mailing list
Post Reply
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

[Z88dk-users] Using sizeof with structures (fwd)

Post by dom »

One day I'll get the hang of multiple mailing lists :). In case anyone is
only on -users, here's the misdirected mail.

---------- Forwarded message ----------
Date: Fri, 24 Jan 2003 21:52:33 +0000 (GMT)
From: Dominic Morris <dom@...>
To: z88dk-developers@...
Subject: [z88dk-dev] Re: [Z88dk-users] Using sizeof with structures

Hi Chris,

On Fri, 24 Jan 2003, Chris Cowley wrote:
Yes, I agree. The sizeof() issue is one that would be nice to fix for
reasons of portability as it's used a lot (well it is by me, anyway).
From what you've said about casts, that doesn't really seem like a major
problem -- the workaround is trivial to implement and, arguably,
parenthesising them is the Right Thing To Do anyway.
I've just put a fix into CVS that should resolve the sizeof() problem. It
was simply a case of not storing the size of the array. Let me know how
you get on with it.

cheers,

d.




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
z88dk-developers mailing list
z88dk-developers@...
https://lists.sourceforge.net/lists/lis ... developers



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
Chris Cowley

Post by Chris Cowley »

On Fri, 24 Jan 2003 21:56:31 +0000 (GMT), Dominic Morris
<dom@...> wrote:
I've just put a fix into CVS that should resolve the sizeof() problem. It
was simply a case of not storing the size of the array. Let me know how
you get on with it.
Thanks for that. It will be a few days before I can try it out as it's
very non-trivial for me to compile z88dk on the Windows box I normally
use (I've been compiling the libs on a *nix box at work and FTPing them
across to Windows). I'll give it a go on a machine running linux during
the week and will let you know how it goes!

Cheers,
Chris.
--
Chris Cowley


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

On Sun, 26 Jan 2003, Chris Cowley wrote:
Thanks for that. It will be a few days before I can try it out as it's
very non-trivial for me to compile z88dk on the Windows box I normally
use (I've been compiling the libs on a *nix box at work and FTPing them
across to Windows). I'll give it a go on a machine running linux during
the week and will let you know how it goes!
Dennis has created a new Windows build. You can download it from:

http://www.algonet.se/~dennisgr/z88dk.htm

d.





-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
Chris Cowley

Post by Chris Cowley »

On Sun, 26 Jan 2003 20:53:21 +0000 (GMT), Dominic Morris
<dom@...> wrote:

Dennis has created a new Windows build. You can download it from:

http://www.algonet.se/~dennisgr/z88dk.htm
Excellent. That works a treat and has saved me a lot of agro. However,
(there's always a "however"...) I've noticed another little bug which is
also present in the 1.5 release of sccz80 that is related to
pre-initializing local array variables:-

main() {
char s[] = "hello";
printf("%s\n",s);
}

compiles, but doesn't produce the correct results. Although it works
fine if "char s[] = "hello";" is moved outside of main().

main() {
int i[] = {1,2,3,4,5};
printf("%d\n",[0]);
}

produces multiple compiler errors unless "int i[] = {1,2,3,4,5};" is
moved outside of main(), where it works fine. Replacing "int i[]" with
"int i[5]" makes no difference.

This doesn't actually break anything I'm trying to do, I just spotted it
and thought you should know.

Cheers,
Chris.
--
Chris Cowley


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

On Sun, 26 Jan 2003, Chris Cowley wrote:
Excellent. That works a treat and has saved me a lot of agro. However,
(there's always a "however"...) I've noticed another little bug which is
also present in the 1.5 release of sccz80 that is related to
pre-initializing local array variables:-

main() {
char s[] = "hello";
printf("%s\n",s);
}

compiles, but doesn't produce the correct results. Although it works
fine if "char s[] = "hello";" is moved outside of main().

main() {
int i[] = {1,2,3,4,5};
printf("%d\n",[0]);
}

produces multiple compiler errors unless "int i[] = {1,2,3,4,5};" is
moved outside of main(), where it works fine. Replacing "int i[]" with
"int i[5]" makes no difference.

This doesn't actually break anything I'm trying to do, I just spotted it
and thought you should know.
Wahey! Someone finally spotted that one! <grin> I thought this was
documented somewhere, but I can't spot it at the moment. Yes, this sort of
behaviour isn't permitted. If you think about how it would work in z80
regarding allocating space on the stack and then copying the individual
elements over it's incredibly inefficient. Certainly for strings it's far
easier/efficient to define a pointer to a string (rather than an array of
characters). You can of course, always make them static. Maybe it's best
to emit a warning however. I'll take a look at the code and see what can
be done to mitigate the problem - it may not have such a quick turn around
as the other problems though!

d.




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
Chris Cowley

Post by Chris Cowley »

On Mon, 27 Jan 2003 01:13:11 +0000 (GMT), Dominic Morris
<dom@...> wrote:
Wahey! Someone finally spotted that one! <grin> I thought this was
documented somewhere, but I can't spot it at the moment. Yes, this sort of
behaviour isn't permitted. If you think about how it would work in z80
regarding allocating space on the stack and then copying the individual
elements over it's incredibly inefficient. Certainly for strings it's far
easier/efficient to define a pointer to a string (rather than an array of
characters). You can of course, always make them static. Maybe it's best
to emit a warning however.
Ah, I see. Emitting a warning would be a good option as I originally
thought I'd found an optimisation rule error when my
supposedly-initialised string contained garbage.

It's easy to forget the limitations of the underlying hardware, and the
fact that the compiler is actually a "small" C compiler with lots of
extra stuff bolted on, as most of the code I've tried so far works fine
first time. It's easy to get complacent!
I'll take a look at the code and see what can
be done to mitigate the problem - it may not have such a quick turn around
as the other problems though!
Don't worry about it. As I said, it doesn't really break anything I'm
trying to do and as long as everyone's aware of what can/can't be done
it easy to avoid.
--
Chris Cowley


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

On Mon, 27 Jan 2003, Chris Cowley wrote:
Ah, I see. Emitting a warning would be a good option as I originally
thought I'd found an optimisation rule error when my
supposedly-initialised string contained garbage.
I'll add in a fatal error since the generated code is garbage.
Don't worry about it. As I said, it doesn't really break anything I'm
trying to do and as long as everyone's aware of what can/can't be done
it easy to avoid.
I have an idea as to how to resolve it; basically rewriting the
initialising code so that everything is stuffed into the literal queue and
then dumped out for statics or ldir'd onto the stack for auto variables.
It's a bit of big change so I'll be thinking on it for a while.

However, I'll add the error at some point this week.

cheers,

d.







-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
Post Reply