[comp.sys.atari.st] "file selector" blues, Megamax bug

braner@batcomputer.UUCP (04/09/87)

[]

I was using UNSQZ.PRG the other day, and got very frustrated.  Partly
it is my fault, partly Atari/DRI's fault, and partly unsqz's author.

Attempting to unsqueeze files on a RAMdisk, UNSQZ gave me a file selection
dialog box (the standard TOS thing) showing the files in drive D:\ with a
.?Q? suffix.  After selecting one, it then spun DRIVE A to look for a target
file!  This is doubly silly, since: I 'was' in D:, and if the target file
existed I wouldn't need to unsqueeze it!  After inserting a floppy to calm
TOS down, I clicked on "A:" and typed the long string "D:\*.*".  After that
unreasonable effort I automatically hit <Return> (habit? nature?), so I
had to start all over again.  After several trials I remembered to click in
the file-list window, then type in the real target name, then <Return> (yes).
(UNSQZ did display the appropriate target name at first, but TOS erased it
when I requested a different directory.)

Then I wanted to unsqueeze another file.  UNSQZ went back to A:\...

If there are shortcuts, I'd like to hear about them.

Atari: please add a drive-selection button to the file-selection dialog
       (like on the Macintosh), and try to give the user more slack
       with that Return key (e.g., when there is _no_ file name
       selected, ignore <return>, or equate it with a mouse click
       in a useful spot).

Programmers: please take more care to change the defaults passed to
       that dialog box as appropriate, and to accomodate users that
       use the ST in a different fashion than you: RAMdisk, hard disk,
       color, B&W, etc.

Yet another bug in Megamax C:

	sizeof("a string constant") always yields 4.

	(sizeof(s) where s is of type array-of-char works fine.)

- Moshe Braner

john@viper.UUCP (04/12/87)

In article <639@batcomputer.tn.cornell.edu>
 braner@tcgould.tn.cornell.edu.UUCP (braner) writes:
 >
 >Programmers: please take more care to change the defaults passed to
 >       that dialog box as appropriate, and to accomodate users that
 >       use the ST in a different fashion than you: RAMdisk, hard disk,
 >       color, B&W, etc.
 >

This is true of a lot of programs.  There are too many people not allowing
for disk systems, hardware, or patterns of use different from what they
would normaly use.  I try to avoid making those types of mistake by showing
my programs to others before I release them.  If possible, I'd recommend
you folkd try doing this to.  It's never too late to rethink your interface
or the methods that lie behind them...

 >Yet another bug in Megamax C:
 >
 >	sizeof("a string constant") always yields 4.
 >
 >	(sizeof(s) where s is of type array-of-char works fine.)
 >
 >- Moshe Braner

  As I mentioned before...  This is infact the right way for sizeof to
work.  When you ask for sizeof(something) you're always asking how
large that element is to the compiler.  The type reference is a reference
to a type with a specific size...  The reference to the string is
translated into a pointer before sizeof gets around to doing it's job.
I agree that the latter is confusing, but it conforms to K&R page 94
"... a reference to an array is converted by the compiler to a pointer
to the beginning of the array." And to page 188 where the effects of
using sizeof on a type identifier is described.  If you wanted to know
how long the string is, you might want to use strlen instead...

--- 
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john

john@viper.UUCP (04/13/87)

In article <821@viper.UUCP> I wrote
 >In article <639@batcomputer.tn.cornell.edu>
 > braner@tcgould.tn.cornell.edu.UUCP (braner) writes:
 > >
 > >Yet another bug in Megamax C:
 > >
 > >	sizeof("a string constant") always yields 4.
 > >
 > >	(sizeof(s) where s is of type array-of-char works fine.)
 > >
 > >- Moshe Braner
 >
 > When you ask for sizeof(something) you're always asking how large 
 >that element is to the compiler.  The type reference is a reference
 >to a type with a specific size...  The reference to the string is
 >translated into a pointer before sizeof gets around to doing it's job.
 >I agree that the latter is confusing, but it conforms to K&R page 94
 >"... a reference to an array is converted by the compiler to a pointer
 >to the beginning of the array." And to page 188 where the effects of
 >using sizeof on a type identifier is described.  If you wanted to know
 >how long the string is, you might want to use strlen instead...
 >

  Well...  I've looked in 5 different references and found 2 different
ways to interpret how sizeof("string") should end up being evaluated.
The "Bible" (K&R) doesn't give any examples that directly apply (although
there are a few examples in the other books I have that -imply- that 
it should result in the length of the string plus one (for the 
trailing null)).

  I'll go so far here as to say I was probably wrong.  It looks like
someone at Megamax took a look at K&R and made the same easy-to-make
mistake that I did.  The quote that I refered to from page 94 implys that
the conversion is done before evaluation of an expression is started.
Unfortunately, the documentation covering sizeof also implys that the
sizeof operation must be done during the evaluation phase which is
-after- the reference to the array (any array) would be converted to
a pointer...  This implys that the the value returned from sizeof("string")
would be the size of the pointer, not the size of the string.

  The second case which involves an array directly implys that whoever
implemented the sizeof got the code right and the person who wrote the
code to process a string overlooked the need to maintain the array-size
information for the single case where it would matter...

  This is another example of why an ANSI standard for C is necessary.
I sincerly hope this is explicitly detailed so we won't run into this
problem in ANSI-conforming compilers....

  Oh well... Live and learn...

  Why are you using an -odd- construct like that anyway?

--- 
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john

nowlin@ihuxy.UUCP (04/13/87)

In article <639@batcomputer.tn.cornell.edu>, braner@batcomputer.tn.cornell.edu (braner) writes:
> []
> 
> Yet another bug in Megamax C:
> 
> 	sizeof("a string constant") always yields 4.
> 
> 	(sizeof(s) where s is of type array-of-char works fine.)
> 
> - Moshe Braner

Intuitively this looks like a place where you'd want to use strlen()
instead of sizeof().  I know sizeof() is faster.  It doesn't make as much
sense as strlen() in this context though.  I suspect that Megamax is
resolving the reference to a string constant as a (char *) which is of size
4.  It's almost funny but some of the 3B compilers also return 4 for this
operation and trying to solve the bug it introduced into our code was the
cause of much wailing and gnashing of teeth.  If you want the length of a
string use strlen().  Personally I think it's a bug if sizeof("string")
doesn't return the size of (char *).

Jerry Nowlin
(...!ihnp4!ihuxy!nowlin)

pett@socrates.ucsf.edu.UUCP (04/14/87)

In article <821@viper.UUCP> john@viper.UUCP (John Stanley) writes:
>In article <639@batcomputer.tn.cornell.edu>
> braner@tcgould.tn.cornell.edu.UUCP (braner) writes:
> >Yet another bug in Megamax C:
> >
> >	sizeof("a string constant") always yields 4.
> >
> >	(sizeof(s) where s is of type array-of-char works fine.)
> >
> >- Moshe Braner
>
>  As I mentioned before...  This is infact the right way for sizeof to
>work.  ...

What???  I find it difficult to believe this is a subject for argument!
A string constant is a character ARRAY and therefore sizeof returns the
storage taken by the string constant.  If you have an array: int foo[10][10],
sizeof(foo) will return 100 * sizeof(int) despite the fact that foo is a
pointer.  If you don't believe me just run the following program on your
MAINFRAME yourself.

#include	<stdio.h>

main()
{
	printf("sizeof(\"abcdef\") = %d\n", sizeof("abcdef"));
}

This will return 7.

				Eric Pettersen
				pett@cgl.ucsf.edu or ucbvax!ucsfcgl!pett

bammi@cwruecmp.UUCP (Jwahar R. Bammi) (04/14/87)

In article <821@viper.UUCP> john@viper.UUCP (John Stanley) writes:
>In article <639@batcomputer.tn.cornell.edu>
> braner@tcgould.tn.cornell.edu.UUCP (braner) writes:
> >Yet another bug in Megamax C:
> >
> >	sizeof("a string constant") always yields 4.
>  As I mentioned before...  This is infact the right way for sizeof to
>work.  When you ask for sizeof(something) you're always asking how
>large that element is to the compiler.  The type reference is a reference
>to a type with a specific size...  The reference to the string is
>translated into a pointer before sizeof gets around to doing it's job.
>I agree that the latter is confusing, but it conforms to K&R page 94
>"... a reference to an array is converted by the compiler to a pointer
>to the beginning of the array." And to page 188 where the effects of
>using sizeof on a type identifier is described.  If you wanted to know
>how long the string is, you might want to use strlen instead...
>
>--- 

	i think you are quoting K&R page 94 a little bit out of context
(for the sizeof operator). The sizeof operator is evaluated at compile
time, and does not itself cause any usual conversions to be applied to
the expression in determining its type. If what you said were true, then
consider the following example

		char a[100];

		printf("%d\n",sizeof(a));

	Why should the sizeof a be 100 and not 4??
	Since "..." is nothing but an array of char, then it follows ....

	Another bug in MegaMax

		int b;
		sizeof(b+0L);
		^^^^^^^^^^^^
			Totally confuses the compiler.  MWC,Alcyon,Vax cc,
and Tartan tcc all correctly report 4.
-- 
usenet: {decvax,cbatt,cbosgd,sun}!cwruecmp!bammi	jwahar r. bammi
csnet:       bammi@case
arpa:        bammi%case@csnet-relay
compuServe:  71515,155

wheels@mks.UUCP (04/14/87)

In article <1934@ihuxy.ATT.COM>, nowlin@ihuxy.ATT.COM (Jerry Nowlin) writes:
> In article <639@batcomputer.tn.cornell.edu>, braner@batcomputer.tn.cornell.edu (braner) writes:
> > 	sizeof("a string constant") always yields 4.
> > - Moshe Braner
> 
> It's almost funny but some of the 3B compilers also return 4 for this
> operation and trying to solve the bug it introduced into our code was the
> cause of much wailing and gnashing of teeth.  If you want the length of a
> string use strlen().  Personally I think it's a bug if sizeof("string")
> doesn't return the size of (char *).
> Jerry Nowlin

Well, according to the C gurus here at MKS, this is what should happen:

{
	int a;

	a = sizeof("hello");	/* should produce 6 (5 chars + '\0') */
}

{
	int a;
	char s[] = "hello";

	a = sizeof(s);		/* should also produce 6 */
}

{
	int a;
	char s[25] = "hello";

	a = sizeof(s);		/* should produce 25 */
}

Gerry
-- 
Gerry Wheeler                  {seismo,decvax,ihnp4}!watmath!mks!wheels
Mortice Kern Systems Inc.

wheels@mks.UUCP (04/14/87)

I forgot one example in my last posting...

{
	int a;
	char *s = "hello";

	a = sizeof(s);		/* should produce the size of a pointer */
}
-- 
Gerry Wheeler                  {seismo,decvax,ihnp4}!watmath!mks!wheels
Mortice Kern Systems Inc.