Diff of /sml/releases/release-110.38/ckit/BUGS

Parent Directory | Revision Log | Patch

	revision 648, Thu May 25 21:28:21 2000 UTC	revision 649, Wed May 31 18:04:54 2000 UTC
#	Line 31	Line 31
31	COMMENT: Could not compile example (it is incomplete);	COMMENT: Could not compile example (it is incomplete);
32	Kathleen indicates she can't reproduce this behaviour.	Kathleen indicates she can't reproduce this behaviour.
33
34
35		----------------------------------------------------------------------
36		NUMBER: 14
37		SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
38		DATE: 4/17/00
39		TEST:
40		STATUS: open
41		DESCRIPTION: array formals
42
43		This one is similar to the ?: bug we reported earlier (Bug number 8).
44
45		void foo(int a[]);
46
47		int main() {
48		int * ip;
49		foo(ip);
50		}
51
52		Output:
53
54		"tt.c":5.3-10: error: Bad function call:
55		arg 1 has type int * but fn parameter has type int []
56
57		Correct C output is still produced but the implicit type of ip inside
58		the call to foo has int array type.  This is a problem for our
59		instrumentation.
60
61
62		----------------------------------------------------------------------
63		NUMBER: 15
64		SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
65		DATE: 4/17/00
66		TEST:
67		STATUS: open
68		DESCRIPTION: union bitfields
69
70		According to Harbison and Steele (top of p.141), bitfields in unions are
71		allowed in ISO C, but not "traditional" C.  Neither "gcc -ansi -pedantic",
72		nor cc complains.
73
74		input:        union { int u16:12; } u;
75
76		output:       "test.c":1.2-3.4: error: union member has size spec
77
78		union t1 { int u16; };
79		union t1 u;
80
81
82		----------------------------------------------------------------------
83		NUMBER: 16
84		SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
85		DATE: 4/17/00
86		TEST:
87		STATUS: open
88		DESCRIPTION: struct bitfields
89
90		This is not a big deal, since ckit implements a superset of ANSI C,
91		but I thought I'd mention it anyway.  Ckit allows the following:
92
93		struct S {
94		char a:4;   /* <-- Illegal field for ANSI C, but not "traditional" C */
95		float f:4;  /* <-- Illegal field */
96		};
97
98
99		----------------------------------------------------------------------
100		NUMBER: 17
101		SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
102		DATE: 4/14/00
103		TEST:
104		STATUS: open
105		DESCRIPTION: large initializer value
106
107		Input:
108		------
109		long i = 0xf8000000;
110		unsigned long i = 0xf8000000ul;
111
112		Output:
113		-------
114		"test.c":1.11-21: error: large int const
115		"test.c":2.19-31: error: large int const
116		"???": warning: additional errors suppressed.
117		"???": warning: additional warnings suppressed.
118
119		long i=0;
120		unsigned long i=0;
121
122		Note:
123		-----
124		gcc -Wall -ansi -pedantic: no complaint
125		cc: warning: initializer does not fit or is out of range: 0xf8000000
126
127		COMMENT:
128		The problem seems to be due to the fact that LargeInt (i.e. Int32 -
129		signed integer type) is used for storing the value, and LargeInt
130		raises exception Overflow (in c.lex) in the above cases.  IntInf does
131		not overflow on such numbers, and so may be the right thing to use,
132		however that requires changing the code to use IntInf for IntConst.
133
134		Ironically, LargeInt parses hexadecimal strings fine but IntInf does
135		not handle the 0x prefix for some reason:
136
137		- let val v = valOf(StringCvt.scanString(LargeInt.scan StringCvt.HEX) "0xff")
138		= in print ((LargeInt.toString v)^"\n") end;
139		255
140		val it = () : unit
141		- let val v = valOf(StringCvt.scanString(IntInf.scan StringCvt.HEX) "0xff")
142		= in print ((IntInf.toString v)^"\n") end;
143		0
144		val it = () : unit
145		- let val v = valOf(StringCvt.scanString(IntInf.scan StringCvt.HEX) "ff")
146		= in print ((IntInf.toString v)^"\n") end;
147		255
148
149
150		----------------------------------------------------------------------
151		NUMBER: 18
152		SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
153		DATE: 4/14/00
154		TEST:
155		STATUS: open
156		DESCRIPTION:  old style varargs (INCONVENIENCE)
157
158		This is something we have an easy workaround for (i.e. using cc -E
159		instead of gcc -E to preprocess) but we mention it in case you think
160		other people might care about this.  When varargs.h is included by
161		gcc -E, old style parameter passing is transformed to this:
162
163		int foo(a)
164		a;...
165		{ }
166
167		This is not accepted by ckit.
168		Remark: non-ANSI (gcc gives warning)
169		Solution: use cc -E.
170
171
172		----------------------------------------------------------------------
173		NUMBER: 19
174		SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
175		DATE: 4/20/00
176		TEST:
177		STATUS: open
178		DESCRIPTION:  incomplete types
179
180		A change to build-ast.sml since ckit 1.0b3 is annotating types of ids
181		with incomplete types at times.  Our problem is that we use the ast in
182		a separate pass, so we don't see the local symbol tables (unless we
183		redo the work of their construction).  We collect types of declared
184		variables, which we then use in instrumentation.  Incomplete types
185		give us compilation errors.
186
187		The fixed up type is inserted into the symbol table under line 911,
188		however, the type in the id of the declaration is still the incomplete
189		type.  Subsequent uses of the id will by typed correctly but not the
190		declaration.  The id created on line 916 should be used instead of the
191		original id.
192
193		Input:
194
195		int ia[] = {1,2,3};
196
197		int main() {
198		int ib[] = {1,2,3,4,5};
199		}
200
201		Types I see in ids for ia and ib in the declarations above are both
202		int[]. :-)
203
204
205		----------------------------------------------------------------------
206		NUMBER: 20
207		SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
208		DATE: 5/24/00
209		TEST:
210		STATUS: open
211		DESCRIPTION: long long
212
213		1. Ckit doesn't really handle long long (it just recognizes the type, but
214		does not handle literals of "long long" size: seems to be due
215		to using LargeInt. See "unsigned long" bug above.
216
217		2. Should keep around "L", "LL", "UL" suffix to int literals:
218		input:  1LL<<40
219		output: 1<<40   /* compiler complains */
220
221		3. Tilde and negative:
222		input:  2e-5
223		output: 2E~05
224
225		Negative numbers are represented with ~ in SML, so that Real.toString
226		called in ppReal prints the ~ in the exponent.
227
228
229		----------------------------------------------------------------------
230		NUMBER: 21
231		SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
232		DATE: 5/25/00
233		TEST:
234		STATUS: open
235		DESCRIPTION: spurious error messages
236
237		Input:
238		struct S {
239		float j;
240		int:24;
241		char * k;
242		} s = {1.2,"3"};
243
244		Spurious Error Messages:
245		"stst.c":1.2-5.16: error: type of initializer is incompatible with type of lval
246		"stst.c":1.2-5.16: error: badly formed struct initializer: not enough initializers
247
248		FIX:
249		skip over unnamed members, as per C specs: diff of build-ast.sml (<new,>old) follows:
250		623c623
251		<             let fun f ((fieldType, _, _) :: l, expr :: exprs) =
252		---
253		>             let fun f ((fieldType, SOME mem, _) :: l, expr :: exprs) =
254		625a626,627
255		>                   | f ((fieldType, NONE, _) :: l, exprs) =
256		>                        f (l, exprs)
257
258
259		----------------------------------------------------------------------
260		NUMBER: 21
261		SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
262		DATE: 5/25/00
263		TEST:
264		STATUS: open
265		DESCRIPTION:  const char */char * incompatibility (INCONVENIENCE)
266
267		input:        char c[100]; const char * d = &c[5];
268		c - d;
269		output:       error: Type Error: Unacceptable operands of "-" or "--".
270
271		general:      in general, the error occurs with incompatible pointer types.
272		the key is to not treat "const" as incompatible.

---

Colored Diff Long Colored Diff Unidiff Context Diff Side by Side

Legend: Removed from v.648   changed lines   Added in v.649

---

root@smlnj-gforge.cs.uchicago.edu	ViewVC Help
Powered by ViewVC 1.0.0