[BUGS] in FlashFileStream and Compiler

Michael Rutenberg mdr at scn.org
Sat Jan 28 03:57:01 UTC 2012


(BUG 1) The following method from FlashFileStream is interesting but most likely wrong.   What looks like the hex constant 16r3f (note lower case f) is accepted as the expression "16r3 f", namely send "f" to 3.  (You can examine the bytecodes for details.)

(BUG 2) The compiler is not consitant in how it treats various cases.
16r		quietly equivalent to the expression		0
16ru	quietly equivalent to the expression		0 u
16ruu	compiler asks about the undefined selector uu

Which raises a few language syntax issues:
(1) Should "16r" be a valid equivalent of zero (Number readFom:base: says it is)?
(2) Is it worth increasing the safety of non base-10 numbers by requiring trailing white space and testing for errors in the number?  Many of the possible errors may already be caught by other parts of the compiler.

Mike
	mdr at scn.org
	"Smalltalk browseAllUnimplementedCalls"


FlashFileStream
nextTagPut: tag length: length
	"Write the next tag."
	length >= 16r3f ifTrue:[		"BUG -- Should be 16r3F"
		self nextWordPut: (tag bitShift: 6) + 16r3F.
		self nextULongPut: length.
	] ifFalse:[
		self nextWordPut: (tag bitShift: 6) + length.
	].





More information about the Squeak-dev mailing list